《人月神话》读后感

在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks 博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代….

《人月神话：软件项目管理之道》（英语：The Mythical Man-Month: Essays on Software Engineering）是由IBM System/360系统之父佛瑞德·布鲁克斯所著经典文集，全书讲解软件工程、项目管理相关课题，被誉为软件领域的圣经，内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验[2]。该书于19xx年首次发行（ISBN 0-201-00650-2），并于19xx年重新发行纪念版（ISBN 0-201-83595-9），其中新增了对〈没有银弹〉一文的评论和回应，与4个额外的新章节。

书开始就形象有有趣的把软件危机比作：焦油坑 ========== 史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎...让我感觉到，软件开发过程中所遇到困难是多么的多，开发多么艰难。

当我看完《人月神话》突然感觉到这本书比《The Clean Coder: A Code of Conduct for Professional Programmers 》更完美，是为软件开发经验的天马行空总结。比《Beautiful code》更为有远见，把我从充实代码的清晰简介升华，拓展到软件开发的高层度， 一个周密，准确，明朗的开发需求分析，可行性研究，软件实现是软件开发的完美递进，他们相互辅助，相互促进，如海浪一层的推着前浪奔向远方，而《人月神话》如软件工程开发经济的精华，碧玉。

在《人月神话》面前《设计模式》、《原型设计》、《灵活软件开发》、《面对对象思维》、只不过是冰山一角。正是《人月神话》---软件项目管理的圣经，软件领域的《孙子兵法》。

人月神话（英语：The mythical man-month）：这部分讲述人力（man）和时间（month）并不体现线性关系。指出以大量人员和较短的时间，并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产，且会制造麻烦，产生出更差的软件。向进度落后的项目追加人力，只会使进度更加落后。因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。当有 N 个人必须在这群人之中进行沟通时（无阶级关系），当 N 增加，其输出 M 将抵消其效益，甚至倒退（最后几天所完成的进度，远不如刚开始几天所完成的进度。像是发现了许多错误）。

我的体会：软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。

人月神话的核心法则：概念完整性和架构师。Brooks认为，一个整洁、优雅的变成产

品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师，则是负责保证产品所有方面的概念完整性的，架构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。

我的体会：概念完整性将软件开发连成了一条钻石项链，每个部分都不可忽视，不可取代。整体的抽象完整时软件管理的灵魂。正因为如此，可见架构师的重要性。因此另一方面 把工作切分给更多人做将造成额外的沟通（communication）代价——训练和相互的交流（intercommunication）。欲增加软件项目的人手，总共必须付出的代价可分为三方面：工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流。

书其中有内容提到：外科手术团队。在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。两人团队，其中一人当领导者，这通常是最佳的用人方式。以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示，使用一堆人蛮干的方式最耗成本、最慢、最没有效率，做出来的系统在概念上也最不完整。

我的体会：软件编码实现过程中，需要不是人多，而是少而精的优秀程序员，编码员。所以整体程序员的素质很重要，有必要培训提高他们的素质。

《人月神话》的第二系统效应（英语：The second-system effect）就一个人所做过的设计而言，第二个系统是最危险的系统，一般来说，都倾向于过度设计。

当他做第三或之后的系统时，之前的经验会互相印证，以确认出这类系统的一般性特色，而系统彼此之间的不同处，也会帮助他辨别出属于特殊和非通用的部份。除了做些功能上的修饰之外，第二系统效应还有另外一项特征，那就是倾向于将之前已熟悉的技术发挥到淋漓尽致，但却没有留意到，这项技术早就跟目前项目的基本系统假设有冲突而不再适用，OS/360有好多这样的例子。（Windows NT则似乎是19xx年代的示例）

对大部份OS/360的设计人员来说，它也是个第二系统，设计成员分别来自1410-7010磁盘操作系统、Stretch操作系统、Project Mercury实时系统、给7090用的IBSYS操作系统等等，几乎没有人拥有两个上述系统的发展经验，所以OS/360可称得上是一个最佳的第二系统效应示例。

我的体会：第二系统效应，不但消耗了巨大花费，而且将没有经验的开发人员拉进开发是一件很囧的事情。并不会给软件管理带来好处。

软件系统可能是人类创造中最错综复杂的事物，往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发人员日夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟

通，彼此理解，才会做出精品来。

第二篇：人月神话》读后