《人月神话》读书笔记

《人月神话》一书是作者Frederick P. Brooks, Jr.博士在IBM开发OS/360的经验之作，为无数从事软件工程相关工作的人提供了理论和实践基础。

该书的作者认为相比于其他行业的大型工程，管理大型的计算机编程项目与之既有较大的相似性，也有独特性。该领域的知识在于累积。需要考虑到控制程序中设计和执行上的缺陷、内存和成本与原计划的差别等。

由于人员的分工，大型编程项目遇到的管理问题和小项目遇到的管理问题区别很大，而关键在于维持产品自身的概念完整性。

一、编程系统产品

程序本身是完整的，可以由作者在所开发的系统平台上运行；编程产品可以被任何人运行、测试、修复和扩展，可以在多种操作平台上运行，供多套数据使用。并且，要成为通用的编程产品，程序必须按照普遍认可的风格来编写，尤其是输入的范围和形式必须广泛地适用于所有可以合理使用的基本算法。接着，还要对程序进行彻底测试来确保其稳定性和可靠性，这就意味着必须准备、运行和记录详尽的测试用例库，用来检查输入的边界和范围。此外，要将程序提升为程序产品，还需要有完备的文档，每个人都可以加以使用、修复和扩展。编程系统是在功能上能相互些许哦、具有规范的格式、可以进行交互的程序集合，并可以用来组装和搭建整个系统。要成为编程系统构件，程序必须按照一定的要求编制，使输入和输出的语法和语义与精确定义的接口一致。同时程序还要符合预先定义的资源限制——内存空间、输入输出设备、计算机时间。最后，程序必须同其他系统构件单元一道，以任何能想象到的组合进行测试。由于测试用例会随着组合不断增加，所以测试的范围必须广泛。因为一些意想不到的交互会产生许多不易察觉的bug，测试工作将会非常耗时，因此相同功能的编程系统构件的成本也大于独立程序。而只有编程系统产品是大多数系统开发的目标和真正有用的产品，同时也具有更高的成本。而调试和查错往往是线性收敛的，甚至具有二次方的复杂度。

产品开发基于的技术在不断地进步，概念应当避免陈旧，而实际产品需要一步一步按阶段实现。实现落后与否的判断应根据其他已有的系统，即在实际的进度和有效的资源范围内寻找解决问题的切实可行方案。

二、软件项目管理

软件项目需要合理的进度安排，要有效地进行估算，对进度与工作量充分了解，对进度进行跟踪和监督。并且，作者认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话，人员数量和时间并不可以相互替换。

对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。因此，在相同人月的前提下，采用增加人手来减少时间得到的最好情况，还是比未调整之前差一些。

软件开发本质上是一项系统工作——错综复杂关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省的个人时间。从而，添加更多的人手，实际上是延长了而不是缩短了时间进度。

作者根据多年的经验法则，总结出一套软件任务的进度安排：

1/3时间用于计划，1/6时间用于编码，1/4时间用于构建测试和早期系统测试，1/4时间用于系统测试，完成所有的构件。相比于传统的进度安排方法，软件任务分配给计划的时间、对所完成代码的调试和测试投入近一半的时间，这些比平常的多，而对于容易估计的部分（如编码）则只分配了1/6的时间。

在软件开发过程中，为了满足顾客期望的日期而造成的不合理进度安排十分普遍。而且，非阶段化方法的采用，过少的数据支持，加上完全依赖于软件经理的直觉，这样的方式很难生产出有力的、看似可靠的和规避风险的估计。而我们需要开发并推行生产率图标、缺陷率图标、估算规则等，使得整个小组从共享性上获益。

除去了神话色彩的人月的Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。可以从这两个数值推算出进度表。在软件项目中，合理的进度安排比其他所有因素加起来的影响都还要大。

需要协作沟通的人员数量影响者开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的系统调试问题等不良结果。Harlan Mills建议大型项目的每一个部分由一个团队解决，但该队伍用类似外科手术的方式组建，即由一个人完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。

作者认为，在系统设计中，概念完整性应该是最重要的考虑因素。为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。

在预算方面，尽早交流和持续沟通能使结构师有较好的成本意识，也能使开发人员获得对设计的信心，且不会混淆各自的责任分工。结构师应当牢记应由开发人员承担创造性和发明性的实现责任，结构师只能建议，而不能支配；应当低调且不公开地时刻准备着为所指定的说明提出一种实现的方法，并能够接受其他任何能达到目标的方法；做好放弃对改进建议的坚持的准备。

软件产品需要有文档化的规格说明——手册，它是产品的外部规格说明，描述和规定了用户所见的每一个细节，同样，它也是结构师主要的工作产物。规格说明的风格必须清晰、完整和准确。

在大型编程项目中，团队应当通过非正式途径、会议和工作手册等进行彼此之间的交流沟通。项目工作手册是对项目必须产出的一系列文档进行组织的一种结构，这些文档包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。大型的编程项目同样需要良好的组织架构，通过人力划分和限定职责范围来减少交流，这些组织与架构分为任务、产品负责人、技术主管或结构师、进度、人力的划分、各部分之间的接口定义等。

数据表明，对常用编程语句而言，生产率似乎是固定的，包括需要注释并可能存在错误的情况；而使用适当的高级语言，编程的生产率可以提高5倍。

软件项目的文档应当包括目标、产品技术说明、进度、资金预算、工作空间分配和人员组织图。正式的文档的存在是必要的，书面决策更加清晰，可以作为同其他人的沟通渠道，也可以作为数据基础和检查列表。

软件开发人员必须设立规模目标，控制规模，发明一些减少规模的方法。

文档的负担应当降到最小，可以借助那些处于语言的要求必须存在的语句来附加更多的信息（如标签、声明语句和符号名称等），尽可能使用空格和一致的格式来提高程序的可读性，加入段落注释。

三、软件维护

在系统需要变更时，最重要的是使用高级语言和文档技术，以减少变更引起的错误。而软件发布后的变更称为“程序维护”，软件维护主要包括对设计缺陷的修复，它通常包含了更多的新增功能，这些通常是用户可以察觉的。

程序维护有一个基本问题——缺陷修复总会以固定20%-50%的几率引入新的bug。很多很微小的错误并不是局部操作的失败，而是系统级别的问题，通常这不是很明显的；并且，维护人员常常不是编写代码的开发人员。基于对统计模型的研究，Belady和Lehman得到了具有普遍意义、为所有经验支持的结论“事物在最初总是最好的”。系统软件开发是减少混乱度（减少熵）的过程，它本身是处于稳态的，软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

在思考软件任务时，应当仔细地进行市场调研，避免开发已上市的产品；在获取和制定软件需求时，将快速原型开发作为迭代计划的一部分；有机地更新软件，随着系统的运行、使用和测试，逐渐添加越来越多的功能；不断挑选和培养杰出新生代的概念设计人员。

四、没有银弹

大家熟悉的软件项目具有一些人狼的特性，常常看似简单明了的东西却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。然而，软件的概念结构、复杂度、一致性、可变性、不可见性等特性在根本上决定了没有银弹的存在。“没有银弹”是软件工程中的根本和次要问题。目前创新式的最先进的技术有Ada和其他高级编程语言、面向对象编程、人工智能、专家系统、“自动”编程、图形化编程、程序验证、环境和工具、工作站等。而针对概念上根本问题的颇具前途的方法有购买和自行开发、需求精炼和快速原型、增量开发而非搭建系统，以及卓越的设计人员。