《人月神话》读书笔记

一、书名和作者

书名为二十周年纪念版 《人月神话》，是一本由美国计算机科学家弗雷德里克·布鲁克斯（Frederick P. Brooks）所著的经典书籍。

二、书籍概览

2.1 主要论点和结构

本书的主要论点在于由于人员的分工，大型编程项目碰到的管理问题和小项目区别很大，关键需要是维持产品自身的概念完整性，并探讨了大型编程项目开发其中的困难和解决的方法。文章结构由前十六章内容以及后面的四篇短文组成，前十六章主要就大型编程项目中可能会遇到的各种困难以及解决办法，后面四章分别是短文“没有银弹：软件工程的根本和次要问题”、“再论《没有银弹》”、“《人月神话》的观点：是或非？”以及“20年后的人月神话”，就软件工程的根本问题做了阐述，并对前文做总结，并且就软件工程的未来做了预测和规划。

2.2 目标读者和应用场景

本书的目标读者是软件开发人员、软件项目经理、系统分析师、软件工程专业的学生以及相关领域的研究人员乃至任何软件开发行业的从业人员。本书内容的应用场景包括任何涉及软件开发和项目管理的环境和场景，无论是大型企业、初创公司，还是教育机构，都可以从中获得有益的知识和经验教训，以提高软件项目的成功率和效率。

三、核心观点与主题

3.1 人员组织管理主题

• 子观点1：外科手术团队

同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。小型、精干队伍是最好的——尽可能的少。两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

• 子观点2：贵族专制、民主政治和系统设计

概念完整性是系统设计中最重要的考虑因素，功能与理解上的复杂程度的比值才是系统设计的最终测试标准，而不仅仅是丰富的功能。为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。如果要得到系统概念上的完整性，那么必须控制这些概念。这实际上是一种无需 任何歉意的贵族专制统治。一个架构师也许还有少量的结构师，代表客户，对团队(实施人员)实行专制统治，从而才能产生概念一致，功能完备且系统的，能够得到客户满意度的产品。

• 案例：Apple的iPhone团队

在21世纪初，苹果公司启动了iPhone的开发项目。史蒂夫·乔布斯亲自策划了这一项目，并聚集了一支小而精干、高度专业化的团队，包括了资深架构师、杰出的设计师以及卓越的工程师。这个团队的卓越特质在于其专制的领导方式和对概念一致性的极致追求，这两者共同推动了一系列备受欢迎的iPhone产品问世。这些产品不仅令市场为之瞩目，也成为了智能手机领域的颠覆性力量。

3.2 项目时间进度管理主题

• 子观点1：人月神话

缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。导致项目落后的深层次原因是所有的编程人员都是乐观主义者：“一切都将运作良好”，由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难。但是，程序员的构思是有缺陷的，因此总会有 bug。围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。这也是著名的Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。

• 子观点2：祸起萧墙

慢性进度偏离是士气杀手。一天一天的进度落后比起重大灾难，更难以识别、更不容易防范和更加难以弥补。为此，我们应该根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。

• 案例：IBM OS/360操作系统开发

IBM OS/360项目是20世纪60年代初期IBM公司启动的一个重大操作系统开发项目。该项目旨在创建一款通用操作系统，可在多种IBM计算机上运行，以满足不断增长的计算需求。该项目在开始时设定了严格的时间表，以满足市场需求并赶超竞争对手。IBM公司认识到计算机市场的重要性，因此时间进度被认为至关重要。OS/360项目的规模庞大，涉及多个子系统和组件，需要协同工作。这增加了项目管理的复杂性。尽管IBM OS/360项目面临了重大的时间进度管理挑战，但最终该项目成功完成。

3.3 项目成本风险管理主题

• 子观点1：未雨绸缪

对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之，系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤。 将开发的第一个系统——丢弃原型——发布给用户，可以获得时间，但是它的代价高昂——对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。 “开发人员交付的是用户满意程度，而不仅仅是实际的产品。”，用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的需求变更。为变更计划软件产品的技术，特别是细致的模块接口文档——非常地广为人知，但并没有相同规模的实践。尽可能地使用表驱动技术同样是有所帮助的。

