人月神话读书笔记

前言

《人月神话》被誉为软件工程的圣书，在我本科阶段的时候就曾经在老师的建议下读过，当初是用吃饭、睡觉前等碎片化的时间进行阅读，好多东西都是囫囵吞枣，不明所以。现如今对于里面的很多知识几乎都已经忘记了，在《软件工程管理》这门课的过程中，老师提起这本书，提起“沟通”的重要性，提起“没有银弹”，在脑海中似乎有印象，但是具体讲了些什么呢？自己又说不出来。软件工程本就是对前人工作的总结，如今再次拿起这本圣书，看到里面对于软件项目管理的过程中一些精华，加上本科阶段软件开发的理解，对于这本书讲的内容不妄想在短时间内全部理解，全部吃透，暂且先来做一份笔记，加上我自己一点点的小见解。许多章节的内容可以相互渗透互相理解，本文虽然是以章节的名字作为小标题但是，并不是严格按照章节来划分。

焦油坑

过去几十年的大型系统开发就犹如这样一个焦油坑，许多大型和强壮的动物在其中剧烈的挣扎。想一想这是多么壮观的场面，在入坑之前，无论是觉得自己多么强壮，无论是觉得自己能力多强，在焦油坑中还是会一点一点的越陷越深。大型的软件开发就如同这焦油坑一般，一点点的吞噬软件的开发人员、测试人员、管理人员、投资者、各种各样的团队，正是因为他们呢没有很好的满足目标、时间进度和预算的要求。看起来系统中的单个问题非常好解决，但是当他们错综复杂的交错在一起的时候，随着时间的推移慢慢积累没有很好的解决的时候，团队成员会慢慢的陷入绝望，导致项目的最终失败。编程系统产品开发是供个人程序构建的9倍，现在许多同学们自己做的demo(程序)，与真正能供用户使用的编程系统产品还差了很多很多。当然本章中也分析了作为软件开发人员的职业乐趣与职业苦恼，任何事情、任何职业、任何观点都是有乐趣与苦恼的我们要学会辩证的看待。

人月神话

本书的书名也是人月神话，将本章的名字命名为书名，意义非凡。本章中首先阐述了，每个软件开发人员的职业病是乐观主义，我觉得这个说的非常在理，软件开发人员是创造者，对自己脑海中的描绘的事务创造程序的创造者，自己想的往往是片面的，程序运行结果符合自己的想法，就会有一种成就感，存在这种成就感就很难想着去发散自己的思维，这形成了一种“良性循环”，一种自我安慰而来的乐观主义。这就是为什么软件开发人员与测试人员是天生的天敌的原因，开发人员会天生乐观的想“我这个程序怎么可能会有Bug”，而测试人员则是“这段程序怎么又有Bug”。存在这种乐观主义，必然会导致程序的返工，项目周期时间的延期，这时候很多项目经理的第一反应是，在deadline之前加人，但是这种盲目加人的思想没有想到沟通带来的成本(为什么巴比伦塔会失败)、新人熟悉项目所带来的时间成本等，所以说盲目的增加人手往往会达到相反的目的，用人手交换时间，人和月的互换就是一个神话。本章中对任务进度安排给了一些建议：1/3计划、1/6编码、1/4构建测试和早期的系统测试、1/4系统测试，所有构建完成。很多人会产生疑问，为什么编码的时间这么少？因为往往编码的时间估算是可控，对于测试的结果往往是未知的，所以要多给测试时间。要做到未雨绸缪我们在实现功能时往往有很多思路，但是哪种思路能行得通并且最适合情况就需要我们进行试验性开发。试验性开发确实会造成精力的消耗，或许大量的测试方案最终还会被舍弃，但是我们必须这样做。实际上如果不进行方案的实验，正式的开发反而可能遭遇返工和混乱的拆补，会严重分散重新开发人员的精力和信心，甚至影响用户对产品的信任。这世界上唯一不变的就是变化本身，我们必须有未雨绸缪的能力，对未来可能产生的变化做出提前的设计，甚至对组织架构也需要进行提前的计划来规避变化造成的风险。除了开发，运营维护也需要适应变化，这就需要我们提高代码的质量和可读性，完善测试过程，保证系统在调整的过程中能够尽量少地引入更多问题。前人的智慧告诉我们，缺陷是永远存在的，我们需要通过质量管理放缓系统混乱度的提高，总而言之一句话，遇到问题不要盲目加人，任何环节都要做到未雨绸缪。

外科手术队伍

