标签：
《人月神话》是软件工程方面的一本经典著作，作者布鲁克斯（Frederick P. Brooks）被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。
1.增量式开发。书中特别建议这种开发模式，这种开发模式最大的好处是让开发人员能够在每个阶段有一个可以运行的系统，这样开发人员每个阶段都有成就感，不会觉得枯燥。而且每个阶段开发出的系统其实都可以使用，这样用户可以使用并且有什么不对的地方可以及时纠正。我上一个系统就是采用增量式开发的，我们先把系统的最基本功能实现了，这样系统已经可以使用，可以交给测试和用户来检测和使用。而且当看到一个能运行的系统出来后，那种高兴是不言而喻的。我们采用的架构是SSH（spring-spring mvc-hibernate），设计模式不用说也可以看出是MVC，这种设计很容易进行增量式开发，新的功能和旧的功能的交叉的地方只有一个接口，一个类。而且使用了hibernate，如果后期有新的数据表或者字段加入，也不会对以前的系统有大的影响，只需要局部调整就行。记得有一次面试中面试官问我：为什么MVC设计模式会如此流行？当时的回答是：易学，能够复用。面试官并不满意这个回答，结束后问朋友，朋友答：易扩展，易维护。我觉得这个回答明显要好很多，因为对于大多数软件来说都是经常变化的，反而复用并不多。这本书中也提到软件肯定会有变化，如业务的增加，取消，改变等都会引起软件需求的变化；我自己经历的软件和朋友所说的都证实了现实开发中软件的变化。这样就需要软件易扩展，易维护。
2.书中提到一个团队，在没有时间，人才和金钱的压力下开发一个系统，本来应该只用1年时间开发的系统却用了5年，当系统开发完成后已经过时了。他们失败的原因有一个就是目标设定的太大，什么都要做到最好，他们列了5个目标，按当时的水平只要他们实现了其中的1到2个就已经很有卖点了。我觉得做系统的确不需要实现太多的目标，而且有些目标甚至是相背的，比如安全性和易操作性。第七章说到了巴别塔项目失败的原因是缺乏交流和组织。书中说缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构，及时更新，每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式，它是可行的，但并不一定是最有效的，因为有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。管理经理负责组织团队、分配工作、创建日程表等。很多时候，他建立内部交流和报告的模式，但是很多时候负责团队之外的交流。技术经理构造设计，确定模块，保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少，实干家也很少，有思想家特质的实干家是最少的。只有在3至6人的小项目中，管理经理和技术经理才可以是一个人。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。也许我们的项目里，Cherry和Xiaolin，我和夏睿就分别扮演了这样的角色？另外虽然从一开始我们就很注重成员间的沟通，同时项目规模也很小，可仍然遇到了大家对某一功能认知不一致的问题，可以见得，巴别塔不能通天，沟通真的只能改进，问题实在不可避免。
3. 文档。虽然太多的书籍都强调文档的重要性，但是在实际操作中它又发挥了多大的作用呢！书中提到流程图，流程图的使用本来应该在开发前画，但是很多流程图都是在开发结束后需要文档才画上的。这样做也许会对维护人员有帮助，但是维护人员真的会看吗？我觉得有少部分关键文档的确非常重要，大部分文档只是为写文档而写。
4. 人月神话为什么能畅销30年。的确如书中所说，其实他只是以某个项目为起点来展开软件工程的实际开发中的原理。计算机技术的确变化很快，某些原理却并没有发生大的变化。
标签：
原文地址：http://www.cnblogs.com/dyc940210/p/4306885.html
