花几天的时间读完了《人月神话》这本软件工程领域的经典书籍。 本书并不厚，作者的文笔很好，讲述一个观点时能够解释得非常清楚， 翻译得也很不错，没有给理解带来障碍。 书中描述的是作者在上个实际60年代管理大型软件工程项目的一些经验和看法， 可是这些观点拿到现在来看也仍然没有过时。 我在此总结一些我比较有体会的观点，并谈谈我的一些体会。

人月神话

首先是和书名对应的这个观点——“人月神话”， 意思是说尽管一个项目的工作量可以用人月来衡量， 但是“人”和“月”这两个量度并不是可以互换的， 也就是说不能通过增加更多的人手来减少项目完成所需要的时间。 这主要是由于两方面的原因：

• 有些任务由于次序上的限制不能分解， 也就是说不能把一个任务分给两个人来做来减少一半的时间。
• 增加了一个人员就增加了培训和交流的成本。

因此，作者提出了Brooks法则：

向进度落后的项目中增加人手，只会使进度更加落后。

这就是除去了神话色彩的人月。

概念完整性

概念完整性是指整个系统的设计具有一致性，系统只反应唯一的设计理念。 这要求系统的设计必须由一个人，或者非常少数互有默契的人员来实现。 在本书中，作者希望按照“外科手术队伍”的形式来组织团队， 团队的首席程序员类似于外科手术队伍的医生，他定义系统的功能， 设计程序，编制源代码，其他的人员负责给首席程序员提供必要的帮助。 或者，可以对设计方法和具体实现进行分工， 由架构师来完成设计，制定好技术说明，而实现人员负责实现。

概念完整性是如此重要，我所知的成功的软件项目都是反应了一两个天才程序员的理念， 由他们来决定整个项目的走向。

没有银弹

这是本书中一个颇具争议的观点：

在未来十年内，无论是在技术还是管理方法上， 都看不出有任何突破性的进步， 能够独立保证在十年内大幅度地提高软件的生产率、可靠性和简洁性。

首先，作者把软件项目的开发过程分为两部分：

• 根本任务，打造构成抽象软件的复杂概念结构，我理解就是完成软件的设计。
• 次要任务，使用编程语言表达这些抽象实体，也就是完成实现。

作者认为，现在的技术或管理方法的革新，只能改进次要任务的生产率， 而根本任务的难度并没有发生改变。这样，除非次要任务能够占到所有工作的9/10以上， 否则总体的生产率不会有数量级的提升。

那为什么根本任务的生产率无法提高呢？这是由于开发软件系统需要面对这些无法规避的问题：

• 复杂度。一个软件系统有大量的状态，存在大量不同元素的相互叠加。 这使得软件系统的复杂性以指数的形式增长。而且，这些复杂度是软件系统的根本属性， 而不像数学和物理中那样可以建立简化的模型而忽略复杂的次要因素。

• 一致性。复杂度的问题不只是软件工程师才会面对，物理学家也会面临复杂度的问题。 但是他们相信能够建立一个通用的理论将这些复杂性统一起来，因为整个宇宙的规律是由上帝创造的， 而上帝不是反复无常的。而软件工程师需要控制的复杂度是随心所欲，毫无规律可言的， 需要遵循人为惯例和系统约束，需要和这些系统保持一致。 （可以这样理解，这些复杂度是由不同的PM带来的，我没有黑PM啊。。）

• 可变性。有两个因素导致软件需要经常发生变化， 一是软件系统改变的容易性使得有更多改变的需求（PM说，不就是改两行代码吗？ 他绝不会轻易让人去改装一辆生产好的汽车）；二是软件的寄主（操作系统，硬件）经常发生变化， 使得软件需要改变。

• 不可见性。这一点我不是很理解，可能随着图形界面的提出， 软件的可见性能够得到很大程度的改善吧。

似乎，作者提出的这些问题40年后仍然没有得到解决， 对抗软件复杂性和可变性一个比较好的方式是快速原型，然后不断迭代。