注：

本文为《我的读书笔记之人月神话》系列的第四篇，欢迎指正。

=============================================================

交流：

作者先以“巴比伦塔的启示”为引子，提出了他所认为的项目成功的先决条件：

• 清晰的目标
• 人力
• 材料
• 足够的时间
• 足够的技术

本身这些条目都没有问题，但我觉得最后两点有待商榷。不可能等什么都准备到了“足够”的地步才去动手，特别是技术方面，在项目的进程当中去学习也是常有的事儿。

而巴比伦塔的失败，也证明了“交流”和“组织”（交流的结果）的重要性。

交流的可能途径：非正式途径；会议；工作手册

—————————————–

工作量：

以大型项目的数据为依据而研究所得的结论：

工作量=常数 * 指令的数量^1.5

由于我估计作者所从事的项目大都是操作系统级别的，所以书中很多指标都用类似“指令”这些指标来衡量。简单的讲，可以把这里的指令理解为系统的原子特征。指数型增长的趋势，倒也符合正常的逻辑推理。

复杂程度的指导原则：

编译器的复杂度是批处理程序的3倍，操作系统复杂度是编译器的3倍。

批处理和编译器我都写过，只不过那编译器是用高级语言Java写的而已，对于这个复杂度没有太深的体会。如果将来有机会接触到操作系统级别的复杂项目，那倒可以回过头来细细比较一下。

—————————————–

规模：

软件的规模是视其是否使整个应用系统更加有效而言的，并不在于它的绝对成本

• 仅对核心程序设定设定规模目标是不够的，必须把所有方面的规模都编入预算
• 在指明模块有多大的同时，确切定义模块的功能
• 培养开发人员从系统整体出发、面向用户的态度

时间与空间（占用的资源）

1. 项目的粗细程度决定所需的空间大小
2. 对于给定的功能，空间越多，速度越快

如何取得 空间<->时间 的折衷？

1. 从团队成员的编程技能上培训
2. 需要技术积累，开发公用单元构件

技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高

最后，以篇末最经典的一句话总结本文：

数据的表现形式才是编程的根本