人月神话解读与感受

   

    在研究生期间我们的课程设置中有一门必修课程是软件工程，其中有一个作业是读人月神话并写一篇读后感。虽然我本科的专业是偏向于网络工程，并且我们也开设过软件工程这门课。但是对于像我这样的二流选手，在本科期间基本没有认真学习，并且在大二后半年（2013.8月份）就开始接触学习编程，但真正通读过的编程书籍还是比较少的，所以这次还是鼓起勇气抽时间把这本软件工程中的巨著粗读了一番。言归正传，其实作者在这本书中“《人月神话》的观点：是或非？”部分对本书进行了高度的概括，我想还是过一下我自己的大脑，接下来谈一下我个人的感受吧！

    其实整本书分为16个部分我们还是按照每部分进行解读，以防我们遗漏了某些知识从而造成我们一些思想的空白。

第一章焦油坑

    本书的第一章是焦油坑，在开始部分主要是介绍了系统产品比独立构件开发难度大很多，接着表达了我们在编程过程的乐趣在于不断的学习新的知识以及创造出对别人有用的产品，最后也说出了我们的苦恼在于追求完美但又在依赖于别人的源码中煎熬！

第二章人月神话

    本书的第二章是人月神话，该部分主要是讲述了人员数量和项目时间进度的辩证关系。其中大家熟知的Brook法则：像进度落后的项目中增加人手只会使进度进度更加落后，这主要的增加的这部分人员需要与别人进行沟通交流，这其中会消耗很长的时间。

第三章外科手术队伍

    本书的第三章是外科手术队伍，首先作者肯定了小型精干队伍是最好的，但是这样的队伍开发大型系统太慢了，接下来作者提出了解决的办法就是外科手术队伍即由一位首席程序员来对系统进行整个产品的架构，其他多位程序员来进行协助工作，就是分工明确，各在其位各尽其能。

第四章贵族专制、民主政治和系统设计

    本书的第四章是贵族专制、民主政治和系统设计，该部分主要是讲解了概念完整性在系统设计中的重要作用。贵族专制统治提供概念完整性这并没有扼杀了小组实现的创造性反而可以促进系统开发和测试的速度。另外作者提出了体系结构（ architecture）、 设计实现（ implementation）、 物理实现（ realization）
的许多工作可以并发进行的观点。

第五章画蛇添足

    本书的第五章是画蛇添足，在这部分作者主要说明了结构师和开发人员之间的责任分工。结构师必须为每一种建议准备一种实现方法，但不要过多的参与开发人员在实现的创造性，也应该虚心听取开发人员对体系架构的建议。在这个章节中作业也暗示了第二个系统是人们所设计的最危险的系统，希望设计者不要过多的注重装饰，不要由于做作而使系统很危险。

第六章贯彻执行

    本书的第六章是贯彻执行，在这个部分中作者主要讲述的是在系统开发过程中沟通的问题。即使是对于大型的设计团队也应该由一个或两个骨干对系统的整体架构做一致性的决策以保证概念的完整性。接着作者提及了文档的规格说明，以及形式化定义记叙性定义一者作为标准另一种作为辅助的关系。最后阐述了结构师与实现人员以及项目经理和测试小组之间应有的合适关系和沟通方式。

第七章为什么巴比伦塔会失败？

    本书的第七章是为什么巴比伦塔会失败？作者一上来就提出了这么一个发人思考的问题，并给出了正确的答案就是就是缺乏交流，于是引出了本章的重点那就是组织。一个是项目工作手册，即对项目必须产生的一系列文档进行组织的一种结构，前面先提及了每一个团队成员应该了解所有的材料，后面又讲解了每个人看到每件事的目标是错误的，我们只需了解接口，这是解决灾难的处方。另一个是组织架构，团队组织的目标是为了减少必要的交流和协作量，然而传统的树状结构（权利结构的原理）是不友好的，应该调整为网状结构这样可以克服交流缺乏的困难。最后作者认为每个子项目应该具有两个领导角色，一个产品负责人另一个技术主管或结构师，这两个角色的任意组合是非常有效的。

第八章胸有成竹

    本书的第八章是胸有成竹，作者开头就否定了对整体项目的精确估计不能通过对编码部分的估计乘以任务其他部分的相对系数。之后通过几个例子说明了生产率的问题，也提出当使用适当的高级语言时，程序编制的生产率可以提高 5 倍。

