读「人月神话」

发表于 · 归类于 读书 · 阅读完需 3 分钟 · 报告错误

我在本科学习计算机专业时,就听过有一本鼎鼎大名的书叫「人月神话」,但却也一直没有机会阅读。直到前一阵子在北邮的图书馆中无意发现了这本书,就借下来翻看,读到了一些很多很有价值的观点,受益颇多,所以才有了此文的简单记录。

一、编程的乐趣与苦恼

在第一章中,作者总结了编程带给开发人员的一些乐趣所在,以及伴随着的若干苦恼。编程行业“满足我们内心深处的创造渴望和愉悦所有人的共同情感”提供了五种乐趣:

  1. 创建事物的快乐。
  2. 开发对其他人有用的东西的乐趣。
  3. 将可以活动、相互啮合的零件组装成类似迷宫的东西,这个过程所体现出令人神魂颠倒的魅力。
  4. 面对不重复的任务,不断学习的乐趣。
  5. 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动——其存在、移动和运转方式完全不同于实际事物。

同样,这个行业具有一些内在固有的苦恼:

  1. 将做事方式调整到追求完美是学习编程的最困难部分。
  2. 任何创造性活动都伴随着枯燥艰苦的劳动,编程也不例外。
  3. 人们通常期望项目在接近结束时,软件项目能收敛得快一些,然而,情况却是越接近完成,收敛得越慢。

二、人月神话

本章中,作者阐述了仅仅用“人月”来进行项目的进度安排是不正确的,它在割小麦的工作中是可行的,但在各子任务需要相互交流的系统编程中几乎不可能:

  1. 缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素的总和影响还大。
  2. 良好的烹饪需要时间,某些任务无法在不损害结果的情况下加快速度。
  3. 人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。
  4. 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
  5. 关于进度安排,我的经验法则是:1/3 用于计划、1/6 用于编码、1/4 用于构件测试以及 1/4 用于系统测试。
  6. Brooks 法则:向进度落后的项目增派人手,只会使进度更加落后。

三、外科手术队伍

在这一章中,作者描述了如何构建一个小型精干的外科手术队伍来进行系统编程:

  1. 同样有两年经验而且在收到同样培训的情况下,优秀的专业程序员的生产效率是较差的程序员的 10 倍。
  2. 小型、精干队伍是最好的。因为系统编程成本的主要组成部分是相互的沟通和交流,以及更正沟通交流不当所引起的不良结果。所以系统应该由尽可能少的人员来开发。
  3. 如果在一个 200 人的项目中,有 25 个最能干和最有开发经验的项目经理,那么开除剩下的 175 名程序员,让项目经理来编程开发。
  4. 一个外科手术队伍包括:一个首席程序员、副手、管理员、编辑、两个文秘,以及程序职员、工具维护人员、测试人员和语言专家。在这个队伍中,首席程序员应当具有对意见分歧的独裁权。