• 子观点2：避免画蛇添足

尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。

• 案例：操作系统360开发

操作系统360对于大多数设计者来说，是第二个系统。它的设计小组成员来自1410-7010磁盘操作系统、Stretch 操作系统、Mercury 实时系统项目和 7090 的 IBSYS。几乎没有人有两个以上早期操作系统的经验 。因此，OS/360 是典型的第二次开发（second-system effect）的例子，是软件行业的 Stretch 系统。但是从某种角度而言，正如Strachey的锐评：“它是一个产品线的终结。如同早期的计算机程序一样，它极富有创造性，极端复杂，非常高效。但不知为什么，同时也感觉到粗糙、浪费、不优雅，以及让人觉得必定存在某种更好的方法”

3.4 软件工程内在本质

• 子观点1：软件工程中的根本问题和次要问题

软件的特性本身导致了不大可能有任何的发明创新——能够像计算机硬件工业中的微电子器件、晶体管、大规模集成一样——提高软件的生产率、可靠性和简洁程度。甚至不能期望每两年有一倍的增长。现代软件系统中这些无法规避的内在特性：复杂度、一致性、可变性和不可见性。复杂性，没有哪两个软件是一模一样的，复杂是软件的根本特性。一致性，大型软件开发中，界面、接口常常会不一致，并且随着时间的推移会变得越来越不一致。易变性，软件构成的因素随时都在变化。不可见性，程序是看不见的，即使用图示方法，也难以充分表现其结构，使得人们沟通面临极大的困难。

• 子观点2：没有银弹

软件开发总是非常困难的，天生就没有银弹。软件领域中取得的最富有成效的三次进步，但是每一次都是解决了软件构建上的巨大困难，但是这些困难不是本质属性，也不是主要困难。没有银弹能够解决这些根本困难，但有一些途径去改善他们：使用新技术，比如高级语言、快速开发原型。做增量开发，而不是采用线性的瀑布模型。聘用人才，寻找卓越的人，并给他们最优厚的待遇。

• 案例：面向对象编程

面向对象编程提出了类和对象的概念过去常被很多人认为是软件工程真正的银弹，抽象数据类型和层次化类型的出现都消除了开发过程中的非本质困难，允许设计人员表达自己设计的内在特性，而不需要表达大量句法上的内容，这些内容并没有添加什么新的信息。对于抽象数据类型和层次化类型，它们都是解决了高级别的次要困难和允许采用较高层次的表现形式来表达设计。不过，这些提高仅仅能消除所有设计表达上的次要困难。软件的内在问题是设计的复杂度，上述方法并没有对它有任何的促进。除非我们现在的编程语言中，不必要的低层次类型说明占据了软件产品设计 90％，面向对象编程才能带来数量级上的提高。

四、亮点与启发

4.1 最有影响的观点

《人月神话》这部书对我影响最大的观点在于对于软件工程的内在本质的分析论述，书中指出了现代软件系统中这些无法规避的内在特性：复杂度、一致性、可变性和不可见性，是软件工程领域的根本问题。因此软件开发总是非常困难的，天生就没有银弹。这不仅引发了我对类似chatgpt等大模型是否是真正的银弹的深度思考，在chatgpt问世之初，chatgpt强大的能力一度引发了我的恐慌，觉得以chatgpt为代表的大模型犹如银弹一定会颠覆自然语言工程领域。例如大模型帮老年人操作软件、大模型对话订机票软件等等。但是通过阅读本书后，我意识到大模型依然无法解决软件工程的根本问题，并且当真正面对终端用户时，昂贵的费用、缓慢的计算速度、画蛇添足的功能等问题导致大模型甚至都不是最优解法。

4.2 对个人专业发展的启示

