《人月神话》书评

中国科学技术大学软件学院 彭家德 原创作品转载请注明出处

       人月神话这本书不涉及具体的程序需开发语言，而是从软件开发过程管理的角度来论述如何提高软件开发效率，对于几乎没有参加过实际的软件开发项目的博客作者来说，读起来想要有深入的理解还是很困难的，只能考从平时做小项目的经验和一些常识性逻辑性的推测来理解其中的很多概念，不过，我依然觉得这本书读完之后收获很大，在此之前，我对于一个项目的理解从来没有超出过程序和应用之类的概念范围，软件项目的管理对于我来说是空泛而遥远的。在现在的软件工程的课程中，即使是到了研究生阶段，依然很少有学生会接触到大型的软件项目，管理的问题不会那么突出，一个小的软件项目的好坏往往决定于小团队中核心技术人员的水平和眼界，倘若之前参与过一个必须把管理问题上升到台面上的问题，我想，我对于这本书中作者的提法会有更深刻的理解。现在的软件工程中的很多学生都在努力成为一名变成高手，当然，这些是必须做的，我也在朝着这个方向努力，但似乎觉得这些还不够，单纯说编程能力，进公司努力码两年代码总会提高的很快，何苦来费钱费力上这一个研究生，更何况软件研究生的学历也不能说明什么。《人月神话》这本书让一直低头拉车的我自觉的开始抬头看路。读了软件工程的研究生，不出意外地话毕业或者说现在就是一名程序员，第一年做的就是上课、做项目，在科大这里，所说的项目，小的是课程的大作业，大一点的是工程实践，再大就是实验室中的大一些的项目，在第二年实习之前，人月神话中所提到的问题几乎都不会遇到或者体会的到，当然，除了第一张说的职业的乐趣和苦恼。《人月神话》提供给程序员的是一中更为宽广的事业，更确切的说，是给软件工程师提供一种更为宽广的视野。

     说了这么多空泛的总结，我们回到《人月神话》这本书，我最喜欢得是这本书的第一章对职业的乐趣和苦恼的描述和焦油坑、银弹这两个词。作者说“编程是一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。”编程确实是一种乐趣，我从编程中获得的乐趣几乎可以和我从游戏中获得乐趣相比，我没有想过编程是在改变世界，编程却是在改变自己，随着写的程序越来越多，自己的思维方式也在发生着变化，我还没有办法描述这种变化，但我知道这些变化却是存在着，至少我现在在排队的时候一不小心就会想到队列，听到树这个词想到的就是数据结构中的树，当然，这些只是思维表面的东西，或者说是条件反射。编程也是苦恼的，我讨厌熬夜，希望有一个健康的生活方式，可是程序总是有bug，而我解决bug最高效的时间往往是在0点之后，世界安静下来的时候，这个时候头脑特别清晰，而且考虑问题的过程不会轻易被打断，避免了重新思考带来的精力开销。但是问题来了，是睡觉明天多花点时间解决问题还是解决bug明天多睡一会儿呢。

    《人月神话》的第二章中提到了Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。这是一个神奇的问题，之前我的思维一直是人多好办事，当然，前提是管理好，不至于出现三个和尚没水吃的窘境。按照我的理解出现这一问题的原因是招募新的人手进来时重新进行培训要耗费大量的时间，后面，在20年之后的人月神话中，提到了关于Brook法则的一些新的结论，比如在《软件项目动力学：一条完整的路》这本书中，作者通过实验得出这一结论“向进度落后的项目中添加人手总会增加项目的成本，但并不一定会使项目更加落后。”Stutzke也成功测试了他的模型，即在项目延期之后加入新的成员而不影响项目的原来的进度，但是作业视乎仍然坚持这一法则，认为上面的结果只是对这一法则的渐进，这一法则仍可以作为项目经理在项目出现延期之后增加人手的参考。

   在第三到六章中，作者给出了对于团队建立、概念设计和贯彻执行的建议。对于小型队伍，最好是选取少数能干和有开发经验的程序员而不是更多的能力一般的程序员，但是对于大型项目，小型精干队伍的开发速度又显得太慢了，若采用一拥而上的办法，仍然不可行。对此，神话的作者拿出了Mills的建议，即大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。并且，神话中将软件开发团队成员及其职责类比到外科手术队伍，并给出了运作和团队扩建的意见。神话的作者十分强调软件设计过程中概念的一致性，提出为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成，这样就可以确保概念的一致性和完整性，作者似乎没有过多的考虑概念的优化和改进，而是尽量避免这些，即宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计，这是不是类似于我党的思想上的统一战线。神话的作者提出了一个很有趣的说法，第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计，中国的老祖宗对此估计就想说一句话，娃儿，过犹不及啊。项目在具体的贯彻执行过程中，需要有明确的手册，这一点深表认同，即使是几个认得小团队，也要分清每个人的职责，先明而后不争。

    我不知道芭比伦塔为什么会失败，看了神话作者的几个文句，我马上就明白了。对于大型项目的完成，管理的作用绝对是最大的，在这一章中神话的作者给出的大型项目中组织和交流的意见，对于交流，是需要靠会议和工作手册来实现，而项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构，项目所有的文档都必须是该结构的一部分，这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。而团队组织的目标是为了减少必要的交流和协作量，具体方法是人力划分和限定职责范围。对于大型团队，技术主管和产品负责人不能是同一个人，要明确各自的职责，技术主管负责技术，产品负责人负责对外的交流和沟通。

   在胸有成竹一章中，神话的作者讨论了软件开发工作量估计的问题，并且列出了一些人的实验和结论。在规模控制中，神话的作者认为规模控制既是管理工作的一部分又是技术工作的一部分，仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。并且，神话的作者认为数据的表现形式是编程的根本，这个有点深奥，不太懂。在提纲掣领中，神话的作者又谈到了文档的重要性，既是实在现在Scrum开发过程中，依然强调文档是非常重要的，虽然不是最重要的。并给出计算机产品的文档、计算机科学系的文档和软件项目文档应该包含的内容。之后讨论了为什么要有文档，首先，书面记录决策是必要的；第二，文档能够作为同其他人的沟通渠道；最后，项目经理的文档可以作为数据基础和检查列表。未雨绸缪中，神话的作者认为第一个开发的测试系统往往是不能用的，在开发第一个系统的同时，就需要着手第二个系统的设计，程序维护中的一个基本问题就是缺陷修复总会以20%到50%的概率引入新的bug，所以现实的系统不可能永远可用，基于原有系统的重新设计是完全有必要的，这就是未雨绸缪。

  不再说了，最后，说一说没有银弹，不从技术层面考虑，想想软件工程做的事情的覆盖面就知道真的没有银弹，人们常常将软件开发同汽车制造进行类比，个人觉得这个类比的不太恰当，现在的软件开发设计到各个行业，生活中的各个方面，就像实体制造业一样，这样的类比就如同将实体制造业同车载系统的开发进行类比。 汽车的生产就相当于一款软件的复制，实际效果就是这样，只是汽车的生产有实物的消耗，软件的复制只消耗电量而已。  神话的作者在20年前断言没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。在之后出现了一些技术比如面向对象，基于构建的开发，确实使软件开发的过程得到简化，但仍没有人没期望的那么快，人工智能是一个可能的解决方案，但是从七十年代至今，仍没有出现真正意义上的人工智能，我们只能期待出现一种新的技术或者管理方法使得软件开发的效率得到提高，但这种提高绝对不是像银弹之于人狼一样有效。我觉得，如果未来的某一天真的有银弹的话，那就是人工智能程序员。但是这个需要做的还有很多，首先是需要机器有像人一样的理解能力，能够理解所要解决的问题的本质，然后是让其掌握一门语言（机器语言除外），懂得算法的思想，再有项目的经验，这对于一个天生就有人工智能的人来说都不容易，何况是机器。

   最后，总结一下，《人月神话》强调组件一个像外科手术队伍一样的开发团队，强调文档的重要性，瀑布模型是没有用的，增量和迭代开发才是重要的。《人月神话》就像是一个方法论，即使现在编程工具和开发环境如何变化，大型项目开发过程中的基本原理是不会变的，就像几千年前古人写的富含哲理的文章，现在读起来依然觉得很有道理，虽然现在生活方式和那个时代的已经是天差地别。《人月神话》的作者在书中说了很多的IBM 的OS/360是一个失败的系统，但是神话中的大部分内容是基于这个失败的系统总结过来的，在我们平时的小项目中，我们是不是也能把失败的原因抽象出来呢？