《人月神话》阅读笔记01

1 什么叫“人月神话”？

“人月”是指一个人在一个月中完成的工作量。理论上，如果一个任务需要两个人工作一个月，或者一个人工作两个月，都可以用“2人月”来表示。然而，Brooks指出，这种简单的线性关系在实际的软件开发中并不总是成立。
“人月神话”的核心观点

增加人力不一定能加快进度：

Brooks定律：向已经延迟的项目增加人手，会使项目更加延迟。这是因为新加入的成员需要时间来熟悉项目背景、代码库和技术栈，而现有团队成员也需要花费额外的时间进行培训和支持。

沟通成本的增加：

随着团队规模的扩大，成员之间的沟通复杂度呈指数级增长。更多的人员意味着更多的沟通路径，这会导致效率下降，反而拖慢项目的进展。

任务分解的难度：

并非所有的开发任务都可以轻易地分解为多个独立的部分并行处理。某些任务本质上是顺序依赖的，必须按特定顺序完成，无法通过增加人力来加速。

质量控制的挑战：

增加人员可能会引入更多的错误和不一致，尤其是在不同成员对项目理解不一致的情况下。因此，项目的整体质量和稳定性可能会受到影响。

2 焦油坑

过去几十年的大型系统开发就犹如一个焦油坑，很多大型动物在其中剧烈挣扎，他们中大多数开发出了可运行的系统--不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。
各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢且很难看清问题的本质。

3 外科手术队伍

小型、精干队伍是最好的--尽可能的少。需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果系统调试。
所以建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。
一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法--既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

4 贵族专制、民主政治和系统设计

为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
同工作的水平分割相比，垂直划分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅提高。

5 画蛇添足

一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地推迟了。
实际情况中，尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法--挑战估算的结果

6 贯彻执行

即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。
对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜测一边工作，这是一项很基本的措施。

7 为什么巴比伦塔会失败？

巴比伦塔
项目的失败是因为缺乏交流，以及交流的结果--组织。
"因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。
随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定，而因此给其他部分引发了BUG。
解决方案：
团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。举行常规项目会议，会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。制定项目工作手册，并实时记录
变更：首先，必须在页面上标记发生改变的文本，例如，使用页边上的竖线标记每行变化的文字。第二，分发的变更页附带独立的总结性文字，对变更的重要性以及批注进行记录。

8 胸有成竹

编码大约只占了问题的六分之一左右，编码估计或者比率的错误可能会导致不合理的荒谬结果。
对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。
使用适当的高级语言，编程的生产率可以提高5倍。

9 削足适履

在大型的团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。
为了满足目标，每个人都在局部优化自己的程序，很少会有人停下来，考虑一下对客户的整体影响。
培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。

10 提纲挈领

如果要制造一台机器，哪些是关键的文档呢？
目标：定义待满足的目标和需要，定义迫切需要的资源、约束和优先级。
首先，书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。项目经理常常会不断发现，许多理应被普遍认同的策略，完全不为团队的一些成员所知。每个文档本身就可以作为检查列表或者数据库。
项目经理的基本职责是使每个人都向着相同的方向前进。项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。
通过周期性的回顾，他能清楚项目所处的状态，以及哪些需要重点进行更改和调整。

11 未雨绸缪

变更的客观需要
对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。
用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的需求变更。
目标上（和开发策略上）的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。
为变更计划组织结构
当系统发生变化时，管理结构也需要进行调整。只要管理人员和技术人才的天赋允许，老板必须对他们的能力培养给予极大的关注，使管理人员和技术人才具有互换性。
为什么缺陷不能更彻底地被修复？
首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级别的问题，通常这不是很明显。
设计实现的人员越少、接口越少，产生的错误也就越少。
所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。用在修复原有设计上瑕疵的工作量越来越少，而早期维护活动本身的漏洞所引起修复工作越来越多。
随着时间的推移，系统变得越来越无序，修复工作迟早会失去根基 ，尽管理论上系统一直可用，但实际上，整个系统已经面目全非，无法再成为下一步进展的基础。
机器在变化，配置在变化，用户的需求在变化，所以现实系统不可能永远可用。崭新的、对于原有系统的重新设计是完全必要的。