人月神话读书笔记2

画蛇添足
这一章主要是告诫系统设计师们，不要过度设计，尤其是在第二个系统(第一个系统完成后开发的第二个系统)中，不要过度自信，保持警觉，避免初始的概念和目标得到充分的体现，而不让一些次要的功能喧宾夺主。(是不是可以说是保持初心？)

贯彻执行
概念的完整性不仅仅要在专制的贵族和系统设计师这一层面上充分传达并理解，在系统的实现人员中，也要充分传达。在不理解业务背景的情况下，开发者也很难写出优秀的代码。作者在这一章介绍了很多方法以达到这一目的，包括规格说明手册、形式化定义(我的理解是 Web 开发中的原型图一样的存在)、会议和大会、多重实现(举例：假如JavaScript只有 V8 一个引擎，那如果引擎实现与 ES 标准不一致时，改标准比改引擎实现要容易得多，但是有多个引擎时，与标准不一致的引擎就必须修改自己的实现，从而保证了标准文档的贯彻执行)、电话日志、产品测试。

当然这些方法在如今可能已经过时了，但是通过种种方式保证软件开发的进度不偏离最初的概念和目标，是实现项目成功的重要保障。实际上在当代的软件开发流程中也有一些措施来实现这一目标，如敏捷开发中每天的站会。

为什么巴比伦塔会失败
我们都知道巴比伦塔的失败是因为上帝给了人类不同的语言导致的沟通失效。那么在大型项目中如何保证沟通的顺畅呢？作者详细介绍了项目工作手册的内容、发布方式、更新方式等等，但是当年他们仍然是纸质文档，后来才进化成微缩胶片，现如今我们有了更方便的字处理工具和文档协作工作，因而这部分的建议就用不上了，但是保持文档的更新和有效获取仍然很重要，否则不同的人对需求的记忆和理解可能出现偏差、进度可能会出现错位等等，导致项目的开发进度被拖慢。

相应的，外科手术队伍也可以有效地降低交流的难度，毕竟人越少，沟通越便捷，这样一来，整个项目通过合理的人力划分和职责限定，就会自上而下形成一个树状结构。作者特地论述了团队中技术负责人和产品负责人的分工与关系，但是我很难将作者的观点映射到当代的开发团队中来，只好略过。