《人月神话》读书笔记

 

 

 

这是一本关于人与团队的经久不衰的书，它并非纯理论，当理论和经验之谈混合时，这本书的价值就提升了很多。虽然里面的很多东西你可能会说这些我都知道，但是它可以被广泛应用，在任何行业，道理是没有界限的。

记录如下观点，理解它们，希望有所帮助^__^：

 

 

关于文档

 

• 不要总是习惯在完成一个项目以后再去按照要求提供文档时再编写进度时间，测试时间等。

这一切都必须是在开始项目的时候就完成的。虽然会花费一部分时间，但是对实现代码时的自我监督会有很大的作用，并且使得整个项目的完成系统化，而且会细化对于相关功能的思考，这样就减少了bug的产生。

 

• 进度表包括日期和里程碑，里程碑必须定义清晰作为约束，这样程序员就不会自欺欺人，在进度上弄虚作假。

 

• 一个人不可能永远记得一个程序怎么运作，哪怕是自己编写的，文档的重要性也体现在此。

 

• 必须采用形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施；它们都可以作为表达的标准。

 

• 项目工作手册不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。必须让全项目组的人都能看到，可以利用网络，要随时更新，注意其变更与变更的重要说明。

 

• 高级编程语言中，代码和说明文字合并，很强大，节省了重复的文字说明，又能在代码上表现逻辑关系。

 

 

 

关于设计开发

 

• 遵循自顶而下的方法，从整体到分布，但必须保证系统的可运行性，不管怎样，做出个大体，能做成多少功能就做出多少功能。这样可以及早地发现潜在的问题，提高结构的稳定性，时时检测，还能提高程序员的士气和成就感。功能的添加要一个个加，切不可多管其下，哪怕接口，也一个一个下手。系统不是编写出来的，也不是架构出来的，是培养出来的。当然，有时必须回退，推翻顶层设计，重新开始。

 

• 在物理和数学范畴上，所有的复杂性都可以由规律性概念来表达。在软件上，因为融入了更多的变化与人的思维，所以并不能应验这个道理。我们可以尝试重用和交互，但这也仅仅是避免面对复杂性，而不是你解决了它。解决复杂性的方法：层次化（模块和对象）和增量化（自顶而下），可以在一定程度上提高软件的生产率。

 

• 概念完整性是系统设计中最重要的考虑因素。

 

• 为了系统的完整性和一致性，我们往往要放弃自己得意的创意，理解为了完整性而采取的无需道歉的贵族专制统治。相反，系统外部结构的规定与限制使我们在细节开发上可以完全放心创意，而不用担心是否会造成系统的紊乱。

 

• 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。

 

• 对于非常大型的项目，要将设计方法、体系结构方面的工作与具体分配，实现分离开来，这是获得概念完整性的强有力方法。

 

• 低劣设计和良好设计的区别在于设计方法的完善与合理。良好设计是很容易成功的，但是卓越设计和良好设计就相差了一个数量级。卓越的设计是创造性的成果，更好，更快，代价更小。方法永远只能实现和释放创造性的思维，而不能激发和产生创造性的过程。

 

• 体系结构，设计实现，物理实现的许多工作可以并发进行。并非是流水线过程化的。

 

• 功能表面是平等的，但是总有轻重不同，为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。

 

• 在早期应该制订策略，决定实现功能项目的粗细程度，因为将它们作为整体大包能够节省内存空间，还可以节约市场成本。

 

• 精炼、充分和快速的程序往往是策略上的成功，而不是技术的展示。战略上的突破表现在对数据的重新表达，数据的表现形式是编程的基本。

 

• 为舍弃而计划。

 

• 系统软件开发是减少混乱度的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

 

• 流程图是最不可取的一道工序，因为软件是无法用一副图来描绘整体的，它无法在二维或三维空间里得到表现。分开在多张纸上的图已经混淆了流程图的根本目的。

 

• 第二个系统——在第一个系统上新增功能和修饰是最危险的，增加不必要的耀眼的功能会降低性能，使原来系统结构紊乱，甚至会崩溃。

第二个版本是指开发第一个实际系统所进行的第二次尝试，是需要提前准备计划的。

 

 

 

关于调试更新

 

• 在进行系统调试之前先要保证每个部件都已经可以正常运行。

 

• 构件的更新和项目的变更要遵循量子化，阶段化。量子大，间隔长比较适用，小而密容易变得不稳定。

 

• 项目最后的测试标准不是功能的多样和丰富，而是功能与理解的复杂程度的比值，即对易用性的测量。

 

 

 

关于时间进度

 

• 为了不违背时间上的期限，我们有时候要伤害结果，作调整，有时间规定的项目，时间比质量结果更重要。

 

• 人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。它们的关系其实是呈非线形的。

 

• 向进度落后的项目中添加人手，只会让进度更加落后。因为任务要重新分配，新人员要培训，还有额外的交流与沟通。

 

• 不要把你经营小程序的时间概念带到大型项目中去，是不适用的。

 

• 项目最后造成不可挽回的延迟是源于每天每天的小延迟。每天的任务一定完成，并要附带着做些超额工作，没人能知道明天会怎么样，会有什么会阻碍进度。

 

 

 

 

关于人员

 

• 如果一个开发组的组长不再继续任职，那么选择组长应当另外选择而不是在该组中选择一个人来担任。熟悉项目是可以很快完成的，而人心的不服与整个队伍的散乱是内在的隐患，要绝避免。

 

• 对于大型项目，别忘了加一个对里程碑报告进行维护的计划和控制小组。

 

• 卓越的设计人员并不一定是经验丰富的，过多的经验反而会给思维的扩散加上枷锁。

 

• 一个非大型系统的项目开发队伍人越精简越好，往往两个人，一个项目经理，是最佳的人员使用发法，就像上帝对婚姻的设计。

 

• 开发设计人员与结构师的区别是结构师仅对说明建议一种实现方法并对现有的结构进行分析和建议，有一定的成本意识，不承担实现责任，并且能让开发设计人员对设计有信心。结构师负责产品所有方面的概念完整性。结构师就像电影的导演，而项目经理类似于制片人。