第九章削足适履

    本书的第九章是削足适履，该部分主要讲解了程序对宝贵内存的精心利用与多磁盘访问次数的控制，这主要依赖于局部优化、用户体验、时间空间的折衷、编程技术的积累、新型算法和数据的表现形式。

第十章提纲挈领

    本书的第十章是提纲挈领，本章主要讲述了项目经理应该在项目早期规范化的一系列提纲挈领的文档，其中软件项目的关键文档包括目标、用户手册、内部文档、进度、预算、组织结构图和工作空间分配。另外还强调项目经理的主要日常工作是沟通， 而不是做出决定； 文档使各项计划和决策在整个团队范围内得到交流。

第十一章未雨绸缪

    本书的第十一章是未雨绸缪，作者首先讲述了将开发的第一个系统——丢弃原型——发布给用户对用户、开发人员和产品都是一种摧残，接着主要解说了三个部分，第一部分是为变更计划组织架构，该部分主要说明老板应该极力培养技术和管理之间自由分配的人手，对于两条晋升线的高效组织机构建立同等的威信的比较困难的，组建外科手术队伍式的软件开发团队是对上述问题所有方面的彻底冲击，但这的确是一个长期行之有效的解决方案。第二部分是前进两部，后退一步--程序维护，这部分主要是讲解了程序维护的困难以及一些技巧，即在每次修复之后， 必须重新运行先前所有的测试用例， 从而确保系统不会以更隐蔽的方式被破坏。能消除、至少是能指明副作用的程序设计方法，对维护成本有很大的影响。同样，设计实现的人员越少、接口越少，产生的错误也就越少。第三部分是前进一步，后退一步--系统熵随时间的变化，这部分主要说明了系统的复杂度，即模块数随着系统版本号呈线性增加而影响的模块以版本号的指数增加，所有的修改都使系统更加复杂，增加了系统的混乱程度。

第十二章干将莫邪

    本书的第十二章是干将莫邪，在这一部分中主要讲述了一套通用工具的开发分配资源应该由项目经理制定，系统调试大部分在夜间完成，一次分配给某个小组连续的目标时间块是最好的安排方法，自顶向下、 彻底地开发一个性能仿真装置应该尽早开始等观点。接着说明了高级语言应用广泛提升了生产率改进了调试。最后提及了系统软件开发中交互式编程的生产率至少是原来的两倍。

第十三章整体部分

    本书的第十三章是整体部分，在这一部分作者首先强调了精确定义整体部分的重要性，在编写任何代码之前， 规格说明必须提交给测试小组， 以详细地检查说明的完整性和明确性，以及说明了Wirth 的自顶向下进行设计新型软件开发方法，但我们的思想也不能被其禁锢，有时必须回退，推翻顶层设计，重新开始。开发大量的辅助调试平台（ scaffolding 脚手架） 和测试代码是很值得的。必须有人对变更进行控制和文档化。系统测试期间，我们应该一次只添加一个构件。

第十四章祸起萧墙

    本书的第十四章是祸起萧墙，这一章节作者先讨论了项目延迟是难以识别、 更不容易防范和更加难以弥补的。进取是软件开发团队比不可少的必要品德。PERT 的准备工作是 PERT 图使用中最有价值的部分。 它包括了整个网状结构的展开、 任务之间依赖关系的识别、 各个任务链的估计。 这些都要求在项目早期进行非常专业的计划。接着论述了老板和经理之间的对决。最后强调了评审机制和里程碑报告的重要性。

 第十五章另外一面

    本书的第十五章是另外一面，主要讲述了文档在整个软件开发中发挥的重要角色。文档能在整个生命周期对克服懒惰和进度的压力起促进激励作用。将文档合并至源程序是至关重要的。程序修改人员所使用的文档中， 除了描述事情如何以外， 还应阐述它为什么那样。对于加深理解， 目的是非常关键的，但即使是高级语言的语法，也不能表达目的。

20年后的人月神话

    最后一部分就是20年后的人月神话，这一部分的核心观点是概念完整性和结构师。概念完整性即我们必须给用户提供一个条理分明的概念模型， 这个模型描述了应用、 实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。结构师负责产品所有方面的概念完整性， 这些是用户能实际感受到的。 主结构师开发用于向用户解释使用的产品概念模型，概念模型包括所有功能的详细说明以及调用和控制的方法，其他结构师根据需要重复递归地进行，我们需要特别清醒的就是概念完整性是产品质量的核心。

csdn下载地址：http://download.csdn.net/detail/davebobo/9488042