《人月神话》读书笔记

软件工程领域的知识在于积累。

煤油坑

职业的乐趣来源：

1. 创建事物的纯粹快乐；
2. 来自开发对他人有用的东西；
3. 来自整个过程体现出的一股强大魅力；
4. 是持续学习的快乐；
5. 来自易于驾驭的介质上工作。

职业的苦恼来源：

1. 来自追求完美；
2. 来自由他人设定目标、供给资源和提供信息；
3. 寻找琐碎的BUG；
4. 当投入了大量劳动，产品在即将完成或者终于完成时，却已显得陈旧过时。

人月神话

美食的烹调需要时间；片刻等待，更多美味，更多享受。——新奥尔良市安托万餐厅

所有的编程人员都是乐观主义者。

系统测试进度的安排常常是编程中最不合理的部分。

为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中比其他任何工程领域要普遍得多。

Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。(Adding manpower to a late software project makes it later.)

外科手术队伍

这些研究表明，效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平。——Sackman, Erikson, Grant

一拥而上的开发方法是高成本的、速度缓慢的、低效的，开发出的是无法在概念上进行集成的产品。

大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。（同每个成员截取问题某个部分的做法相反，由一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力）

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

在系统设计中，概念完整性应该是最重要的考虑因素。

存在的矛盾：概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。VS. 进度压力却要求很多人员来开发系统。

解决方法：1、仔细地对设计方法和具体实现进行分工；2、组建外科手术队伍

系统的体系结构指的是完整和详细的用户接口说明。

整个创造性活动包括了三个独立的阶段：体系结构（architecture）、设计实现（implementation）和物理实现（realization）。——Blaauw

画蛇添足

聚沙成塔，聚腋成裘。——奥维德

贯彻执行

手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样地，它也是结构师主要的工作产物。手册不仅要描述包括所有界面在内的用户可见的一切，还要避免描述用户看不见的事物。

规格说明的风格必须清晰、完整和准确。精确比生动更重要。

形式化定义：“不要携带两个时钟出海，带一个或三个。”如果同时具有形式化和记叙性定义两种方式，则必须以一种作为标准，另一种作为辅助描述，并照此明确地进行划分。

会议分成两个级别：周例会和年度大会。

周例会是每周半天的会议，由所有的结构师，硬件和软件实现人员代表以及市场计划人员参与，由首席系统结构师主持。周例会的决策会给出迅捷的结论，使工作继续开展下去。

为解决周例会堆积起来的问题，举行持续两周的年度大会。

为什么巴比伦塔会失败

团队间进行交流的方式：

1. 非正式途径：如电话；
2. 会议：常规项目会议；
3. 工作手册。

减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。

树状结构几乎不能用来描述交流沟通，因为交流是通过网状结构进行的。

产品负责人的角色：组建团队，划分工作及制定进度表；争取，并一直保证必要的资源；建立团队内部的沟通和报告方式；确保进度目标的实现，根据环境的变化调整资源和团队的架构。

技术主管的角色：对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构；提供整个设计的一致性和概念完整性；控制系统的复杂程度。

对小型团队最好的选择：技术主管作为总指挥，产品负责人充当其左右手。

对真正的大型项目的开发团队的安排：产品负责人作为管理者更适合。

胸有成竹

实践是最好的老师。——普布里乌斯

实践是最好的老师，但智者还能从其他的地方有所收获。——《穷理查年鉴》

削足适履

数据的表现形式是编程的根本。

提纲掣领

1、书面记录决策是必要的。2、文档能够作为同其他人的沟通渠道。3、项目经理的文档可以作为数据基础和检查列表。

项目经理的任务是制定计划并实现计划。但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人员、项目内容和资金。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己的方向。

未雨绸缪

不变只是愿望，变化才是永恒。——斯威夫特

在实验室可以进行的反应过程，并不能在工厂一步实现。

对于大多数项目，第一个开发的系统并不合用。变化是与生俱来的，不是不合时宜和令人生厌的异常情况。

系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

干将莫邪

开发和维护公共的通用编程工具的效率更高。

机器支持可以有效的划分成目标机器和辅助机器。目标机器是软件所服务的对象，程序必须在该机器上进行最后的测试。辅助机器是那些在开发系统中提供服务的机器。如果是在为原有的机型开发新的操作系统，则该机器不仅充当目标机器放入角色，也可以作为辅助机器。

整体部分

自上而下的设计将会是最重要的新型形式化软件开发方法。

通过GOTO不加限制的分支跳转，会产生导致自身逻辑错误的结构。

祸起萧墙

制定进度表，进度表上的每一时间被称为“里程碑”，它们都有一个日期。里程碑必须是具体的、特定的、可度量的事件、能够进行清晰定义。

具体的里程碑是百分之百的事件。

里程碑边界明显和没有歧义，比它容易被老板核实更为重要。

另外一面

使用程序。每个用户都需要一段对程序进行描述的文字。

验证程序。除了程序的使用方法，还必须附带一些程序正确运行的证明，即测试用例。

修改程序。调整程序或者修复程序需要相当多的信息。

很少有程序需要一页纸以上的流程图。

降低文档负担的方法：
1.借助那些出于语言的要求儿必须存在的语句，来附加竟可能多的“文档”信息。
2.尽可能地使用空格和一致的格式提高程序的可读性，表现从属和嵌套关系。
3.以段落注释的形式，向程序中插入必要的记叙性文字。

没有银弹——软件工程中的根本和次要问题

所有软件活动包括：
根本任务，即打造构成抽象软件实体的复杂概念结构；
次要任务，即使用编程语言表达这些抽象实体，在空间和时间限制下将它们映射成机器语言。

没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。

进步是逐步取得的，要伴随着辛勤的劳动，对规范化过程进行持续不懈的努力。

计算机硬件产业技术的性价比在30年内取得了6个数量级的提高。

软件的复杂度是根本属性。

很多复杂性来自保持与其他接口的一致性，对软件的任何再设计，都无法简化这些复杂特性。

所有成功的软件都会发生变更。

软件是不可见的和无法可视化的。软件的客观存在不具有空间的形体特征。

再论“没有银弹”

复杂性是层次化的。

读后感：

程序员对编程有着充分的热爱，因为爱所以要做好，在软件工程领域，前辈的经验教训最为重要，我们能做的是不重复走前辈的歧途，使用好他们留下的遗产。在软件开发过程中，始终要保持着乐观的心态，保持对完美的追求，遇到困难，自己解决不了就应寻求帮助合作；对于规范要遵守，寻求合适的管理者，或者自己努力成为一个管理者；理解软件开发中的困难，分清根本和次要，解决次要困难。前车之鉴，后车之师。