人月神话读后感

终于读完人月神话了，一直没有时间写读后感，现在距读完这本书已经一个星期了。现在把自己能想到的写一下吧！

1、增量式开发。书中特别建议这种开发模式，这种开发模式最大的好处是让开发人员能够在每个阶段有一个可以运行的系统，这样开发人员每个阶段都有成就感，不会觉得枯燥。而且每个阶段开发出的系统其实都可以使用，这样用户可以使用并且有什么不对的地方可以及时纠正。我上一个系统就是采用增量式开发的，我们先把系统的最基本功能实现了，这样系统已经可以使用，可以交给测试和用户来检测和使用。而且当看到一个能运行的系统出来后，那种高兴是不言而喻的。我们采用的架构是SSH（spring-springmvc-hibernate），设计模式不用说也可以看出是MVC，这种设计很容易进行增量式开发，新的功能和旧的功能的交叉的地方只有一个接口，一个类。而且使用了hibernate，如果后期有新的数据表或者字段加入，也不会对以前的系统有大的影响，只需要局部调整就行。记得有一次面试中面试官问我：为什么MVC设计模式会如此流行？当时的回答是：易学，能够复用。面试官并不满意这个回答，结束后问朋友，朋友答：易扩展，易维护。我觉得这个回答明显要好很多，因为对于大多数软件来说都是经常变化的，反而复用并不多。这本书中也提到软件肯定会有变化，如业务的增加，取消，改变等都会引起软件需求的变化；我自己经历的软件和朋友所说的都证实了现实开发中软件的变化。这样就需要软件易扩展，易维护。

2、书中还提到一点，虽然OS/360失败了，但是在开发它的过程中解决了很多技术难题。这使我想到为什么大家总说只有做项目才能提高技术水平。的确是项目开发过程中会遇到很多问题，这样大家才会想办法解决，没有项目，你不会去想有什么问题。但是在项目中遇到问题的话，你最好的求助方式是网络和书籍，而且如果在遇到问题的时候能深入研究书籍的话你才会进步的比较快。以前我们公司有一个同事，他好像是一个百事通，新出的流行技术他大都会用，我问他是怎么做到的。他答：先看网络，有新技术的话就深入的看看书，然后再自己写一个小例子。这种学习的方式的确不错，但是我自己却做不到。

3、书中提到一个团队，在没有时间，人才和金钱的压力下开发一个系统，本来应该只用1年时间开发的系统却用了5年，当系统开发完成后已经过时了。他们失败的原因有一个就是目标设定的太大，什么都要做到最好，他们列了5个目标，按当时的水平只要他们实现了其中的1到2个就已经很有卖点了。我觉得做系统的确不需要实现太多的目标，而且有些目标甚至是相背的，比如安全性和易操作性。

4、文档。虽然太多的书籍都强调文档的重要性，但是在实际操作中它又发挥了多大的作用呢！书中提到流程图，流程图的使用本来应该在开发前画，但是很多流程图都是在开发结束后需要文档才画上的。这样做也许会对维护人员有帮助，但是维护人员真的会看吗？我觉得有少部分关键文档的确非常重要，大部分文档只是为写文档而写。

5、人月神话为什么能畅销30年。的确如书中所说，其实他只是以某个项目为起点来展开软件工程的实际开发中的原理。记得大学的时候软件工程，计算机原理，编译原理等书籍都至少采用了10年，而其他的java语言等只是这2年才开课的。计算机技术的确变化很快，某些原理却并没有发生大的变化。

我本来分到的书是《Agile project management with scrum》，奈何读了一章着实没有感觉，可能项目经历不够，真的很难站在高的角度去看懂该书，所幸栋梁那儿多了一本人月神话，光看封面和插图就很生动，于是就换了，以下是一点小小感悟。

《人月神话》是软件工程方面的一本经典著作，作者布鲁克斯（Frederick P. Brooks）被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。

书中很雷到我的是Brooks提出的这样一条定律：给推迟的软件项目增加人手将使得项目更加推迟。所有的程序员都是乐观主义者，他们倾向于认为事情会如他们想象的那么顺利，而事实上并非如此。所以软件项目都倾向于被推迟完成。那种认为大项目只是增加足够的程序员就能顺利完成，已经对于已经推迟的项目，只要增加人手就能按期完成的看法是错误和危险的，因为它假定人和月是可互换的，而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。就拿我们这次做的学术搜索会议助手项目来说，本来我们的scrum开始的就很早，初期进展也都不错，可哪怕是在这样大好的情况下，最终我们还是留下了两三个task没有得到很好的完成而被拖到beta版本中。

