读人月神话有感

关于本书，即便不少没读过的人也能说出其中知名度最高的关于人月神话的观点。以前还在知乎上看过有人举了一个例子：一我的生孩子须要十个月，两我的去生孩子一样须要十个月。这一比喻虽不彻底恰当，却也大体说出点内容。事实上，做者在书中这样来描述人月神话：软件开发项目常以人月来衡量工做量，这种度量暗示着人手和时间是能够互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，布鲁克斯法则：向滞后的软件项目追加人手会使得进度更迟缓（Adding manpower to a late software project makes it later）。关于这点，做者解释的为：向软件项目中增派人手从三个方面增长了项目必要的整体工做量：任务从新分配自己和所形成的工做中断；培训新人员；额外的相互沟通。一样，做者也向项目管理人员提供了相应的解决方法：

• 从新安排进度。我喜欢P.Fagg，一个具备丰富经验的硬件工程师的忠告：“避免小的误差（Take no small slips）”。也就是说，在新的进度安排中分配充分的时间，以确保工做能仔细、完全地完成，从而无需从新肯定时间进度表。
• 削减任务。在现实状况中，一旦开发团队观察到进度的误差，老是倾向于对任务进行削减。当项目延期所致使的后续成本很是高时，这经常是惟一可行的方法。项目经理的相应措施是仔细、正式地调整项目，从新安排进度；或者是默默地注视着任务项因为轻率的设计和不完整的测试而被剪除。

　　在三四十年前，做者便以他丰富的项目经验和敏锐的观察力、判断力提出这样创造性的论断，确实使人折服。时至现在，关于人力和时间之间的关系并不是呈现线性关系，也不能采用人月做为生产率的衡量标准这一结论已获得广泛的认同。

　　固然，做者的论断以及Brooks准则也并不是严格成立：在《20年后的人月神话》一文中，做者给出了Boehm的模型和数据以验证以前的说法太过绝对，可是，“这些细致的研究使“异常简化”的Brooks准则更加实用。做为平衡，我仍是坚持这个简单的陈述，做为真理的最佳近似，以及一项经验法则——警告经理们避免对进度落后的项目采起的盲目、本能的修补措施。”

　　许多人都以为以上观点就是《人月神话》的所有了，并不是这样。《人月神话》只是书中一个章节，Brooks准则也只是书中的观点之一。本书所述内容远非于此，它涉及到软件开发与项目管理过程当中的方方面面，从开发团队人员配置，到资源的合理配置，到项目文档的撰写以及其余许多内容。实际上，本书取名《人月神话》在某种意义上存在必定的误导性：在《20年后的人月神话》中，做者提炼出了核心观点：概念完整性和结构师。

• 概念完整性。一个整洁、优雅的编程产品必须向它的每一个用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操做和各类参数的用户界面使用策略。用户所感觉到的产品概念完整性是易用性中最重要的因素。
• 结构师。结构师负责产品全部方面的概念完整性，开发用于向用户解释使用的产品概念模型，概念模型包括全部功能的详细说明以及调用和控制的方法。结构师是这些模型的全部者，同时也是用户的代理。在不可避免地对功能、性能、规模、成本和进度进行平衡时，卓有成效地体现用户的利益。
• 将体系结构和设计实现、物理实现相分离。为了使结构师的关键任务更加可行，有必要将用户所感知的产品定义——体系结构，与它的实现相分离。体系结构和实现的划分在各个设计任务中造成了清晰的边界，边界两边都有大量的工做。
• 体系结构的递归。对于大型系统，即便全部实现方面的内容都被分离出去，一我的也没法完成全部的体系结构工做。因此，有必要由一位主结构师把系统分解成子系统，系统边界应该划分在使子系统间接口最小化和最容易严格定义的地方。每一个部分拥有本身的结构师，他必须就体系结构向主结构师汇报。显然，这个过程能够根据须要重复递归地进行。

　　因此从人我的观点出发，本书用其中一章的标题命名全书，实则不太稳当，哪怕叫作《项目管理规范》都更能作到统筹兼顾（尽管这个名称看起来有点官腔，或者说：土）。固然，做者这样命名，应该有本身的用意（或许用其中一篇做为总标题是这类技术文章合集书籍命名的一种习惯？前段时间看的《黑客与画家》也是这样）。

　　回到书本内容，大部份内容涉及团队与管理，强调了沟通及人的重要性，技术方面虽未过多涉及，却从项目管理的角度高屋建瓴地描绘了软件开发的整个过程，在一些不涉及具体技术的方面（由于年代已经过久远），颇有先见性和指导性。

