人月神话读书笔记
总的来说，人月神话是一本较老的书籍，出版时间看第一版序言都追溯到1974年10月，我看的是40周年中午纪念版，在此书中作者回过头来，也对人月神话中之前的预估一一做了分析和评价，挺好的一本书。
此书的读书看完的感觉就是：嗯，有道理，好像掌握了什么，明白了什么，然而回忆起来似乎啥都又没抓住。
此书的读书笔记打算按照人月神话的章节拆分来讲讲各个章节的内容，也方便自己回忆，回过头来自己也可以翻一翻。
第一章 焦油坑
一句话：作者把几十年的大型系统开发比做焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。认为编程系统产品把是需要从程序，编程系统，编程产品，编程系统产品。这个过程中不仅仅需要程序，还要程序集合，文档，测试，集成等等，才能构成一个完整的编程系统产品。
编程的乐趣：在于创造的乐趣和各种组件进行啮合的满足感。
编程的烦恼：需要依赖他人组件或程序；需要寻找琐碎bug，是一种重复性活动；当投入大量辛苦劳动，产品即将完成或终于完成时，发现过于老旧不能使用。
一个许多人痛苦挣扎的焦油坑，一种乐趣和苦恼共存的创造性活动。
第二章 人月神话
本章讲了人月不是神话，需要警惕人数的增加并不一定能替换时间，有些系统性工作是不可拆分的，人数和时间的互换仅仅适用于可拆分的子系统或任务，并且他们之间并不需要交流。
对于软件任务构建，提到了一个经验法则：
1/4 计划 1/6 编码 1/4 构建测试和早期系统测试 1/4 系统测试，所有构建完成
Brooks法则：向进度落后的项目中增加人手，只会使项目进度更加落后。
项目的时间依赖于顺序上限制，人员的最大数量依赖于独立子任务的数量。
第三章 外科手术队伍
优秀的程序员和较差的程序员之间的生产率差异很大，实际测量结果差异更加令人震惊，生产率达到10:1，在编程速度和空间上具有5:1的差异。
这章讲述了如何组建一种类似外科手术队伍式的精英研发团队，包含系统开发中的所有角色。
外科医生（首席程序员，架构师）亲自定义功能，性能技术说明书，设计程序，编制代码，测试以及书写技术文档
副手 他是外科医生后备，能完成任何一部分工作。
程序职员 负责编写程序和所有团队技术文档维护。
工具维护人员 有很多文件编辑，文本编辑和交互调试等工具，需要用自己的机器和操作人员来维护，保障基本服务的可靠性。承担团队成员所需要的各种工具。
测试人员 负责大量测试用例。
语言专家 精通语言特性，能够有效的用语言解决晦涩，难懂或棘手问题
管理员 外科医生的老板，必须在人员，薪酬、办公室空间具有决定权，需要控制财务、人员、工作地点和办公设备的专业管理人员，该管理员充当与其他机构的接口。在项目中仅具有法律，合同、财务和报表方面的需求时，才具有全职责任。
编辑 负责外科医生的文档生成，他必须创建各种文档，无论外部和内部。
文秘 管理员和编辑都需要文秘，协助他完成文档工作。
此种团队的组织是高效的，角色分工和技术是可行的。
第四章 贵族专制、民主政治和系统设计
一个系统的易用依赖设计和概念的完整性，概念的完整影响一个系统的研发效率和bug发生概率。
概念的完整性需要由一个人或者非常少数的，有默契的人员来实现。
概念的完整性要求系统只反映唯一的涉及理念。用所见的技术说明来自少数人的思想，实际工作被划分为：体系结构，设计实现和物理实现。
第五章 画蛇添足
在开发第一个系统时，架构师往往倾向于简洁和精炼，他知道自己对正在进行的任务不够了解，所以会谨慎、仔细地工作。
当第一个项目或系统结束时，此事对下一个项目内容，架构师对这类系统充满十足的信心，其精通这一级别的系统，并且时刻准备开发，此时第二个系统的开发往往是危险的。当后续着手第三个或第四个系统时，先前的经验会相互印证，得到对此类系统的通用特性判断，而且能够识别系统之家不够通用的部分。
一种普遍的倾向是过分涉及第二个系统，向系统过分添加很多修饰功能和想法，结果会产生一个大陷阱。
结构师如何避免第二个系统所引起的后果，从而避免画蛇添足？
答案是：虽然他无法避免第二个系统设计，但他可以有意识地关注这个系统的特殊危险，运用特别的自我约束，来避免那些功能上的过于修饰。（比如设置一个准则或阈值，每次改进或功能不超过xxx）
第六章 贯彻执行
如何保证项目经理已拥有行事规范，富有经验结构和许多程序人员，如何确保每个人听到，理解并实现结构师的系统设计，如何保证1000人开发的系统，一个10人架构师团队如何保证系统概念上的完整性？ 答案是： 文档话的规格说明-手册
规格说明必须清晰、准确和完整。必须采用形式化定义（形式化定义就是定义一套标准、编码、清晰准确）
第七章 为什么巴比伦塔会失败
首先强调了交流和组织的重要性，一个项目没有交流和组织，是无法形成合力，导致项目分崩离析，最终系统之间模块相互孤立，导致争辩，争吵和群体猜疑，最终项目失败。
大型项目的交流：非正式途径、会议、工作手册
大型项目的组织架构：
如果项目有n个工作人员，则有(n^2-n)/2个相互交流的接口，有近2n个潜在的必须合作的团队。团队组织的目的是减少所需要的交流和合作数量。
交流和组织是一个项目成功的关键。交流和组织需要一个管理者仔细考虑，相关经验的积累和提高同软件技术本身一样重要。
三种可能的组织形式：
产品负责人和技术主管是同一个人（非常容易应用小型团队）
产品负责人作为总指挥，技术主管充当左右手（有一定困难，需技术主管不参与任何管理工作下，树立技术权威）
技术主管作为总指挥（适合小型团队）
对真正大型项目而言，产品负责人作为管理者更适合。
第八章 胸有成竹
系统编程需花费多少时间？需要多少工作量？如何进行评估？
这三个问题都是项目管理的排期计划的重要组成。
扒拉了各种xx数据，生产率，工作量等等
最后结尾提到了对常用的编程语言，生产率是固定的。
使用适当的高级语言生产率可以提高5倍。
第九章 削足适履
程序控制内存、存储、计算等资源。
规模控制：控制软件成本，考虑下对客户的整体影响。
空间技能： 内存，空间-时间的折中。
数据的表现形式是编程的根本。
第十章 提纲挈领
软件项目文档的重要性，关键的文档包含： 目标 技术说明 进度 预算 组织结构图 工作空间分配 报价、预算、价格
项目经理的文档可以作为数据基础和检查列表，通过周期性回顾，他能清晰清楚项目所处的状态。
项目经理的文档是要提纲挈领的，项目经理的任务是制定计划、并实现计划，只有书面计划是可以沟通和精确的。计划中包含了时间、地点、人员、项目内容和项目资金，这些少量的关键文档封装了项目经理的大量工作。
第十一章 未雨绸缪
对于大多数项目而言，第一个设计的系统往往太慢、太大，而且难以使用。要解决以上问题除了重新开发，没有其他办法。因此提到为舍弃而计划，无论如何，你一定要这样做。
唯一不变的就是变化本身。
要为变更设计系统，为变更计划组织架构，变更的阶段化是一种必要的技术。
软件系统开发是减少混乱度（减少熵），它本身处在亚稳态中。软件维护是提高混乱度（增加熵）的过程。
第十二章 干将莫邪
项目经理必须考虑、计划、组织的工具有哪些呢？
巴拉巴拉一堆，提到了，计算机设施、操作系统、实用程序、调试辅助程序、测试用例生成工具、和处理文档的字处理系统。
计算机设施：目标机器和辅助机器
第十三章 整体部分
如何开发一个可运行的系统？如何测试系统？如何将已测试的集成到已测过、可依赖的系统中？
系统的考虑一下：
防范bug，产品迭代完整性概念在使它易用的同时，也使开发易于进行，且bug更不容易产生。
自上而下设计
结构化编程
构建单元调试
系统集成测试：
已充分测试构件
搭建充分测试平台
一次添加一个构件
阶段（量子化）化、定期变更
第十四章 祸起萧墙
一天天的进度落后是难以识别、不容易防范和难以弥补的。
对计划和控制职能进行适度的技术人力投资是非常值得赞赏的。
第十五章 另外一面
高级语言使用激发的自文档化方法，特别用于在线系统的高级语言，它们的应用都是非常合情合理的。
第十六章 没有银弹
软件工程中根本和次要问题.
根本任务: 打造构成抽象软件实体复杂概念结构。
次要任务：使用编程语言表达这些抽象实体。
根本问题不仅仅在目力所及的范围内没有银弹，软件的特性也导致不大可能有任何发明创新（能够像硬件工业中的电子器件）-提高生产率、可靠性和简洁程度。我们甚至不期望每2年能有两倍增长。
次要问题：高级语言有力解决突破了软件生产率、可靠性和简洁性；分时解决了完全不同的困难，保证及时性，从而使我们能维持对负责度的一个整体把握；统一编程环境，通过提供统一文件格式、集成库、管道和过滤器解决了不少共同程序使用的次要困难。
银弹的希望：
面向对象编程
人工智能
专家系统
“自动”编程
图形化编程
针对概念上根本问题的颇具前途的方法：
需求精炼和快速原型
增量开发
第十七章 再论“没有银弹“
作者自豪地断定：“没有银弹”的声称和断定，在近10年没有认可单独的软件工程进展可以使软件生产率有数量级的提高。
“没有银弹”无可争辩地指出：如果开发的次要问题少于整个工作的9/10，即使不占任何时间（基本就是奇迹），也不会给生产率带来数量级的提高。因此必须着手解决开发的根本问题。
根本困难是固有概念的复杂性、无论任何时间、任何方法设计和实现软件功能，它都存在。
复杂性是软件开发本身的行业属性，而且复杂性是我们的主要限制。现在我们可以在软件生产率上取得逐步发展，而不是等待不大可能的大的突破。
第十八章 《人月神话》的观点：是与非
作者自己回顾了第一章到第十八章的所有内容。
编程系统产品的开发工作量是供个人使用、独立开发的构件程序的9倍。
巴拉巴拉。。。。
第十九章 20年后的《人月神话》
概念完整性和结构师。
概念完整性：一个整洁、优雅的编程产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。
开发第二个系统所引起的后果：盲目的功能和评率猜测。
增量模型开发更佳-逐渐的精化。
软件工程的焦油坑在将来很长一段时间会继续使人们举步维艰，无法自拔。
软件系统可能是系统创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围进行探索和尝试。
这个复杂的行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的工程管理方法和最佳应用；良好的自我判断已经能够使我们认识到自己的不足（上帝所赐予我们的谦卑）。
参考资料
《人月神话》-40周年中文纪念版