liujianli的博客

人月神话读书笔记焦油坑过去几十年的大型系统开发就犹如一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统，不过只有极少数的项目满足了目标、进度和预算的要求；编程为什么有趣创建事物的纯粹快乐；开发对他人有用的东西；整个过程体现出的一股强大的魅力–将相互啮合的零部件组装在一起，看到它们以精妙的方式运行，并收到预期的效果；持续学习的快乐，它来自于这项工作的非重复特性；

另外一面英国巨石阵是世界上最大的没有文档说明的“计算机器“。4000－5000年前古人没有留下只言片语说明巨石阵的用途，至今考古学家对古人建筑巨石阵的目的莫衷一是。 比喻文档匮乏会使软件产品难以为用户接受，故而使用文档在软件项目中相当重要。对软件编程产品来说，程序向用户呈现的（文档）和提供给机器识别的内容同样重要。需要什么样的文档每个用户都需要一段对程序进行描述的文字。可是大数文档只提供了很少的

祸起萧墙潜藏的小祸患看似微不足道，而有朝一日可能葬送了原本看起来坚不可摧的事物。项目是怎样被延迟了整整一年时间的……一次一天。一天一天的进度落后比起重大灾难更难以识别，更不容易防范和更加难以弥补。里程碑还是沉重的负担根据一个严格的进度表来控制大型项目的第一个步骤是制定进度表，进度表由里程碑和日期组成；里程碑的选择只有一个原则，必须是具体的、特定的、可度量的事件，能够进行清晰定义；里程碑边界明显

整体部分那些号称自己能完成庞大软件项目的业界人士，和旧时马戏团中以夸张吹嘘来吸引观众注意力的魔术师一样，其表演的东西并不能进行实质追究。剔除BUG的设计产品的概念完整性在使它易于使用的同时，也使开发更容易进行，而且BUG更不容易产生；关键的工作是产品定义。许许多多的失败完全是因为那些产品未精确定义的地方而导致的；细致的功能定义、仔细的规格说明、规范化的功能描述说明以及这些方法的实施，大大减少了

干将莫邪干将，春秋时吴国人，是楚国最有名的铁匠，他打造的剑锋利无比。楚王知道了，就命令干将为他铸宝剑。后与其妻莫邪奉命为楚王铸成宝剑两把，一曰干将，一曰莫邪。项目经理应该制定一套策略，并为通用工具的开发分配资源。与此同时还必须意识到专业工具的需求。目标机器开发团队需要有自己的目标机器，它更需要最大限度的内存来提升工作效率；机器资源缺乏时，一次分配给某个小组的连续的目标时间块被证明是最好的安排方法

未雨绸缪不变只是愿望，变化才是永恒。试验性工厂和增大规模对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之；系统的丢弃和重新设计可以一步完成，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤；为舍弃而计划，无论如何，你一定要这样做；唯一不变的就是变化本身变化是与生俱来的，不是不合时宜和令人生厌的异常情况；开发人员交付的是用户满意程度

提纲挈领在堆积如山的文件资源中，少数文档是关键枢纽，每一件项目管理的工作都围绕着它们运转。软件项目的文档每份文档的准备工作是集中考虑，并使各种讨论意见明朗化的主要时刻；对每个关键文档的维护提供了状态监督和预警机制；不论项目的规模有多小，开发人员从商讨结构的会议开始，项目经理首先立刻正式生成若干正式的小文档，以作为自己的数据基础，然后再要求提供和其他经理类似的文档；为什么要有正式的文档书面记

削足适履规模，成本控制作为成本的程序空间规模是软件系统产品用户成本中一个很大的组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法；规模本身不是坏事，但不必要的规模是不可取的；规模控制对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。必须研究用户和用户的需求，以设置待开发系统的规模；仅对核心程序设定规模目标是不够的，必须把所有方面的规模都编入预算；规模预算

胸有成竹仅通过对编码部分的估计，然后应用计划进度、编码、构件测试和系统测试的比率是无法得到对整个任务的估计的；构建独立小型程序的数据不适用于编程系统产品（就好像把100米短跑记录外推，得出人类可以在3分钟之内跑完1英里的结构一样）；相对于活动，全职程序员仅将50%的时间用于编程和调试；对常用的编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要注释并可能存在错误的情况；使用适

为什么巴比伦塔会失败当时人类联合起来兴建希望能通往天堂的高塔；为了阻止人类的计划，上帝让人类说不同的语言，使人类相互之间不能沟通，计划因此失败，人类自此各散东西。巴比伦塔的管理教训缺乏交流；缺乏交流的结果——组织；无法交谈，从而无法合作。无法合作工作陷入停顿；大型编程项目中的交流因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于存在对其他人的各种假设，团队成员之

贯彻执行他只是坐在那里，嘴里说：“做这个！做那个！”当然，什么都不会发生，光说不做是没有用的。项目经理如何确保每个人听到、理解并实现结构的决策？如何保持系统概念上的完整性？文档化的规格说明——手册手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样地，它也是结构师主要的工作产物；手册不仅要描述包括所有界面在内的用户可见的一切，还要避免描述用户看不见的事物；体系结构设计人员必须为自

画蛇添足抛开开发速度和成本的责任，结构师和设计人员之间应彻底、谨慎、和谐的交流。结构师的交互准则和机制关于估算，结构师的不利之处是，开发人员通过增高或降低结构师的估计，来反映到设计的好恶。实际情况中，尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工；面对估算过高的难题，结构师有两个选择：削减设计或者采用成本更低的实现方法；采用成本更低的实

外科手术队伍效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平。问题需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。这一点，也暗示系统应该由尽可能少的人员来开发（小型、精干队伍是最好的——思绪尽可能少）；绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、低效的，开发出的是无法在概念上进行集

人月神话缺乏合理的进度安排是造成项目滞后的最主要原因，导致这种灾难如此普通的原因有： 1. 对估算技术缺乏有效的研究； 2. 估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆； 3. 对自己的估算缺乏信心，软件经理通常不会有耐心持续地估算这项工作； 4. 对进度缺少跟踪和监督； 5. 当意识到进度的偏移时，下意识的反应是增加人力。这只会使事情更糟；乐观主义所有的编程人员都是

没有银弹由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。摘要所有软件活动包括： 根本任务，即打造构成抽象软件实体的复杂概念结构；次要任务，即使用编程语言表达这些抽象实体，在空间和时间限制下将它们映射成机器语言；关注软件任务中的必要活动： 仔细地进行市场调研，避免开发已上市的产品；在获取和制定软件需求时，将快速原型开发作为迭代计划的一部分；有机地更新软件，随着系统