初读醍醐灌顶，读罢怅然若失——《人月神话》随感——By Zhe Song

软件工程这门课除了指定的教材外，我们还被要求额外选定一本参考书。我选择的是Frederick P. Brooks的《人月神话》。

早就听说过这本书的大名了。之前在一些互联网学习社区、计算机大牛学长的博客上都见到过推荐书单，多是名家经典，推荐给初学者入门学习，也推荐给不算高手、不算初手的中手们苦练进阶。《人月神话》就常常出现其中。被评价为，“将技术书写成散文集，把经验教训和经历背景等一一道来”。比较惭愧的是，在学校时就曾经两次把这本书从图书馆借出来，遗憾的是都没有读完，只是明白了本书的名字并不是人类和月球之间的神话故事，而是软件工程的一些迷思，人月是一个人一个月的人力单位。

这次从中关村图书大厦买来这本书，下决心一定要读完。这篇文章就读书中的一些体会和留下深刻的观点记录下来，并加以分析。经典的书目以后还要读更多次，随着项目经历的不断丰富，每次读来肯定都会有新的体会。

一．软件工程的时间分配

作者提出软件工程中各个项目的比例应该如下：

1/3 planning

1/6 coding

1/4 component test and early system test

1/4 system test, all components in hand

出乎我的意料，本来以为编程时间应该成为软件开发中最耗时的部分，事实上却是相反的，编程时间被分配了最少的时间。软件项目团队被建议，使用三分之一的时间对项目进行各种规划、设计，实际的编程时间并不是主要时间部分，余下一半时间被用来进行各种测试，检测、排除软件中的各种问题。这也许就是现实中软件工程和我们平时小打小闹写程序最大的区别，规范的规划、操作，配套的文档，严谨全面的测试阶段，科学的时间任务管理。即使我们在现实中做不到那么专业，较早学到这些意识也是很好的。

二．人多一定力量大吗？

举一个例子，假如一个三个人的团队在项目截至还有两个月的时候的发现还有四个月才能完工。也就是说现在只有三个人，两个月，只有6个人月的人力资源，却又12个人月的任务需要完成。

怎么办呢，看来需要人来增援他们了。好的，公司决定，分派两个新人过来。事实上，新人来了之后是要培训的还有熟悉项目的。假设一个老员工接下来一个月的任务也是培训他们，那么这个月过去只有2个人月的任务被完成，然后我们有6个人面对10人月的任务。还是会超时，而且由于现在是5个人，我们需要把任务重新分成5份，原来的一些工作会白做了，整个系统测试的时间也会被增加。

Brooks提出一个定律：

“给一个进度落后的软件项目团队中增援更多的人力，只会将进度拖后更多”

我们的软件工程团队项目在正式开始开发后不久，有两个同学加入。一些其他团队的同学非常羡慕，作为看过《人月神话》的PM的我马上就意识到，要客观看待人手增加这个问题。确实我们增加的人手将确保更强劲的生产力，成员之间的沟通成本、组织成本也随之增加。幸运的是，我们在开发伊始就迎来的新成员，对后面的开发负面影响并不大。

三．外科手术式团队

学校中做大作业有一种“抱大腿”的传统，就是人们往往喜欢找到编程能力很强的同学结成团队完成作业，抱着的是“打酱油”的心态。有时候“大腿们”并不情愿，经常“打酱油的”们也真的打了“酱油”。事实上这种团队就具备了外科手术式团队的雏形，团队由一个技艺非常高超的人带领，其他人作为助手、副手、后勤的身份积极协同作战。如果运作的好，也将成为一个愉快工作、各司其职、共同成长、效率非常高的团队。

四．银弹之问

首先要介绍一下银弹的出处，今天中午还在和同事一起查阅银弹的概念。

人狼是传说中的妖怪，只有银弹才能杀死他。Brooks提出观点，软件项目具有人狼的特性，比如软件项目时而会变身变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。银弹呢就是攻克软件工程难题的良方，或者叫高招、杀手锏也可以。

现实是有点残酷的，Brooks通过从复杂性、一致性、可变性、不可见性等方面论述软件的银弹本来就不会存在。的确，软件工程和其他工程作业有太多特殊的地方。电子计算机这个革命性发明就有一个特点，它有太多太复杂的状态集了。操控计算机的程序们注定了不同于其他人造产品的特殊性质。每段代码都要有人工手写，往往在完成之前人们很难对它有准确的估计，随着用户、硬件、市场的发展，软件也要随之改进，其改变的周期要比其他人造产品短了很多。

在过去的几十年里，软件开发的效率大大提升，这要归功于高级语言、分时系统、集成开发环境等技术的发明和广泛应用。然而这些发明并没有改变软件开发的主要流程和复杂度等主要问题，被解放出来的程序员们又要接受新技术环境下的挑战。

银弹一致时许多高瞻远瞩的贤才所追求和忧心的，不过真正的那枚银弹一致没有被人类所得到。幸运的是，即使没有银弹，我们还是有其他可以做的事来提升软件开发效率和质量。

比如说，将开发非核心的任务外包，或者购买成熟的软件产品作零件；提炼需求和敏捷开发；增量开发；培养雇用优秀的设计师。