《人月神话》阅读笔记（1）

《人月神话》一开始我觉得这本书重点是在软件工程，但后来我觉得更准确的说法是，《人月神话》是讲软件工程中人与团队关系的。
一个由个人完成的“小”程序，和一个由团队完成的“大”程序，有根本性的不同，《人月神话》将讨论的是那些由团队进行开发的大型程序。另外，软件工程的项目管理也和其他类型的项目管理有很大不同，软件工程往往更复杂，存在很多“不可见”的东西。

书中第五章讲了画蛇添足

在开发第1个系统时，结构师倾向于简洁，之后不断产生装饰和润色。第二个系统是最“危险”的，往往会过度设计。而随后的系统由于之前的经验会相互验证，因此能识别出不够通用的部分。

第九章讲了一个削足适履的问题。

这一章讨论了内存成本问题。基本的教训是：

制定预算
确切定义模块的功能
需要有人进行宏观掌控。因为团队内的成员都是争取小红花的学生，都在局部优化自己的程序而很少考虑整体影响。
另外的措施是：

让用户选择模块，减少不需要的内存占用。
让“时间”换“空间
此外，革新的算法或者数据结构也能从根本上优化。

（不过，书中讨论的关于内存的限制情况已经和如今差别巨大。例如对于“时间”和“内存”的折中，从我个人在做交互工具的经验而言，“时间”往往比较重要，如果能用多点的“空间”来换取，一般会做这种交易。）

书中第三章 外科手术队伍中提到在计算机领域的会议中，常常听到年轻的软件经理声称他们喜欢由头等人才组成的小型、精干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。其实我们也经常有相同的看法。但这种幼稚的观点回避了一个很困难的问题一-如何在有意义的时间进度内创建大型的系统?那么就让我们现在来仔细讨论一下这 个问题的每一个方面。

第一，传统两人队伍，每人负责一部分工作的设计和实现；外科手术团队中，外科医生和副手了解所有的设计和全部的代码，保证了工作概念上的完整性。
第二，传统团队中，大家平等，出现观点的差异时，不可避免的需要讨论和进行相互的妥协和让步，由于工作和资源的分解，不同的意见导致会造成策略和接口上的不一致；外科手术团队中，外科医生和副手是上下级关系，并且不分解问题，可以达到客观上的一致性。
第三，外科手术团队中，其他人员职能的专业化分工是高效的关键，它使得成员之间采用非常简单的交流模式。