我第一次写这么长的读后感

初识《人月神话》这本书是看到在豆瓣上的推荐，它被列在计算机方面的书籍里取了一个这样的书名确实吸引了我，并且很多评价将其奉为“软工的圣经”，但是由于当时对软件工程没有太多概念对这本书的了解也就止于书名了，直到这学期选修了这门课程加上老师的推荐才对这本书产生了浓厚的兴趣。这也是我继《最后期限》所读的第二本管理类的书，由于自己所处的高度和知识能力的限制，在读完之后其实还是对很多东西没有理解，语言能力的限制也使我只能阅读翻译版本的，但还是明显感觉得出其中有些作者想表达的意思翻译者可能也没有很准确的传达，这也是阅读的一个弊端。处在现阶段我仅从自己认知的角度来说说我的体会。

首先这本书并不是在讲述一个计算机历史的神话故事，也不是告诉我们如何编程和如何去构建一个伟大的工程项目，它更像是在追根溯源去探究和反思真正影响项目工程因素的管理类书籍，整本书强调的更多的是人的重要性。“人月“其实是项目工程中用来估计和进度安排中使用的一种工作量单位。我觉得《人月神话》这本书的产生基于一个概念——“软件危机”。 作者Brooks是著名“OS/360“项目的项目管理人（也是通过这本书我才去查阅资料了解了其中的历史），这个项目如作者所说被比作焦油坑，整个开发团队像一只巨兽在焦油坑中拼命挣扎，然后自己反而越陷越深，无法挣脱。和code rush记录片中所讲述的网景的故事一样，当软件开发从小作坊式的开发模式到大团队大项目的过程自然而然就暴露了许多问题,其中包含的所需要解决的各种复杂度也逐渐上升。虽然0S/360失败了，但是它在开发的过程中解决了很多技术难题。它的开发过程也成就了这本让大家膜拜的《人月神话》，也正是深刻的经历过这样的危机，作者以一个过来人总结问题所在给出结论，我相信其中的经验很值得我们去借鉴和学习。

书中所提到的Brooks法则让我眼前一亮，好像以往并没有思考和遇到过这种问题，在我们的传统思考方式里，仿佛一件工作投入的时间和人力越多会做的越好，当一项工作没有按计划完成时，第一解决方法便是加班加人手，而Brooks法则告诉我们，用人月作为衡量工作进度的单位是一个危险和带有欺骗性的神话。其实也很好理解，只是惯式思维常常让我们想不到这个层面，当一个项目的工期已经延误时，再增加人手可能反而会造成负面影响，这时候成员本身的心态可能也处于焦虑状态，而每个项目都有其独特性，想要入手都需要花费一定时间，增加新成员时老成员还要花额外时间对其进行培训，先不提培训的效率，人与人之间的沟通成本会随着人数的增加成指数增长，反而增加了项目必要的总体工作量，团队成员沟通成本的增大也相应的使压力变大，所以人手增加的优势最后反而被负面影响抵消了。这也可以类比于战争时期的情况来理解，当一场战争来临，军队希望的是人越多越好，甚至为了弥补人力鼓励多生多育，但同时也面临着一个问题，带领10个人作战可能很容易，带领100个人可能也没那么困难，可是当人数达到一万十万的时候呢，团队中产生的问题也会急速增加，这时候如果解决不好团队内部的沟通和协作问题，还未谈攻击力自己内部就先甭离瓦解了，所以后来我们实行计划生育将重心放在提高教育质量上来提高综合国力。