软件开发不仅是一项技术活动，更是一项涉及沟通、协作、创造、变化等多方面因素的复杂活动。读完《人月神话》这部经典著作，我对软件开发的过程和困难有了更深刻的认识，软件开发需要有合理的计划、有效的组织、灵活的调整和持续的改进。此外，我还对软件设计的重要性和原则有了更清晰的理解。书中强调了软件设计的概念整体性，认为这是软件系统成功与否的关键因素，通过这本书，我还对软件维护的难度和策略有了更多的思考，针对软件维护中遇到的各种问题，如需求变化、错误修复、结构破坏等，可以通过预留变更空间、制定变更计划、重构代码等方式来解决。

五、批评与局限性

5.1 可能存在争议或过时的信息

（1）“《人月神话》的观点：是或否”一章中提到的：库中的每个组件需要有两个版本，运行速度较快和短小精炼的。但是现在已经有很多优秀的版本管理工具，故该观点可能已经是过时的。
（2）“银弹的希望”一章中列举的技术依旧停留在过去，没能与时俱进。
（3）“胸有成竹”一章中以当年的统计数据给出结论：如果以先前提到的编码大约只占了开发时间的六分之一左右，用编码时间乘以六以预估开发周期其错误可能会导致不合理的荒谬结果。该章节数据均来自以前的汇编语言时代，与现在差距较大。
（4）“削足适履”这一章主要是讲程序大小的，包括代码大小和内存占用的大小。但是代码大小现在应该已经不是软件开发中最重要考量。

5.2 可能的不足或缺陷

（1）作者认为软件开发是一种艺术而非科学，需要依赖个人的创造力和直觉。但随着软件工程的发展和成熟，已经出现了许多科学化、标准化、工具化、自动化的方法和技术，可以提高软件开发的质量和效率。
（2）这本书的内容主要是基于作者在IBM的项目管理经验，可能不适用于其他类型和规模的软件开发项目。例如，敏捷开发、开源开发、分布式开发等，都有自己的特点和挑战，需要根据具体情况进行调整和优化。

六、实际应用和拓展

6.1在实际工作学习中应用这些概念的方法

在实际的大型软件项目开发中看，要格外注意项目的规模和复杂性，避免在项目中过度分工。确保团队之间的有效沟通和协作，以减轻沟通成本。要构建高效的项目团队，倾向于外科手术队伍的模式，选择专业、有经验且高效的成员。软件设计时，要避免过度设计和添加不必要的功能，注重项目的核心目标，不要画蛇添足。最后，还要制定明确的项目计划和提纲，同时在项目初期进行风险管理，未雨绸缪，降低不确定性。

6.2 对未来研究实践的建议

学习项目管理的最佳实践，例如使用项目管理工具和方法，了解敏捷、Scrum等项目管理框架。学习和实践敏捷开发方法，这些方法在应对变化和灵活性方面具有优势，是当前软件开发领域的主要趋势之一。了解新兴技术和工具，如云计算、人工智能、区块链等，以适应不断变化的软件开发环境。

七、总结与评价

7.1 整体评价

《人月神话》绝对可以算是软件工程领域的经典之一，某种程度上，《人月神话》是关于人与团队的书，具有持久的价值。该书强调了许多软件开发项目中常见的挑战和困难，并提供了有关如何解决这些问题的深刻见解。书中的观点基于弗雷德里克·布鲁克斯多年的实践经验，因此具有高度的可信度和实用性。此外，该书引经据典，语言十分诙谐，在保证通俗易懂的前提下还能持续输出深刻的观点，是一部难得的经典佳作。

7.2 长处和短处

（1）该书的长处在于提供了关于软件开发和项目管理的深刻见解，强调了人员分工、沟通成本、项目计划等关键问题。书中提供了大量的实用建议和方法，帮助读者更好地管理和组织软件项目。这些建议可以直接应用于实际工作中，对提高项目的成功率有着非常大的帮助。
（2）该书的缺点在于有些观点可能过时且未涵盖新兴技术。尽管《人月神话》提供了许多宝贵的观点，但其中的一些观点和案例是基于20世纪的情境和技术，不一定适用于今天的软件开发环境。因此，一些内容可能已经过时，且书中未涵盖现代软件开发中的新兴技术和方法，如敏捷开发、云计算和人工智能等。这使得该书对于处理这些新领域的项目管理挑战的能力有限。