喜欢理论结合实践，这次的 Hackathon 大赛的项目开发，其实是人月神话一个很好的试验田。对下面几个点有一些感受： 1. 焦油坑，程序员认为职业的乐趣远大于苦恼，因为创造和解决问题的过程带来的满足感是巨大的。 2. 外科手术队伍 3. 系统设计中概念完整性的重要性。一个优秀的系统应该有一致的设计理念，就像由一个人设计的一样。集中决策（贵族专制）和分散决策（民主政治）在系统设计中的利弊。 《人月神话》的目录主要分为多个章节，涵盖了软件工程和项目管理的各个方面。以下是书中的主要章节内容： ## 焦油坑 - 编程系统产品 - 职业的乐趣 - 职业的苦恼 软件开发是一项复杂的工作，类似于艺术创作，需要高度的创造性和技术能力。程序员的职业生活中既有乐趣，也有苦恼。 乐趣包括： - 创造性：软件开发是一种高度创造性的工作，程序员可以通过编写代码来创造新的产品和解决方案。 - 团队合作：程序员可以与同事讨论问题和解决方案，与其他角色合作，共同完成项目。 - 持续学习：软件开发的非重复性带来不断学习新知识的乐趣，程序员需要不断更新自己的技能和知识。 - 创造有用的东西：开发对他人有帮助的产品带来满足感，程序员可以通过自己的工作来改善他人的生活。 - 问题解决：程序员可以享受将复杂问题分解并解决的过程，通过自己的努力来克服挑战。 - 自动化：程序员可以创造能提高效率的工具，通过自动化来简化工作流程。 苦恼包括： - 追求完美：软件开发要求极高的精确度，这可能带来压力，程序员需要不断地检查和测试自己的代码。 - 依赖他人：开发人员常常依赖他人提供的资源和信息，这可能导致挫折，程序员需要与其他人合作来完成项目。 - 调试困难：寻找和修复bug是一项耗时且有时枯燥的工作，程序员需要耐心和细心来解决问题。 - 时间和资源限制：在有限条件下寻找解决方案的挑战，程序员需要在有限的时间和资源下完成项目。 - 快速变化：技术的快速发展要求不断学习和适应，程序员需要不断更新自己的技能和知识来跟上行业的发展。 尽管存在这些挑战，许多程序员认为职业的乐趣远大于苦恼，因为创造和解决问题的过程带来的满足感是巨大的。 ## 人月神话 - 乐观主义 - 人月 - 系统测试 - 空泛的估算 - 重复产生的进度灾难 软件开发者往往对项目进度持乐观态度，低估了项目的复杂性和可能遇到的困难。这种乐观主义常常导致不切实际的时间估算。 人月是一个危险的概念，它假设人力和时间可以简单互换。实际上，增加人手并不能线性地缩短项目时间，反而可能因沟通成本增加而延长进度。 这句话出自 Fred Brooks 的著名著作《The Mythical Man-Month》，其中最著名的论点就是 "Brooks's Law"： 原文是： "Adding manpower to a late software project makes it later" 即："向进度落后的项目中增加人手，只会使项目更加落后" Brooks 解释这个现象的主要原因： 1. 新人培训和沟通开销： - "The added burden of communication and training" - 新成员需要时间学习项目 - 现有成员需要花时间培训新人 1. 任务拆分的限制： - "Some tasks are not partitionable" - 并非所有任务都能有效地分解和并行化 1. 沟通成本增加： 原文中有个著名的公式： "If each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2" 意思是：如果任务的每个部分都必须与其他部分协调，那么所需的工作量会按照 n(n-1)/2 增长，其中 n 是人数。 另一句经典原文是： "Nine women can't make a baby in one month" （九个女人不能在一个月内生一个孩子） 这个比喻用来说明某些任务是无法通过增加人力来加速完成的。 Brooks 在书中还提到： "The bearing of a child takes nine months, no matter how many women are assigned" （生孩子需要九个月，不管安排多少个女人） 这本书的核心观点就是：软件项目中人力和时间不是简单的线性关系，增加人手可能会因为带来额外的沟通和协调成本，反而降低效率。 ### 外科手术队伍 - 问题 - Mills的建议 - 如何运作 - 团队的扩建 "外科手术队伍"这一章节主要讲述了一种高效的软件开发团队组织方式，其核心思想如下： 1. 问题： - 指出最好和最差的程序员效率可以相差10倍之多[1]。 - 传统的"一拥而上"的开发方法成本高而效率低[1]。 2. Mills的建议： - 提出了"外科手术式队伍"的概念，与传统方式相反[1]。 - 由一个核心人员（类比外科医生）完成问题的分解，其他人给予支持[1]。 3. 如何运作： - 强调一个强有力的技术/项目领导的重要性[1]。 - 这种模式下，技术主管通常作为总指挥，形成类似外科手术队伍的结构[1]。 4. 团队的扩建： - 对于大型项目，小型精干队伍可能进度缓慢[1]。 - 通过外科手术式的队伍组织，可以在保持高效率的同时完成巨大的工作量[1]。 这种组织方式强调核心技术人员的作用，同时通过合理的团队结构来提高整体效率和质量。 ## 贵族专制、民主政治和系统设计 - 概念的完整性 - 获得概念的完整性 - 贵族专制统治和民主政治 这一章节主要讨论了软件系统设计中的概念完整性及其实现方式，以及在项目管理中如何平衡集中决策和团队参与。主要内容包括： 1. 概念的完整性： - 强调了系统设计中概念完整性的重要性。 - 指出一个优秀的系统应该有一致的设计理念，就像由一个人设计的一样。 2. 获得概念的完整性： - 提出了由一个首席设计师或小型核心团队负责系统的整体设计。 - 强调了清晰的系统架构和接口定义的重要性。 3. 贵族专制统治和民主政治： - 比较了集中决策（贵族专制）和分散决策（民主政治）在系统设计中的利弊。 - 建议在关键设计决策上采用"贵族专制"方式，以保持概念完整性。 - 同时强调在实现细节和具体问题解决上，应该鼓励团队成员的创造性和参与度。 ## 画蛇添足 - 结构师的交互准则和机制 - 自律——开发第二个系统所带来的后果 1. 结构师的交互准则和机制： - 强调结构师应该与开发人员保持良好的沟通。 - 结构师应该尊重开发人员的创造性，只提供建议而不是命令。 - 结构师应该准备好为自己的建议提供实现方法，但也要接受其他可行的方案。 - 结构师应该保持低调和平和的态度，愿意放弃一些自己的想法。 - 结构师应该倾听开发人员关于架构改进的建议。 2. 自律——开发第二个系统所带来的后果： - 指出第二个系统通常是设计者所设计的最危险的系统。 - 设计者在第二个系统中往往倾向于过度设计，添加过多的功能和想法。 - 以OS/360为例，说明了过度设计带来的负面影响。 - 建议为功能分配优先级，使用字节和微秒作为衡量标准，以避免过度设计。 ## 贯彻执行 - 文档化的规格说明——手册 - 形式化定义 - 直接整合 这一章节主要讨论了软件开发过程中如何贯彻执行设计决策和规格说明。主要内容包括： 1. 文档化的规格说明——手册： - 强调了详细文档化系统规格说明的重要性。 - 手册作为开发团队的指导文件，确保所有成员理解并遵循统一的设计标准。 2. 形式化定义： - 提倡使用正式的方法和语言来定义系统规格。 - 形式化定义有助于减少歧义，提高系统设计的精确性。 3. 直接整合： - 强调将设计决策直接整合到开发过程中的重要性。 - 确保设计理念在实际编码和实现过程中得到贯彻。 这一章节强调了在软件开发过程中，从设计到实现的一致性和连贯性。通过详细的文档、形式化的定义和直接的整合，确保软件架构和设计决策能够被准确地传达和执行，从而提高开发效率和软件质量。 ## 没有银弹 - 根本困难 - 以往解决次要困难的一些突破 - 针对概念上根本问题的颇具前途的方法 虽然没有"银弹"能一劳永逸地解决所有问题，但一些方法被认为有潜力缓解根本困难： 1. 软件复用：利用已验证的构件组装新系统，提高质量和效率 2. 分而治之：将复杂问题分解为简单问题逐个解决 3. 逐步演进：采用小步快跑的开发策略，不断调整和优化 4. 优化折中：平衡各种质量特性，实现整体最优 这些方法虽然不能完全消除软件开发的根本困难，但可以帮助开发者更好地应对挑战，提高软件开发的效率和质量。 1. **20年后的《人月神话》** - 核心观点——概念完整性和结构师