此为梦断代码第二篇

 

这里的被无数奇点拖住的Chandler，恰恰映照了人月神话中的一句话，没有银弹。

在书的最后，韩磊的译后记中已经提到了Chandler项目的结局，它失败了，它成

了众多失败软件项目中的一个。这个耗资巨大的工程留下了什么？无数人在思考，

作者给出了他的见解：

1.尽量少的人

最复杂的因素：沟通成本的降低以及更好的一致性。

2.尽量少的时间

最有效的开发流程。

3.尽量少的功能

最有把握实现而且是硬性刚需的功能。

这三点减少了问题的理论上限和发生概率。

我想，如果当初Chandler设想的最初版本能够满足上列三个需求，也许已经成功了，

可惜经验的得来往往意味着牺牲.如今，完善的开发流程例如瀑布模型，敏捷开发，

还有团队协作模式，或多或少得益于此。一些看上去很棒的事情其实并不是有益于工程，

例如百花齐放的想法，使用编外人员开发，使用不成熟但是高端的技术，试图创新等等，

Chandler在漫长的岁月里，替后辈趟过了一个又一个雷区。