人月神话读后感—终极人月.doc

人月神话读后感终极人月一千个读者，会有一千个哈姆雷特，每个人对待同一事物的看法都会略有偏差，尤其是对于人月神话这样出版至今30多年的旷世巨作而言，评论就更加是数不胜数，参差不起了，所以，在这里，我只发表一下我对这巨作的一点微薄之见。书中有许多非常好的观点，但我只把我感触最深的写下来。 这确实是一本很值得多次阅读的好书，每次阅读都可能从中得到一些新的理解和体会。那么，我首先来说下人月神话的核心观点：概念完整性和结构师。Brooks认为，一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而结构师，则是负责保证产品所有方面的概念完整性的，结构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。将一个美好的事物呈现给大众。我的理解：保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东西（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。还有一个观点是针对第二个系统，这里的第二个系统指的是产品的第二个实际发布。开发第一个发布的时候会因为各种原因去消减不必须的功能，所以会简化问题，而在第二个版本的时候则常常想其中添加各种各样的功能（也许源于用户的功能建议）但是，却导致了灾难性的后果。所以，在这种情况下，用户群越大，越不稳定，我们就更加应该明确的定义用户群，以获得概念的完整性。我们必须为整个设计团队定义一个共同的用户图像，记录下用户群的属性：1.他们是谁。2.他们需要什么。3.他们认为自己需要什么。4.他们需要什么。而另一方面，对于任何产品，任何用户群属性都是一种概率上的分布的，也就是每个属性都有各种可能的值，所以我们能做的是，架构师去猜测（guess）或者假设（postulate）一系列完整的属性和频率值。这里，清晰和错误都将比模糊不清好得多（也是我现在犯的问题）。我再把自己的一些感悟写一下：1、增量式开发。书中特别建议这种开发模式，这种开发模式最大的好处是让开发人员能够在每个阶段有一个可以运行的系统，这样开发人员每个阶段都有成就感，不会觉得枯燥。而且每个阶段开发出的系统其实都可以使用，这样用户可以使用并且有什么不对的地方可以及时纠正。我上一个系统就是采用增量式开发的，我们先把系统的最基本功能实现了，这样系统已经可以使用，可以交给测试和用户来检测和使用。而且当看到一个能运行的系统出来后，那种高兴是不言而喻的。我们采用的架构是SSH（spring-spring mvc-hibernate），设计模式不用说也可以看出是MVC，这种设计很容易进行增量式开发，新的功能和旧的功能的交叉的地方只有一个接口，一个类。而且使用了hibernate，如果后期有新的数据表或者字段加入，也不会对以前的系统有大的影响，只需要局部调整就行。记得有一次面试中面试官问我：为什么MVC设计模式会如此流行？当时的回答是：易学，能够复用。面试官并不满意这个回答，结束后问朋友，朋友答：易扩展，易维护。我觉得这个回答明显要好很多，因为对于大多数软件来说都是经常变化的，反而复用并不多。这本书中也提到软件肯定会有变化，如业务的增加，取消，改变等都会引起软件需求的变化；我自己经历的软件和朋友所说的都证实了现实开发中软件的变化。这样就需要软件易扩展，易维护。2、书中还提到一点，虽然OS/360失败了，但是在开发它的过程中解决了很多技术难题。这使我想到为什么大家总说只有做项目才能提高技术水平。的确是项目开发过程中会遇到很多问题，这样大家才会想办法解决，没有项目，你不会去想有什么问题。但是在项目中遇到问题的话，你最好的求助方式是网络和书籍，而且如果在遇到问题的时候能深入研究书籍的话你才会进步的比较快。以前我们公司有一个同事，他好像是一个百事通，新出的流行技术他大都会用，我问他是怎么做到的。他答：先看网络，有新技术的话就深入的看看书，然后再自己写一个小例子。这种学习的方式的确不错，但是我自己却做不到。3、书中提到一个团队，在没有时间，人才和金钱的压力下开发一个系统，本来应该只用1年时间开发的系统却用了5年，当系统开发完成后已经过时了。他们失败的原因有一个就是目标设定的太大，什么都要做到最好，他们列了5个目标，按当时的水平只要他们实现了其中的1到2个就已经很有卖点了。我觉得做系统的确不需要实现太多的目标，而且有些目标甚至是相背的，比如安全性和易操作性。4、文档。虽然太多的书籍都强调文档的重要性，但是在实际操作中它又发挥了多大的作用呢！书中提到流程图，流程图的使用本来应该在开发前画，但是很多流程图都是在开发结束后需要文档才画上的。这样做也许会对维护人员有帮助，但是维护人员真的会看吗？我觉得有少部分关键文档的确非常重要，大部分文档只是为写文档而写。软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用整个项目开发时间不超过20%，而80%的时间花在编程上一样。探讨人狼是否存在已经没有意义了，而那颗“银弹”的去向也只有等待时间去发现。总之，软件工程发展到今天这个