The Mythical Man-Month 读书笔记

The Mythical Man-Month 读书笔记

The Mythical Man-Month被翻译成了《人月神话》，初看此书名，还以为是神话故事，再加上去图书馆借书时发现这本书摆放在XX北馆四楼（社会科学图书库），还以为自己检索错了。当找到书之后，看到了醒目的蓝色封面，在封面上同时有中英文书名，还配有小字“40周年中文纪念版”和著者Brooks，才确定这就是我要找的The Mythical Man-Month的中文译本。

借到这本书之后，先浏览了这本书的三篇序和目录。三篇序依次是清华大学博士王计斌(Dave Wang)写的代序，Brooks写的20周年纪念版序言以及第一版序言。从王博士和Brooks自己的序言里就可以感受到软件工程一直面临严峻的问题，以及这本小册子的博大精深。这本小册子历经20年，40年，甚至到2018年的今天，一直继续流行，作者传达的观点和工程经验仍值得思考和借鉴。其实小册子是王博士的叫法，我借到的这本译本有369页，完全没法称呼小册子。翻阅目录发现，其实除了正文，有近五十页的附录，附录大多是对正文的书评。与书名一样，每章的中文标题也充满了神话色彩，这使我更加好奇正文里到底写了什么神奇的故事。

这本书我花了大约一周的空闲时间才读完，包括书评。书中前15章分别从编程问题、时间进度、团队组成、任务分配等不同角度分享了软件开发遇到的问题以及相关经验和解决之道。16章没有银弹 和17章 再论“没有银弹” 是对软件工程中出现的困难的原因探究，不断的思考何为根本问题，何为次要问题，进而探寻是否存在解决之道。18章内容是对第一版《人月神话》，也就是本书前15章的浓缩。19章20年后的《人月神话》增补了一些对软件工程新的思考，对书中以前一些思考的对错进行阐述和纠正。以下是我从Brooks前15章表达的内容里获得的经验知识：

编程问题之“焦油坑”：编程系统软件（Programming System Product）是真正有用的产品，是大多数系统开发的目标，但是编程系统软件的成本却出奇的高，是简单程序的9倍。编程可以带来创造新事物的快乐，也会被bug折磨，甚至有时在付出大量辛苦劳动之后发现产品显得过时。

时间进度之“人月神话”：人月之所以是神话，是因为人月作为衡量一项工作的规模是危险的和带有欺骗性的。增加人员未必会减少开发时间，人员的加入会增加更多的沟通工作量。沟通包括培训和相互交流，恶劣情况下，增加的沟通负担会超过任务分解产生的作用。作者认为所有的编程人员都是乐观主义者，而缺乏合理的进度安排是是项目之后的主要原因。

团队组成之“外科手术团队”：编程人员的水平相差很大，人员增加沟通又会增加工作量，出于效率和概念的完整性考虑，最好有小而精干的队伍设计和开发。但是对于大型系统团队，“外科医生-副手”团队架构从效率、概念的完整性和开发周期而言，才是可取的。“外科医生”从上到下进行所有的设计，一丝不苟的专注于体系结构。

任务分配之“专制民主”：产品既要考虑成本和性能，也要实现易用性的目标。易用性通常需要结构师（外科医生）实行“贵族专制统治”来实现，而成本性能很大程度依靠实现人员，实现小组施行“民主统治”，发挥小组的创造性。

混淆责任分工之“画蛇添足”：结构师和开发人员要明确自己的任务分工。对于结构师，第二个系统往往是自己所设计的最危险的系统，原因通常会倾向于过度设计，画蛇添足。

一致性之“贯彻执行”：对于大型团队，设计结构要确保一致性。体系结构的定义应至少有两种以上的实现，如使用形式化定义和记述性定义，必须选用一种作为标准，一种辅助来加深理解。独立的产品测试小组是保证一致性贯彻执行的必要保证。

导致“巴比伦塔”失败的交流和组织：巴比伦塔为什么会失败？一是缺乏交流，二是缺乏交流的结果——组织。大型项目中的交流有非正式途径、会议和工作手册。工作手册应包括目的、外部规格说明、接口说明、技术标准、内部说明和备忘录，对于团队交流至关重要。良好的团队组织的目的是要减少交流和协作量。

对生产率要“胸有成竹”：系统编程如何工作量如何估计？Brooks有两条忠告，一是仅仅通过对编码部分的估计，然后应用之前推荐的比率（计划进度、编码、构件测试和系统测试的比率），是无法得到对整个任务的估计的；二是，构建独立小型程序的数据不适用于编程系统产品。Brooks对比多份数据，认为对于常用的编程语句，生产率似乎是固定的，而且如果使用高级语言，编程的生产率会提高数倍。

