一本写于 1975 年的书
《人月神话》（The Mythical Man-Month）是 Fred Brooks 根据他主导 IBM OS/360 开发的经历写成的。那是 1964 年，离 GitHub 的诞生还有 44 年。
然而这本书里的观点放在今天，仍然刺痛人心。
核心论点：人月不可互换
书名来自软件行业最根深蒂固的谬误：“这个项目延期了，加人就能追回来”。
Brooks 的反驳简洁有力：
“向一个已经落后的软件项目增加人手，只会使它更加落后。”
这就是著名的 Brooks 定律。
为什么？因为软件开发不像搬砖——新人需要培训时间，而且增加人手会增加沟通成本。
如果一个团队有 n 个人，沟通路径的数量是 n(n-1)/2：
- 3 人团队 → 3 条沟通路径
- 5 人团队 → 10 条沟通路径
- 10 人团队 → 45 条沟通路径
人数翻倍，沟通路径增加 4 倍。这些沟通本身就会消耗大量时间。
没有银弹
Brooks 后来补写的章节”没有银弹”（No Silver Bullet）同样振聋发聩：
“在未来十年，没有任何单一的软件工程进展，能够使生产率提高一个数量级。”
他区分了软件复杂度的两种来源：
- 本质复杂度（Essential Complexity）：问题本身固有的难度，无法消除
- 偶然复杂度（Accidental Complexity）：我们引入的工具、语言、流程带来的难度，可以优化
大多数技术进步——高级语言、IDE、框架——只是在减少偶然复杂度。但本质复杂度始终存在，这正是软件依然难做的根本原因。
外科手术式团队
Brooks 提出了一个反直觉的团队结构：与其用 10 个平均水平的程序员，不如用 1 个顶尖程序员加上支持他的几个辅助角色。
这和我们今天说的”10x engineer”遥相呼应。但 Brooks 强调的不只是个人能力，而是减少接口、保持概念完整性：
“概念完整性是系统设计最重要的考量因素。”
一个人脑子里的设计，比 10 个人委员会讨论出来的设计，往往更一致、更优雅。
第二个系统综合症
有趣的心理现象：程序员第一个系统往往因为经验不足，反而简洁克制。到了第二个系统，信心大增，把所有”第一次没敢加”的东西全塞进去，结果做成了大而复杂的怪物。
这不是 50 年前的问题。看看多少开源项目 v2 重写把 v1 的简洁全丢掉了？
今天还有什么意义？
读完这本书，我的体会：
- 进度估计要诚实：软件估时的艰难不是因为程序员懒惰，而是不确定性本质上难以量化
- 小团队更高效：Spotify、Amazon 的”two-pizza team”原则，本质上就是 Brooks 几十年前说的
- 警惕复杂度积累：每加一个依赖、每多一个抽象层，都在增加偶然复杂度
- 文档是系统的一部分：Brooks 花大量篇幅讲文档，因为代码只解释”怎么做”，不解释”为什么”
“乐趣在于做出东西……痛苦在于，要做出别人真正需要的东西，而不只是自己觉得有趣的东西。”
这句话值得每个工程师贴在显示器旁边。
书籍信息： 《人月神话》，Fred Brooks，1975 年初版，推荐读带”没有银弹”章节的 20 周年纪念版。
Comments