效率高和效率低的实施者之间的具体差别非常大，经常达到了数量级的水平。软件项目经理往往喜欢由头等人才组成的小型、精干的队伍，而不是几百个平庸程序员组成的大型团队，因为需要协作的人员数量影响着开发成本。通常情况下小型强有力的团队不超过十人，组成这种小而强力的10精英团队往往时很难的，这个时候外科手术队伍的团队方式就可以值得借鉴。书中的对应是一名首席程序员相当于外科医生，一个经验相对较少的人员充当副手，一个管理员负责行政事务的决策，一个编辑用于生成文档，两个文秘使得文件与项目协作一致，一个程序职员用于维护技术记录，一个工具维护人员，一个测试人员，以及一个语言专家。这样的开发团队人员平等但是各司其职，保证了团队的有序运行。对于大型的项目，就需要在人员安排上使用分解的思路，由架构师负责整体设计，系统实现则由各个小团队协作完成。

贵族专制、民主政治和系统设计

概念的完整性是系统设计中最重要的考虑因素。在日常生活中，每个人的想法都不一样，软件的开发不能完全按照每个人的想法进行开发创造，这样开发出来的产品就是一个四不像。所以，必须有一个人(架构师)或者具有共识的小型团队来收集团队中成员的愿景(民主)，最终综合产出具有概念一致性的软件产品，来反映唯一的设计理念，在一些重要决断的时候必须由架构师或者小型具有共识的架构团队来强制性执行(贵族专制)，这样开发出来的产品才会有一个共同的目标，为不是背向而驰。虽然有一个一致的完整的概念，如何做到概念的完整性？如何贯彻执行上层领导的决策？书中提出了几个方法来实现整个团队保持系统的概念完整性。文档化的规格说明，文字是信息的载体，当产生分歧不一致的情况出现的时候，文档就可以拿来作为下一步决策的标准，这足以证明文档对于维持概念完整性的重要性，当然对于文档的编写也需要形式化的定义保证概念的清晰和确定。但是书中存在一种观点，对于软件项目的开发人员都要完整的了解软件开发的细节，也就是说每次上班之前都要读文档，读各种各样的项目文档，以便了解项目开发的进度。我对此表示并不是很赞同，这种做法对于小型的团队，小型的开发而言，浪费在文档阅读，文档制定的时间可能不是很多，但是对于大型的项目而言，开发人员每天花费大量的时间去阅读与自己负责单元、模块、服务无关的文档，而且这些文档就像女人的裹脚布一样又臭又长，这非常浪费时间与经历，这些文档是否增加了开发人员的负担？我所提倡的是必要的设计与决策进行书面表达是可以的，并且这种文档存在形式是单一的，文档存在的意义就在于沟通，这些文档可以作为一种标准。在软件开发的过程中，你不想听见别人告诉你一堆废话，还有一堆与自己开发工作无关的话。开发人员仅仅需要了解的是整个项目的宏观设计与关键步骤的决策，以及重点关注自己所负责的部分。

画蛇添足

当我们小心翼翼开发完第一款产品准备开发第二款类似的产品的时候，对于第一款产品的思路已经清澈熟路，对于第一款产品的缺陷与不足我们也能够了然于胸，所以往往会对第二款产品进行许许多多冗余的设计，这是每个人的通病，我们总想将事情设计的完美无缺，但是当我们回看的时候想一想，这些设计是那么重要的嘛？每个人都不能跨过第二个系统直接调到第三个系统，第二个系统就在那里，无法逾越，但是我们怎么去避免会出现一些无关紧要的冗余的浪费时间金钱人力物力的设计呢？虽然我们有意识的去避免这些无关紧要的边缘的设计，避免一些功能上的修饰，保持对特殊诱惑的警觉，但是自己是无法完全避免的，所以必须坚持至少用于两个系统以上开发经验结构师来决定。

祸起萧墙

项目是怎样延迟了整整一年的时间？是一步步的一点一点的。一天一天的进度落后是难以识别、不容易防范和难以弥补的。昨天，某个关键人员生病了，无法召开某个会议。今天，由于雷击打坏了公司的供电变压器，所有机器无法启动。明天，因为工厂磁盘供货延迟了一周，磁盘例程的测试无法进行。下雪、应急任务、私人问题、同顾客的紧急会议、管理人员检查——这个列表可以不断地延长。每件事都只会将某项活动延迟半天或者一天，但是整个进度开始落后了，尽管每次只有一点点。对于这种逐渐延迟的进度，Brooks提议简历项目里程碑，并且持续的修订项目计划，这样无论最后的情况变得多么糟糕，它都不会有太大的变化。里程碑是指百分之百的事件，必须有明显的边界和没有歧义。这样就很好有人可以在里程碑进展上弄虚作假。我们要学会利用工具好的工具，在软件的开发离不开工具，从需求的分析，到系统的设计，到程序的编码，到构建、测试、发布和维护，我们要善于利用工具来提高我们工作的效率和质量，善于利用工具进行时间进度的把控。