作者对问题的分析思路也值得我们学习，他并不人云亦云，而是注重从经验和实际来看待解决问题的有效性。比如说，在画流程图这一做法上，作者认为流场图是被吹捧的最最过分的一种程序文档，事实上，流程图被吹鼓的程度远远大于他们的实际作用，一个有经验的编程人员，在开始编写程序之前，并不会绘制详尽的流程图，在一些要求流程图的组织中，流程图也总是事后才补上。一些公司则使用工具软件，事后从代码中生成这个不可缺少的设计工具。我很赞成作者的这一观点，其实在学到流程图时，它要遵顼很多符号规则和设计原则时我就很费解觉得没有很大的作用，在一个项目开始前我觉得流程图只是起到一个给我们提供整体思路的辅助方式，为何要给它设置限制然后小心翼翼遵循这种原则去设计一个没有多少实际作用的流程图来增加自己的工作量和负担。这好像一种循规蹈矩去重理论不重实践的典型体现。

外科医生式的团队也是我很感兴趣的一个部分。在传统的队伍中，将工作进行划分，每人负责一部分工作的设计和实现，大家都是平等的，出现观点的差异时，不可避免需要讨论和进行相互的妥协让步或者很难调和。而我们知道在外科医生团队中，一个手术团一般都是多人配合，但是一定有一个主刀大夫，由他来决定治疗方案并且实际操作，而其它人护士等只需为他提供支持，使问题的分析保持了一致性。对应到软件开发团队，这里的主刀大夫相当于首席程序员，由首席程序员来完成问题的分解，其他人给与他所需要的支持，以提高效率和生产率。这一观点在现今好像已经普遍被软件开发团队应用，不过这也对应一个很关键的问题，就是这名“主刀大夫”必须具有强大的意志力和决策能力，当面临困难时能带领团队攻坚克难。这其实也体现了第四章中谈到的民主政治思想，有时候一个团队的开发需要适当的“专制“，过分的民主不会有太多益处，反而会损坏团队效率和士气，或者说，过分民主其实反映出的是团队领袖意志和能力的不足。

除了这些理念，文中也提到一些软件开发中值得我们重视的事。

关于沟通：在和客户沟通时明确定义用户群：他们是谁，他们需要什么，他们认为自己需要什么，他们真正的需求是什么。在和客户沟通的过程中要不断抽取和细化产品的需求，事实上，客户往往不知道自己需要什么，他们通常不知道哪些问题是必须回答的，并且，连必须回答的问题细节常常根本不给与考虑，甚至只是简单的回答“开发一个类似于我们已有的手工信息处理过程的新系统软件”类似的话。实际上客户绝不会仅仅只要求这些，复杂的软件系统往往是活动和变化的系统，活动的动态部分往往是很难想象的，加上可能遇到客户对技术需求的无知性产生的问题，所以在计划任何软件活动时，必须让客户和设计人员之间进行多次广泛的交流沟通，并将其作为系统定义的一部分。

关于文档:软件项目要有正式的文档。只有记录下来，分歧才会明朗，矛盾才会突出，它的存在让人们从迷惑的现象中得到清晰的解释、确定的策略；文档能够作为同其他人的沟通渠道，只有书面计划是可以精确和可以沟通的；文档可以作为数据基础和检查列表，通过周期性的回顾，能清楚项目所处的状态，以及哪些需要重点进行更改和调整，通过遵循文档开展工作，能更清晰和快速的设定自己的方向。

关于减少bug的设计：（一）许许多多的失败完全是因为哪些产品未精确定义的地方而导致的。细致的功能定义、仔细的规格说明、规范化的规格描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量。（二）好的自上而下的设计从4个方面避免了bug：清晰的结构和表达方式更容易对需求和模块功能进行精确的描述；其次，模块分割和模块独立性避免了系统级的bug；第三，细节的抑制使结构上的缺陷更加容易识别；第四，设计在每个精化步骤上都是可以测试的，所以构件应该尽早进行单独的测试，之后再进行集成测试。（三）另外，采用结构化编程将整个系统划分为模块结构而不是零零散散的分支语句。

