读《人月神话》后我对开发效率的重新理解

《人月神话》是 1968 年的作品，站在今天回看，大部分技术细节已经过时，但它对”为什么软件项目会延期”的洞察，几乎全部命中。

人月是个神话

书里最著名的论断：向一个已经延期的项目增加人手，只会让它更延期。

原因不是人不够聪明，而是沟通路径数量随人数平方增长：

n 人的沟通路径 = n × (n - 1) / 2

  3 人 → 3 条
  6 人 → 15 条
 10 人 → 45 条

这是我见过的最简洁的协作成本公式。很多团队规模化的直觉失误，都源于低估了这条曲线的陡峭程度。

概念完整性

Brooks 强调：系统的概念完整性比单点的精妙更重要。一个由十个聪明人各自主导一部分做出来的系统，往往不如一个人统一设计、各人分工实现的系统好用。

这个判断在组件化的时代依然成立——设计系统的价值不在于复用组件，而在于约束了设计的自由度。

没有银弹

书的后半部分在找”银弹”，最终没有找到。Brooks 的结论是：软件困难的部分本质上是概念结构难，而不是实现难。

这个结论在 2026 年依然没被推翻。我们有了更强的 IDE、更快的框架、更多的库，但面对一个全新领域的建模问题时，依然要在纸上把概念理清楚。

三条最实用的

1. 乐观估计是系统性偏差，不是个体失误——留缓冲比追求准确更有用
2. 文档和代码同样重要，但”为写而写”的文档是负资产
3. 第二次做某件事的成本远低于第一次，但前提是你真的从第一次里学到了东西

值得反复读的书不是给你新信息，而是给你一套更好的提问方式。