05人月神话阅读笔记之三

《人月神话》是大学刚开始就很熟悉的一本书，当时被奉为软件工程的圣书，似乎都要在书架上摆上它才能表明软件工程学生的身份。时至今日我再读它，因为有了之前参与系统的开发的经验，很多的内容都通过记忆得到了验证，读来与大一时的“虽然不懂你在讲什么但好像很有道理” 的体会有了明显的不同。选择一些感触较深的章节写一些理解。

画蛇添足

过度设计的现象常常存在，据我的观察，这种现象往往出现于极度追求完美的人和刚刚经历过首次开发设计不足的经验教训的人。过度设计的系统在最初就引入了过多的复杂性，导致开发举步维艰，这个问题或许在一个架构师有了一定经历后就自然能够解决，但是“第二个系统”的困境出现时，我们可以有意识地约束自己做出一些舍弃。

贯彻执行

世界的规律就是一切往着混乱的方向发展，所以我们往往需要耗费很大的精力将上层的决策向基层贯彻执行。书中提出了几个方法来实现整个团队保持系统的概念完整性。首先是文档化的规格说明，文字是思想传播的载体，也正是文字和纸的出现，前人的思想才能流传至今，这足以证明文档对于维持概念完整性的重要性，文档的编写也需要形式化的定义保证概念的清晰和确定。对于软件开发这样的特殊团队，我们还可以通过建立模块间的结构来将各部分进行整合。虽然有了持久化的文字和代码，语言的交流会更有利于概念的确定，不至于在不同的人那里产生歧义，所以正式的会议和随意的交流都是必须的。书中还提出了多重实现、电话日志和产品测试的方法。

为什么巴比伦塔会失败

巴比伦塔的制造是一个神话故事，但是其中的道理却对今天人们的协作有着重要的启示。软件系统的开发完全通过计算机执行，为什么还是很少有远程协作的企业，这是因为远程协作很容易导致交流的缺失。大型的软件项目开发需要团队中的每个人能及时了解到整个团队在做些什么，这就需要经常的交流。交流的方式可以通过非正式的电话、网络，也需要正式的会议和工作手册。

提纲挈领

我们做课程作业时往往需要交大量的文档，而我们在写这些文档时就像填充八股文一样只考虑制式放弃了思考为什么要将它放在文档中。设计与决策的书面记录是必要的，但是文档存在的本意是为了沟通，我们写文档时应该考虑文档内容的现实指导意义，建立功能划分明确的文档类型和逻辑清晰的文档结构。