《人月神话》阅读记录

第一版 序言
在很多方面，管理一个大型的计算机编程项目与管理其他行业的大型工程很相似–比大多数程序员所认为的还要相似；在另外一些方面，它又有差别–比大多数职业经理人所认为的差别还要大。
这个领域的知识在于积累。
虽然写出来的是各自独立的章节，但本书还是有一个中心的论点，特别包含在第2~7章，简言之，我相信由于人员的分工，大型编程项目碰到的管理问题和小项目碰到的管理问题区别很大；我相信关键需要的是维持产品自身的概念完整性。这几章探讨了其中的困难和解决的方法。而后继的章节则探讨了软件工程管理的其他方面。
本书是一部文集。

第1章 焦油坑

前车之覆，后车之鉴。 — 荷兰言喻
不过只有极少数的项目满足了目标、进度和预算的要求。
首先让我们来认识一下系统开发这个职业，以及充满在这个职业中的乐趣和苦恼吧！
编程系统产品
职业的乐趣
创建事物的纯粹快乐
开发对他人有用的东西。

职业的苦恼
遗留代码（postgresql百万行，OS 千万行代码）
追求完美。
由他人来设定目标、供给资源和提供信息。
概念设计时有趣的，寻找琐碎的bug确实一项重复性的活动。
调试和差错。
完成时，发现实现的已经过时陈旧。

第2章 人月神话

乐观主义

人月

系统测试

空泛的估算

重复产生的进度灾难

第3章 外科手术队伍

这些研究表明，效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平。
一流人才组成的小型、精干的队伍。
精兵

问题
Mills的建议
外科医生—Mills称为首席程序员。
副手，他是外科医生的后备。
管理员
编辑，创建各种文档，。

如何运作

团队的扩建

第4章 贵族专治、民主政治和系统设计

概念的完整性
对于计算机系统而言，尽管它们通常没有花费几个世纪的时间来构建，但绝大多数系统体现出的概念差异和不一致性 远远超过欧洲的大教堂。这通常并不是因为它由不同时代的设计师们开发，而是由于设计被分成了由若干人完成的若干任务。
我主张，在系统设计中，概念完整性应该是最重要的考虑因素。也就是说，为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
如何获得概念完整性？
这样的观点是否要有一位杰出的精英，或者说是结构设计师的贵族专治，和一群创造性天赋和构思被压制的平民编程实现人员？
如何避免结构设计师制订出无法实现，或者是代价高昂的技术规格说明，使大家陷入困境？
如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计能被正确地理解，并精确地整合到产品中？

获得概念的完整性

贵族专治和民主政治
避免各自为政。主设计师。经验主义（耗时低效长期设计 写文档） PK 实证主义（敏捷，原型，快速迭代，尽快交付用户可用、核心功能可用软件）。

在等待时，实现人员应该做什么

第5章 画蛇添足

结构师的交互准则和机制
自律 开发第二个系统所带来的后果

第6章 贯彻执行

文档化的规格说明–手册
形式化定义
直接整合
会议和大会
多重实现
电话日志
产品测试

第7章 为什么巴比伦塔会失败

巴比伦塔的管理教训
清晰的目标
人力充足
材料
足够时间？
足够技术？
失败原因：交流 & 交流的结果–组织。
无法相互交谈，从而无法合作。交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂–大家选择了孤立，而不是互相争吵。

大型编程项目中的交流
非正式途径
会议
工作手册

项目工作手册
大型编程项目的组织架构

第8章 胸有成竹

削足适履

提纲挈领

未雨绸缪

干将莫邪

巧匠因为他的工具而出名 – 谚语
工具 工具开发部门
目标机器
辅助机器和数据服务
高级语言和交互式编程

整体部分

剔除bug的设计
构建单元测试
系统集成测试

14 祸起萧墙

比喻内部发生祸乱；也比喻身边的人带来灾祸。
带来坏消息的人不受欢迎。

里程碑还是沉重的负担
其他的部分反正会落后
地毯的下面
有两种掀开毯子把污垢展现在老板面前的方法，它们必须都被采用。一种是减少角色冲突 和 鼓励状态共享，另一种是猛地拉开地毯。

另外一面

需要什么样的文档
流程图
自文档化程序

没有银弹

再论没有银弹

《人月神话》的观点：是与非

20年后的《人月神话》

软件工程的状态和未来
软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越能力所能及的范围内进行探索和尝试。