编程神作《人月神话》

骨灰级的经典书籍。1975 年的作品，1995 年再版，到如今再次读来，依然还是受益匪浅。

| 讲的是什么？ 

《人月神话》是一本讲软件工程的书。书中几乎探讨了所有与之相关的内容。包括进度管理、团队搭建、人员交流、文档编写等，不可谓不全面。而书中也有很多有意思的比喻，十分让人喜欢。

| 有趣的比喻

我们先从比喻说起。书中用焦油坑，来类比大型项目里，很多程序员的感受。渴望施展拳脚，却只能在焦油坑里挣扎。是不是很形象？而对于催进度方面，书中使用了厨子的比喻。就如做菜一样，总是需要时间的，催的着急了，可以说快了，但最终上菜的时间，其实和一开始估算的，没什么区别。书中还有很多这种类比，每篇都有一两个，有些还配了插图，有兴趣的话，都可以看看。

| 到底什么是人月神话

好了，让我们来解密什么是人月神话。当然，不是讲一个人和月亮的神话故事。人月其实是个评估工时的指标。比如，一个人干一个月。那为什么说是神话呢？这是因为，由于项目开发的复杂性，10 人 3 月的开发周期，很难简单地换算成 30 人 1 月。新人的加入，会增加很多培训成本和沟通成本，而任务本身在次序上的约束，也导致了不能用简单的方式分解。所以，通过人月直接换算工期，是个不存在的神话。当然，这个老先生认为解决不了的问题，让聪明的中国人解决了。就是让这 10 个人死命加班，凌晨也不睡觉，干死拉倒。

| 概念完整性

书中感慨于兰斯大讲堂在整体完整性上的美感。几百年建设的大教堂，前后经历了八代建筑师，他们牺牲了自己的一些创意，以获得更纯粹的整体设计上的完美。软件工程与此类似，由于总是多人合作完成的，在概念完整性上，不统一的问题也尤为突出。软件项目，本身的一个大目标，就是要让系统变得更容易使用。而每个人的个性发挥，会让系统变得极其混乱。事实也证明，现实中的很大一部分 bug，特别是不容易被发现的部分，都是和开发人员间概念不一致有关。牺牲个人个性，换取整体的一致性美感，这才是一个优秀的程序员该有的信念。

| 组织构建

书中建议我们把设计工作和实现工作分开。这样，设计工作由一个专业人士完成，能很好的保证概念完整性。我们常说的架构师，大致就是这种职位。书中还提供了外科手术式的团队构建理念。一个优秀的人，带一些相对普通的技术，配合他完成工作。现在很多公司的小组方式，本质上也应该是此种构成。书中也明确了组织的本质：“因为交流才出现的组织”，这个需要你细细品味。当然，设计和实现的分离，会让有些人觉得没有价值。书中的观点是，设计工作和编码实现的工作，其实都有很多不一样的挑战。

| 银弹理论

“没有银弹”的论点，就是这本书的作者提出的。他在大约 30 年前，做了一个大胆的预测：在未来一段时间内，并没有像有解决狼人的银质子弹那样，会出现一种单独的技术进展，能让软件工程的生产率，有数量级的提高。这主要是因为，软件工程的主要困难是设计，而实现只是其次要困难。我们不可避免地要面对软件设计上的复杂度、一致性、可变性和不可见性。而这些并没有看到，类似“银弹”的技术出现。诚然，现今 AI 发展迅猛，作者也在 1997 年就谈到了 AI 辅助编程。但目前来看，AI 解决的还是次要问题，并没有很强的能力，解决主要困难。当然，作者的观点貌似有些悲观。但当你阅读过原文的话，可能会有不一样的体验。

| 写在后面的话

书中多是作者做大型软件项目的经验之谈。基础量级都是 5000 人年的系统。而对于互联网项目来说，很显然太过重型了。不过软件开发，大同小异。书中每一章节所讨论的问题，都值得你去仔细思考；而每一章节的内容，也会对你有不小的启发。