《人月神话》(Fred Brooks, 1975)是那种每隔几年就该重读一次的书——因为书里的每个教训,都会在你最新的项目里换一身衣服重新出现。这篇笔记只抓四个仍然锋利的点。

一、布鲁克斯定律:人月是神话

向进度落后的项目增加人手,只会让进度更加落后。

原因在于两点:沟通成本随人数平方增长(n 人的项目有 n(n-1)/2 条沟通通道),以及新人需要老成员付出培训成本。一个延迟两个月的项目加一倍的人,通常延迟更久。

现代变体:分布式团队 + 异步协作没有消除这条定律,只是把沟通成本从"开会"换成了"文档、评审与等待"。评估一个团队的真实产能,先数它的沟通拓扑,再数人头。

二、第二系统效应

设计师的第二个系统最危险:第一个系统学会了克制(因为不熟),第二个系统则想把之前没做上的所有想法全部塞进去——过度设计由此而来。

对照现实:多少 V2 重构死在"顺便把架构升级了"上。解法是 Brooks 给的:把炫技的冲动留给第三个系统,第二个系统只做减法。

三、概念完整性:宁可独裁,不可民主

概念完整性是系统设计中最重要的考虑。

Brooks 主张外科手术式团队:一个首席架构师拥有设计决定权,其他人负责实现——因为"好设计出自少数头脑"。这政治不正确,但统计上正确。今天的对应物是:RFC 流程可以民主,决策必须收敛到一个人。所有设计都委员会投票出的系统,通常每个模块都平庸。

四、没有银弹

软件的本质复杂性不会因为任何单一技术突破而消失。

十年一个轮回:当年是 CASE 工具、面向对象,今天是低代码、AI 辅助编程。它们都真实地提升了偶然复杂性那一半的效率——AI 写样板代码的能力确实惊人。但需求澄清、概念设计、取舍决策这些本质复杂性,依然是人的工作。判断一项新技术的真实价值,先问它砍的是哪一半。

札记

  • 焦油坑的比喻:大型系统开发是焦油坑,野兽和恐龙都在里面挣扎——保持敬畏
  • 文档不是负担,是"给未来的自己的减震器"
  • Brooks 的职业生涯本身就是论据:IBM System/360 + OS/360 的总架构师,写出的是失败与成功交织的复盘——最好的工程书都来自真实伤疤

一句话总结:这本书讲的不是如何构建软件,而是如何接受软件构建是一个本质上困难的人类活动。