人月神话读后感

　　　中国科学技术大学软件学院   闫松山  原创作品版权所有转载请注明出处

　　孟老师在高级软件工程课程上为我们推荐了八本专业方面的课外读物，我选择了这本人月神话。最初主要是因为这本书有一个有趣的名字，还有一些有趣的标题，如焦油坑，外科手术队伍，贵族专制等。在大致浏览了一下该书后，基本上发现这本书讲的是一些软件项目开发与管理中所经常遇到的问题。

         作者在第一章中指出，过去几十年大型系统的开发就像焦油坑一样，虽然各种各样的团队通过各种努力开发出可运行的系统，但只有很少的项目可以满足目标、时间进度和预算的要求。作者还介绍了编程的快乐和烦恼。编程的乐趣主要是创造的乐趣、学习的乐趣。而其烦恼是难以达到完美，必须付出艰苦的劳动，项目似乎总是倾向于推迟完成，最可怕的是产品还未完成就可能已经过时了。作者将为解决这些困难在本书其他章节为大家提出自己的建议。

         认为大项目只是增加足够的程序员就能顺利完成，已经对于已经推迟的项目，只要增加人手就能按期完成的看法是错误和危险的，因为它假定人和月是可互换的，而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。Brooks提出：给推迟的软件项目增加人手将使得项目更加推迟。作者同时在本章指出应该谨慎对待弥漫在编程开发中的乐观主义，估算的不可靠行和重要性以及早期策划时应该分配给系统测试足够的时间。

         作者在外科手术队伍这一章中讨论了在软件开发中组织一只什么样的团队比较合适。好的程序员与差的程序员的生产力可能相差10倍以上，所以一个小规模的精锐的团队要比一个大的却有很多平庸的程序员的团队要好得多。一个两人的团队，其中一个作为领导者，通常是最好的使用脑力的方式。但是，对于真正大的系统，小规模的团队开发速度又太慢，难以满足需求。这时，一个主程序员，就像手术团队中只有一名主刀医师的模式是很好的模式。Harlan Mills建议一个团队包括主程序员另外配一名副程序员（与主程序员分享设计，并且代替主程序员于一般程序员、工具制造者、测试人员、语言律师交流）、一名管理员（管理钱、人、机器等）、一名编辑（修改、评价主程序员写的文档），管理员与编辑都配一名秘书。主程序员只与副程序员、管理员和编辑交流，这样就大大减少了主程序员与其他人的交流量。 

         作者首先通过法国兰斯的大教堂指出建筑师们牺牲了自己的创意，保持了教堂风格的一致性和完整性。作者借此引出在软件开发过程中概念一致性的重要性。概念的完整性要求设计必须由一个人，或者少数互有默契的人来实现。概念完整性要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。作者指出专制只是体现在软件体系结构上的，而这并不会限制具体实现中创造和发明的机会，相反创造性活动会因为规范化而得到加强。

         项目经理应避免画蛇添足，他必须坚持至少有两个系统以上的开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议不能支配。

         巴别塔项目失败的原因缺乏交流和组织。缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构，及时更新，每个人都可以看到。良好的组织可以减少所需的交流量。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。

         准备估计一个编程项目的工作总量并制订进度表是很难的，因为很难根据编码时间来估算整个项目需要完成的时间。建造小系统的数据不能应用到大型系统上。据研究，若按基本语句来计算，软件的生产率基本是个常数，其原因是每个人的思考速度基本上是个常数。相比低级语言，使用一种合适的高级语言可以使生产率提高5 倍。 

         软件编写者必须设定软件大小的目标，控制大小，设计减少大小的技巧。在大的项目中，分小组通常只考虑自己小组的目标的实现，而不顾对用户的影响。因此的实现的整个过程中，系统架构师必须时刻保持警惕，保证系统的完整性。为完成一个完整的系统，保持用户取向的态度是编程经理最重要的功能。另外还有时间-空间权衡的问题，为使空间-时间协调，整个小组要进行编程技巧的培训。但是精巧的快的程序几乎都是由战略上的突破产生的而不是战术上的聪明。 

         计算机产品的主要文档包括目标（需求、需要的东西、限制、优先级）、规范（计算机手册和性能规格）、进度表、财务预算、组织结构图、空间、预测、估算、价格等。正式的文档是非常重要的：首先，将决定写下来是至关重要的，只有当一个人将自己的想法写下来的时候，不确定性、不一致性才可能凸显出来。其次，有了写出来的文档，才可能与别人交流你的决定。最后，经理的文档给他一个数据库和一个检查清单，根据正式的文档，他才会知道自己身在何处。

         作者提出在计划时最好就应该决定把第一个系统丢弃，因为第一个构建的系统几乎都不可用。如果直接把它抛给客户会让用户觉得痛苦，并且设计者在重新设计时会分心。另外用户的目标和需求是会改变的，所以在设计时就应该准备改变。设计可变化系统的技巧包括模块化，好的子程序，模块之间全面的接口定义以及所有这些的全面文档。组织也应该能应对变化。所有的计划、里程碑和时间表都应该是有弹性的，以应对变化。

         在软件开发过程不仅需要通用的工具，还需要个性化的工具，最核心的问题是交流。使用高级语言编程可以提高生产力和调试速度，一般的反对意见（能干我所干的事、目标代码太大、目标代码太慢）都是难以成立的。交互式编程也可以提高生产力。

         概念完整性与产品精确定义是关键的；结构化编程是必要的；构件应该进行单独的测试，之后再进行集成测试；修改时应控制变更规模。

         里程碑应该明确定义以防止产生隐瞒；使用PERT图指示对进取的需要；老板不应与一线经理产生角色冲突，而应使用能了解状态真相的评审机制，计划和控制小组在这一过程中很有价值。

         用户需要文档来帮助他们使用（目的、环境、IO范围、功能算法、指令、选项、运行时间和精度检验）、验证和修改程序；流程图的使用与维护都很麻烦，已经过时；自文档化技术是一种非常有效的解决方案。

         软件开发所不可规避的困难在于复杂度、一致性、可变性和不可见性；尽管高级语言、分时系统、IDE在编码过程中帮了程序员的大忙，但他们无助于解决内在困难；高级编程语言、面向对象技术、人工智能、专家系统、自动编程、图形化编程和更快的工作站都无助于问题的根本部分；有希望缓解根本问题的是：购买软件、快速原型技术、增量开发和卓越的设计人员。

读完本书后， 感触虽然不是太深，也许是目前自己开发经验不足，在此方面体会不是太深，但是仍然觉得讲的很有道理。本书作者为人们管理复杂项目提供了高深的见解，既有很多发人深省的观点，也有大量的软件工程实践。