书中又说到，系统设计中最重要的是概念的完整性。应明白概念的完整性而不是功能的多样性是评价系统好坏的标准。概念上统一的系统更容易建造和测试。要保证概念上的完整性，设计应该由一个人或者观念一致的小规模小组完成。这看似具有贵族主义倾向，却是保证系统概念上的完整性的需要。架构师的角色与军队的统帅很类似，虽然独裁，但是却是必须的。我们前期的准备就发现，经过一开始的头脑风暴后，确实需要一两个强大的人来扮演架构师的角色，很幸运的是，我们拥有像夏睿和海峰这样的队友。

第七章说到了巴别塔项目失败的原因是缺乏交流和组织。书中说缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构，及时更新，每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式，它是可行的，但并不一定是最有效的，因为有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。管理经理负责组织团队、分配工作、创建日程表等。很多时候，他建立内部交流和报告的模式，但是很多时候负责团队之外的交流。技术经理构造设计，确定模块，保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少，实干家也很少，有思想家特质的实干家是最少的。只有在3至6人的小项目中，管理经理和技术经理才可以是一个人。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。也许我们的项目里，Cherry和Xiaolin，我和夏睿就分别扮演了这样的角色？另外虽然从一开始我们就很注重成员间的沟通，同时项目规模也很小，可仍然遇到了大家对某一功能认知不一致的问题，可以见得，巴别塔不能通天，沟通真的只能改进，问题实在不可避免。

另外一个让我印象深刻的观点是：要保证一个项目的进度被大幅度推迟，制订进度表很重要。进度表由里程碑和完成的时间组成。里程碑必须具体、明确、可界定。某一里程碑要么到达，要么没有到达，不应该是80%到达的。而我的经验是，制订进度表非常重要，而且要求制定者有很强的技术背景，这样才能对可能碰到的问题和可能花掉的时间做出更准确的估计，我们这次的项目中出现了burn down图的正斜率，希望通过学习和锻炼再也消失不见。

以上就是粗读《人月神话》的一点愚见，好书，以后有时间一定再读。

当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。

把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。

1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。

概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。

2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。

组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。

3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。

以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。）

如果不想加班，不想削减功能，不想推迟发布日期，那么……唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。

感触还有很多，以后如果有机会再写。不过，我决定去买本英文版回来，收藏，以后再多看几次。

第一，增量式开发。这种开发模式能在每个阶段有一个可以运行的系统，能让人有成就感。像以往的开发模式，项目没做出来，就什么都没有了。没有一点用处。采用的架构是SSH(spring-spring mvc-hibernate)。设计模式当然是MVC，新的功能和旧的功能交叉的地方只有一个接口，一个类。而且还使用了hibernate框架，后期只要局部调整就行了。所以说，MVC为什么会这么好用呢。就是由于其易扩展，易维护。

第二，为什么OS/360会失败呢? 碰到太多困难难以解决了。很多人都说多做项目才能进步技术水平，但是没有书籍做保障。什么叫先网络。再看看有什么新技术没。有的话再看书。

第三，项目的要求要切实际，不要把目标定的太大，以免完成不了。少一些花哨。多一些朴实。

第四，文档的重要性。我们现在在做项目的时候，有几个人会认真的往写文档，全都是为写文档而写文档的。养成写文档是一个良好的编程习惯。这样对软件的后期维护也有帮助，相当重要。

第五，人月神话为什么会畅销30年呢?为什么我们在大学学的那个什么软件工程。计算机组成原理，基础什么的。一成不变。由于那些原理是永远不会变的。

第六，做好软件开发的前期工作。说实在的，编程占的时间并未几。而在前期的预备工作做好了。前期的文档 需求分析写好了。后面的软件的编程就水到渠成了。软件编程那些代码都是死的。都是有固定的算法。编程方法在那的。唯一变化的是前期的需求分析和文档。做好了这个。这个项目就算成功了一半了。

第七，工具的重要性。能善用工具的人也是人才。很多编程都可以用记事本编写。用工具也能达到同样的效果，还可能比记事本更好，那我们为什么不用工具呢。好的工具能进步办事效率。能缩短我们项目的开发时间，时间就是金钱。

第八，软件系统也是人类创造的错综复杂的事物。只有大家彼此沟通，彼此理解，多讨论，多合作。才能使一个软件更加完善。才能做出精品的软件。