关于工具：所有工具的生命周期都是短的，每个骨干人员也都会有自己个性化的一套工具，但项目的关键是良好沟通以解决问题，太个性化的工具会妨碍而不是促进沟通，所以开发和维护公共的通用编程工具的效率会更高，不过仅用通用工具是不够的，，所以在关于软件开发队伍的讨论中，建议为每个团队配备一名工具管理人员。这个角色管理所有通用工具，能指导他的客户和老板如何使用工具，他还能编制老板需要的专业工具。

关于项目功能：保证项目的精炼简洁避免画蛇添足，设计师往往容易被诱惑着开发过多冗余的功能，其实并没有必要而且是应该被避免的。

当然，初此之外书中也提到很多其它的内容，例如无银弹说法、生产率的估计、程序空间和时间的折中等，我对这些方面没有太多感触在此就不再赘述。同时，对于书中提出的一些系统问题我也还没具体弄清楚，可能还要在今后的项目实践中慢慢去探索感受，比如如何把一系列程序设计构建成系统，如何把程序或者系统设计构建成健壮的、经过测试的、文档化的、可支持的产品；以及如何去控制大量的复杂性。《人月神话》这本书传达给我的整体感受便是：我们行业产生的主要问题实质上更侧重于社会学而不是科学技术，经营好一个项目团队不仅要技术还需要考虑诸多人文因素。

总之软件的团队开发是一项复杂的工作，需要我们投入大量思考和实践来寻求正确线路，作为一名计算机专业的学生，我相信当我处于不同的学习阶段、能力高度和将来处在事业的不同高度、扮演团队中不同的角色时，这本书中所阐述的观念和内容都会让我有不同的感受和收获，今后应该还会回头细细品读。多了解行业内的历史和经验也是今后需要去做的事，以往的学习我仅仅停留在一种小格局上，只是执着于对编程语言和数据结构算法等技术的学习以及程序的实现，并没有懂得以一个真正的计算机人的角度去从技术、思维、专业素养和格局等多角度培养自己。这本书让我明白一个专业体系的学习不仅仅只停留在技术工具的学习上，人的多变性产生的复杂度远大于技术产生的复杂度，从前人的事迹中学习经验培养自己的职业素养也尤为重要。正如书中所说，对于一个项目的成功而言，项目人员的素质，人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。现在软件工程的大多数学术研究集中在工具上，欣赏和期盼强大工具的同时也应该鼓励对人的关注、激励和培养，这才是核心所在。

另外，从作者Brooks身上，我看到了一种匠人精神，这也是本书中很能触动我的一部分，作者在结尾部分这样说到：“感谢上帝让我成为了为数不多的那些开开心心的做着自己喜欢的工作的人之一”，“我实在无法想象还有哪种生活会比热爱计算机更加激动人心” 。读到这里我的脑海里不自觉浮过纪录片coderush中展现的场景：“蚂蚁部落”一般的程序员们夜以继日的在一台机器前为了那些奔腾不息的代码劳作着，他们大腹便便，他们衣衫不整，他们没有光鲜的外表，他们甚至不得不牺牲了自己的家庭、健康和私生活为一份看不见的理想买单。想必作者也经历过这样的生活，于旁人看来，也许会问这值得吗，作者却避之不谈那些艰辛而是将这份工作看作是一种恩赐，这份能抵挡住外界压力的坚持与热爱以及所体现出的职业素养是我由衷敬佩的。互联网相关共工作看似是现今社会很酷的一件工作，很多人为了那份高薪跟风挤近来，圈外人也羡慕的红了眼，很多人在做一项工作的时候更多的是为了完成任务，只有任务完成才能得到一朵外界奖赏的小红花，所以我们不得不去做，反思自己好像也是这样的，每次编写一个程序或者实验的时候更多的也是为了完成任务去做，根本谈不上将它看做一个艺术品去精雕细琢去把它变得更完美，我想也是因为不够热爱和投入。方法千千万，唯有热爱是发自内心的旁人学不来的，希望自己今后也能戒掉浮躁身体力行去坚持一份难能可贵的热爱，在学习编程的过程中将做事方式调整到追求完美、态度严谨的状态。