规模(内存)之“削足适履”：规模是软件系统产品用户成本中很大的一个组成部分。开发人员必须设置规模的目标，控制规模，考虑减小规模的方法。在空间预算角度，Brooks分享了两个技巧：用功能交换尺寸和考虑“空间-时间”的折中。数据的表现形式是编程的根本。

文档之“提纲挈领”：为什么要用正式的文档？1、书面记录决策是必要的；2、文档能够作为同其他人的沟通渠道；3、项目经理的文档可以作为数据基础和检查列表。项目经理的任务是制定计划，并实现计划。只有书面计划是精确的和可以沟通的，而且通过遵循文档开展工作，项目经理能更加清晰和快速的设定自己的方向。

面对变化之“未雨绸缪”：“实验工厂”的存在，就是为了舍弃而计划的。变化是与生俱来的，所以要为变更设计系统，为变更计划组织架构，考虑程序维护带来的副作用。系统软件开发是减少混乱度（减少熵）的过程，而软件维护是提高混乱度（增加熵）的过程。

资源分配之“干将莫邪”：项目经理应该制定一套策略，为通用工具的开发分配资源，同时还必须考虑专业工具的需求。

自上而下之整体部分：好的自上而下的设计可以从下面四个方面避免bug:1、清晰的结构和表达方式更容易对需求和模块功能进行进行精确地描述；2、模块分割和模块独立性避免了系统级的bug；3、细节的抑制使结构上的缺陷更容易识别；4、设计在每个精化步骤上都是可以测试的，所有测试可以尽早开始，而且每个步骤的重点可以放在合适的级别上。

计划控制之“祸起萧墙”： 项目一天一天的进度落后是难以识别的、不容易防范和难以弥补的。所以控制大型项目，需要制定严格的进度表，而且不能让里程碑成为沉重的负担。如何让里程碑发挥积极作用，就需要一线经理与老板减少角色冲突和鼓励状态共享。老板最好区分“状态检查”会议和“问题—行动”会议。

自文档化之另外一面：Brooks提出的“合并文档”，即将文档整合到源程序，这能保证编程用户方便、及时地得到文档资料。这种程序被称为自文档化（Self-Documenting）。在线系统的高级语言应该使用的工具中，自文档化发现了它的绝佳应用和强大功能。

如果参与过软件项目，一定会对Brooks前15章的内容有较多的体会，深知软件工程是一个庞大、复杂而又抽象的实体。Brooks在No Silver Bullet（《没有银弹》）的讨论中，用“人狼”（werewolf）来形容软件项目的一些特性，来讨论到底有没有消灭“人狼”的“银弹”。Brooks从技术为核心的角度把软件活动分成了根本任务和次要任务。根本任务是打造构成抽象软件实体的复杂概念结构。现在软件系统中存在着复杂度、一致性、可变性和不可见性这些无法规避的内在特性。这些特性决定着软件开发的根本困难,Brooks对银弹的存在一直持怀疑态度，认为目前的一些突破只是在解决次要困难。到底有没有银弹，Cox从人为核心的角度，得出了：银弹是存在的，只不过是软件思维的变迁（paradigm shift），而不是技术（technology）。两位大师的出发角度不同，得出的结论相异，孰优孰劣，以我对软件浅显的理解，不妄加评论。但是，出于我对软件工程美好的期望，如果存在必然是好事。

在 20年后的《人月神话》部分，Brooks思考着又经过的20年软件的发展，对自己对软件工程的见解重新回顾和反思。Brooks认为，构造舍弃原型的建议是错误的，原因在于太过于简单化了；增量开发模型有独特的优点；Parnas对于信息隐藏的见解是对的。20年的发展，微型计算机普及了，软件产业也发生变革了，软件构件的使用逐渐流行了。软件工程在不断发展，但Brooks认为焦油坑将会继续存在很长时间，软件工程面临的根本困难仍然没有突破。

这本《人月神话》从1974年第一版到现在2018年，已经过去44个春秋，仍然在软件行业继续流行着。足以见得，有价值的思想经久不衰。最后，希望软件工程继续发展，不断有所突破。

2018.09.23

参考文献：

[1]Frederick P. Brooks, Jr. 著; 汪颖 译. 人月神话[M]. 北京:清华大学出版社.2015