　　简单提下书中对我最有感触的几章吧，其余有些由于经验不够的缘由还不能彻底理解。

• 第一章 焦油坑 
  　　史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不一样，对开放过程的要求也有极大的不一样，这给软件开放这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。
• 第三章 外科手术队伍 
  　　虽然优秀的程序员的工做效率每每数倍于平庸的程序员，但如果缺少合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队须要和外科手术组同样妥善分工，各司其职协调配合。 
• 第五章 第二个系统效应 
  　　人们在第一个系统成功完成后，每每会在开发后续的第二个系统时犯冒进的错误。第二个系统常常成为过分设计或多此一举的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，普遍进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。 
• 第六章 沟通顺畅 
  　　架构设计一般由核心设计小组完成，将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。以System 360的开发经验为例，要贯彻概念完整性，须要在团队中保持良好顺畅的沟通和交流，采用形式化定义等技术来确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。 
• 第七章 巴别塔为什么失败 
  　　若是缺少良好有效的沟通和协做，成员间难以有效的配合，团队项目的目标就没法实现。清晰的工做文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。 
• 第九章 袖里乾坤 
  　　最大化资源利用率，减小没必要要的资源占用，合理规划，使软件系统在资源有限的状况下依然保证了良好的性能，从而实现良好的可伸缩性和健壮性，这能体现软件开发人员精湛的设计技巧。巧妙的数据结构每每能大幅度地俭省资源耗费，提升系统运行的性能。
• 第十一章 准备抛弃 
  　　变化是永恒的，用户的需求和指望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程当中的种种问题。程序的复杂性、用户需求的不肯定性、软硬件技术环境的发展等因素致使了软件维护工做并不是老是可以百分之百地得到回报。 
• 第十六章 没有银弹――软件工程的必然和偶然 
  　　本文最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》第一版发行已有十年，其间计算机技术领域的变化使人振奋，但做者在此提出，因为软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。做者点评了二十世纪80年代前期为业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具有的优点和缺憾。做者预言在近十年内，没有任何单独的软件工程进展可使软件生产率有数量级的提升。 　　

　　以上是我对本书内容的简单思考与提炼，之后有一些工做经验后，我仍是要回头再看一遍《人月神话》的，把其中不理解的部分继续读透。

　　推荐本文的读者朋友们也去读一读这本书，绝对不会失望的。关于写做风格，看看译者的话：

　　在写做风格上，《人月神话》也足以垂范后世。图灵奖评选委员会曾经特地提到，布鲁克斯不只为计算机技术作出了杰出的贡献，他也是一位修养全面的学者。《人月神话》并不是一份枯燥的技术文献，而是一系列文采斐然的随笔――布鲁克斯对文学和艺术涉猎颇广，他敏锐的思惟和渊博的学识，使他在表述软件工程思想时，能从人文和其余工程领域信手拈来旁证博引，深得举一反三之妙。从英语写做的角度上说，《人月神话》具有随笔体睿智而典雅的风貌，行云流水间文思严谨。读者没必要象阅读常见的技术手册同样正襟危坐在工做台前研读，却是能够在旅途之中，工做之暇轻松地开卷有益，领略精纯的文笔、睿智的思索。 

　　到这，本文差很少该结束了，在此，我想引用《人月神话》的部分结束语，与诸君共勉：

　　我实在没法想像还有哪一种生活会比热爱计算机更加激动人心，自从从真空管发展到集成电路以来，计算机技术已经飞速发展。我用来工做的第一台计算机，是从哈佛刚刚出炉的IBM7030 Stretch超级计算机，Stretch在1961到1964年间都是世界上运算速度最快的计算机，一共卖出了9台。而我如今用的计算机，Macintosh Powerbook，不但快，还有大容量内存和大容量硬盘，并且便宜了1000倍（若是按定值美圆来算，便宜了5000倍）。咱们依次看到了计算机革命，电子计算机革命，小型计算机革命，微型计算机革命，这些技术上的革命每一次都带来了计算机数量上的剧增。

　　在计算机技术进步的同时，计算机相关学科知识也在飞速发展。当我在五十年代刚从学校毕业的时候，我能看完当时全部的期刊和会议报告，掌握全部的潮流动向。而我如今只能对层出不穷的学科分支遗憾地说“再见”，对我所关注的东西也愈来愈难以所有掌握。兴趣太多，使人兴奋的学习、研究和思考的机会也太多——多么难以想象的矛盾啊！这个神奇的时代远远没有结束，它依然在飞速发展。更多的乐趣，尽在未来。