注：

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

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

这次谈得是贯彻执行的问题。换句话说，也就是如何确保一个拥有诸多结构师和编程人员的项目团队，对整个系统保持概念上的完整性？

最好的办法就是文档化的规格说明——手册！
这里的手册应该包括各种说明文档，设计文档，甚至备忘录，只要是对理解系统的设计有帮助的，应该都可以归入在内。

谈到手册，可能刚开始工作或者比较偏好编程的朋友会觉得比较头大，不太喜欢。刚开始的时候我也是如此，可随着时间的推移和工作经历的增多，却越来越发现手册的重要性。大到设计思想，小到会议记录，手册就像幻灯片一样将整个系统显示在你的面前。

那么，应该怎样书写文档（手册？manual？document？whatever），怎么样的文档才能算是好文档？

先来回答后面那个问题：

清晰、完整和准确：精确比生动更重要

好在搞技术的大多数都是理性思维，不会为了华丽辞藻在那边苦思冥想半天。

写到这里的时候忽又想起在之前那家日企得到的经验：尽量用简短的英文来描述，不用长句式。一来小日本不太擅长也不喜欢英语，二来长句式在理解上确实不如短句来的一目了然。

再回过头来说说第一个问题，人月神话的作者给出了两种用来书写文档的定义：形式化定义和记叙性定义。

但是作者并未就这两种定义给出具体的解释和说明，这里就简单谈谈我的理解：

所谓的形式化定义就是用一种有规则的、有限制或有约定的语言（自然语言、计算机语言、伪代码，均可），来描述系统的一些关键特征，或者表达文档所关注的重点目标对象。而记叙性定义，就是简单的用大篇幅的文字来描述上述特征或目标。

两者各有优缺点：

• 形式化定义比较精确，倾向完整，但不易理解（总不能保证每个阅读手册的人都是搞编程的吧），对于有些场景很难描述清楚；
• 记叙性定义能够表达结构性原则，描述阶段或层次上的结构，表达异常和强调对比的关系，并解释原因，却也因此而显得有些累赘，索引和定位都比较差。

再补充一点，形式化定义是一种设计实现，仅仅用于外部功能（描述系统必须做什么）。潜在的问题是：实现可能过度地规定了外部功能（声明了自己到底做了些什么），当实现充当标准时，必须防止对实现的任何修改（这话听着很拗口，其实仔细想想确实如此）。

如何取舍，关键还是看系统本身的特性更适合哪种方式，以及文档编写人员的习惯。注意：两者只能以其中之一为标准，另一个为辅助。
另外，为保持一致性，须由少数人对大家的想法进行整理和汇总，对看似琐碎或不重要的问题进行判断并得出结论，使之体现在文档中。

文档的话题就说到这里，回到前面“贯彻执行”的主题。有多种很好的方式方法可以利用：

周例会：
建议以书面形式在会议之前分发，要求事先Review原先的设计并作出思考，提出少数解决方案，传递给结构师。
当需要对变更作出决策时 ==> 强调首席结构师的最终决策权，避免妥协和拖延（这个很重要，我已经有所切身体会了）

年例会：
由于各种原因，在周例会中可能未予以考虑的某些问题会堆积起来。有时候程序员都是很固执的性格，这些问题的一直存在，会让系统的执行变得困难。年例会就是针对这个来考虑的。大家在会上把那些问题列举出来，进行表决或者讨论，时间可能会持续几周，每日更新手册说明，记录前一日的各项决定（可能需要一定的额外工作量）。

目前为止我没有参加过此类的年例会，可能超大型的项目才会有这种可能性。不过听上去还是很不错的主意。

对规格说明有疑问时：

• 不要自己猜测

很多新手常会犯这个错误

• 打电话询问相关结构师

有些人就是怕麻烦，或者怕开口交流，需要努力克服

• 结构师记录并定期整理、分发给相关人员

啊哦，又多了点工作量

• 不需很正式

似乎是好消息

以测试作为驱动动力：
开发和测试不是两个冤家，测试能够推动系统更加贯彻的执行。

就先到这里吧。