【读书笔记】人月神话

 作为一本计算机编程项目管理类的书刊，此书书名就毫不留情地指出“用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话”。这里向读者传达了这个重要的概念，在估计和进度安排中使用的工作量单位：人月。但实际上，人数和时间的互换是近乎不可能的，因为编程项目的任务不能分解给互相毫无交流的参与人员们（关系如下图所示）。

   在本书开头部分，作者讨论了编程从业者的职业乐趣和苦恼，并且以精妙地将编程比喻为焦油坑，编程团队比喻为外科手术队伍，围绕着软件开发中的各大障碍和误区，展开了对编程团队管理方法的讨论。总结为以下几点：

1. 系统测试的进度安排。系统测试是最难完成暗示完成的部分，而这种拖延的二次成本却是巨大的。
2. 空泛的估算。任务的计划进度，可能受限于顾客要求的紧迫程度，无法控制实际的完成情况。
3. 重复产生的进度灾难。通过增派人手来完成任务的方式往往事半功倍。

   然后，作者以结构师的角度进行分析，阐述正确的做法来保持产品系统的概念一致性和编程人员的正确实践，这也是此书关于概念一致性的核心理论。主要在于：

1. 创造性活动上的专制性统治但也要求结构师与建筑人员的仔细交流。
2. 文档化的规格说明以及一系列保证编程实现人员理解决策的手段

   接下来，作者以巴比伦塔建造失败、各个先例的数据的案例来具体分析了大型编程项目中的交流与组织架构，强调了编程中程序空间与计算机产品文档的重要性。

1. 巴比伦塔项目的失败原因主要在于缺乏交流以及组织。团队交流、项目手册及组织架十分重要。
2. 整项工作的的估算不能仅依靠编码部分的估计，尤其小型独立程序的数据本就不适合编程系统项目。
3. 编程产品的实验性工厂为提高产量和缺乏保护环境下运作提供宝贵经验。
4. 开发过程中专业工具的使用，以及通用工具的开发分配资源对生产率的影响深刻。

   最后，本书介绍了一些对于软件整体部分bug的减少有效的一些理论措施，如自顶向下设计、结构性编程、高级别表达方式等，好的结构设计可以避免很多小错误。

   这本书给我留下的最深刻、最重要的观点便是它对人员与月数的关系的描述。它强调少而精的团队，是因为在关系错综复杂的任务之中，人员交流时间的变多、交流效率的变低会使开发进度延长。我在实验室常常有相同的体会，处于项目边缘的成员们往往很难入手，而在不自觉的等待与观望或费时费力的交流之中让时间悄悄溜走。正是由于这个矛盾的出现，人员与时间的调控，尤其是在大型的复杂编程项目之中，显得尤为重要。如何把一系列程序设计和构建成系统，如何把程序或者系统设计成健壮的、经过测试的、文档化的、可支持的产品，如何维持对大量的复杂性的控制，将成为软件工程这个“焦油坑”中持续存在的问题，而IT领域的飞速发展更是督促着我们不断地学习新工具的最佳使用。

   另一个令人惊叹的观点就在于，结构师交互准则与机制中提到的开发第二个系统的画蛇添足——倾向于过分设计。这里提到，当他们在设计第三到第四个系统时，先前的经验就会互相印证，并且为了避免第二个系统的画蛇添足，他们应坚持至少拥有两个以上系统开发经验的结构师的决策。这提醒了我们，现代软件工程中经验十分重要，一类系统中通用特性的判断，以及系统之间的差异会帮助我们识别出经验中不够用的部分，并且可以成为一种积累。

   总而言之，为了避免可怕的进度偏离，一个优秀的整体架构以及里程碑式的报告举足轻重，等到项目进行之后临时的增援只会大大地扰乱我们的“人月”计划。