《人月神话读书笔记》--第二周

人月神话读书笔记

第二周

第一章 焦油坑

• 编程系统产品

只有编程系统产品才是真正有用的产品，是大多数系统开发的目标。

• 职业的乐趣

• 创建事物的纯粹快乐；eg: 当自己写完第一个hello world时候的欣喜

• 来源于开发对他人有用的东西；eg: 现在的组队项目bbs

• 将相互啮合的零件组装在一起

• 持续学习，和don't repeat yourself（《程序员修炼之道》里有讲） 原则相一致

• 来自于在易于驾驭的介质上工作

• 职业的苦恼

1. 源于追求完美
2. 由他人设定目标，供给资源和提供信息。
   1. 依靠他人不合理的程序真的很痛苦
3. debug真的很酸爽
4. 产品完成了却显得过时了

第二章 人月神话

缺乏合理的进度安排是造成项目滞后的最主要原因！

• 我们对估算技术缺乏有效的研究（《程序员修炼之道》有讲估算的技巧），更加严肃的说，它反映了一种悄无声息但并
  不真实
  的假设——
  一切都将运作良好

  • 这句话说的太精辟了！一切都将运作良好根本不存在的！以前定每日计划每周计划，都坚持不久了就会fact！=plan，这就是自己在列计划的时候，默认了一切都将运作良好

• 错误的将工作量和进度相互混淆

  • 每日能完成的就那么多，进度需求大了，你还是能完成那么多，不会有超能力

• 对自己的估算缺乏信心

• 对进度缺少跟踪和监督

• 当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。

  • 这就像汽油灭火一样，只会更糟。
  • 当计划赶不上变化导致进度变慢，不应该用蛮力来搞定。

• 乐观主义

错误的假设：一切都将运作良好，每一项任务仅花费它所”应该“花费的时间

所遇到的延迟是一个概率分布曲线，‘不会延迟’具有限定的概率。

• 人月

人员和时间的关系：较小的组合更方便

我觉得我们可以最近前后端分开工作，前后端的交流给前后端的组长来完成。

• 系统测试

单元调试和系统测试是对进度安排最大的可能出错的地方。系统测试的安排常常是编程中最不合理的部分。

软件任务经验安排的经验法则：

1/3 计划

1/6 编码

1/4 构件测试和早期系统测试

1/4 系统测试，所有的构件已完成

这也是对我们的团队project的一个指导吧，给的时间看起来就不多了，实际留给编码的时间更少

• 空泛的估算

做出可靠的估计是很难的（尤其当缺乏数据的时候）

解决方案：

开发并推行生产率图表、缺陷率图表、估算规则等

坚持估计，确信自己的经验和直觉总比从期望派生出来的结果要强的多

• 重复产生的进度灾难

在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成。从而无需重新确定时间进度表！

向进度落后的项目中增加人手，只会使项目更加落后

第三章 外科手术队伍

效率搞和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平。

• 问题：效率&完整性 vs 时间上的要求
• Mills的建议（职责分配）
  1. 首席程序员
  2. 副手
  3. 管理员
  4. 编辑
  5. 两个文秘
  6. 程序职员
  7. 工具维护人员
  8. 测试人员
  9. 语言专家

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

• 概念的完整性

这应该是最重要的考虑因素，它就是说，为了反应一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。

• 获得概念的完整性

目标是易用性，功能和概念的复杂程度的比值才是系统设计的最出众测试标准，但是功能本身或者简洁都无法成为一个好的设计评判标准。

• 贵族专制统治和民主政治

概念的完整性必须由一个人，或者非常少数互有默契的人员来实现。

• 必须将体系结构和实现区分开来

第五章 画蛇添足

• 结构师的交互准则和机制

• 牢记开发人员承担创造性和发明星的实现责任，所以结构是只能建议，而不能支配

• 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法

• 对上述的建议保持低调和不公开

• 准备放弃所坚持作的改进建议

• 自律——开发第二个系统所带来的后果