[人月神话]读书笔记3--避免过分设计&&手册与产品一致

画蛇添足（The Second-System Effect）

如果将制订功能规格说明的责任从开发快速，成本低廉的产品的责任中分离出来，那么有什么样的准则和机制来约束

结构师的创造性热情呢？答案是结构师和建筑人员之间彻底仔细和谐的交流。

□结构师的交互准则和机制

实际情况中，尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法。--挑战估算的成果。

成本更低的实现方法：结构师是在向开发人员的做事方式提出挑战。想要成功，结构师必须

1）牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配

2）时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法

3) 对上述的建议保持低调和平静

4) 准备放弃坚持所作的改进建议

一般开发人员会反对体系结构上的修改建议。通常他是对的——当正在实现产品时，某些特性的修改会造成意料不到的成本开销。

□自律——开发第二个系统所带来的后果

在设计第一个项目时，会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为下一个项目的内容。

第二个系统是设计师们所设计的最危险的系统，一种普遍倾向是过分地设计第二个系统。向系统添加很多修饰功能和想法。

开发第二个系统所引起的后果（second-system effect）与纯粹的功能修饰和增强明显不同，也就是说存在对某些技术进行细化、精炼的趋势。

结构师如何避免画蛇添足——开发第二个系统所引起的后果（second-system effect）？

是的，他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰。根据系统基本理念及目的变更，舍弃一些功能。

一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，功能x不超过m字节的内存和n微秒。这些值会在一开始作为决策的向导，在物理实现期间充当指南和对所有人的警示。

项目经理如何避免画蛇添足（second-system effect）？

他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉。他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。

贯彻执行（Passing the Word）

□文档化的规格说明——手册

手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节。同样的它也是结构师主要的工作产物。

手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特征准备一种实现方法，但是他不应该试图支配具体的实现过程。

规格说明的风格必须清晰完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。

如果想保持文字和产品之间的一致性，则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。

对于在整个设计中，保证这些看似琐碎的问题处理原则上的一致性，决不是一件无关紧要的事情。

□形式化定义

形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更快地完成。但是形式化定义的缺点是不易理解。

记叙性文字则可以显示结构性的原则，描述阶段上或层次上的结构，以及提供例子。它可以很容易地表达异常和强调对比的关系它可以解释原因。

将来的规格说明同时包括形式化和记叙性定义两种方式。但必须以一种作为标准，另一种作为辅助描述，并照此明确地进行划分。

□会议和大会

我们把会议分成两个级别：周例会和年度大会--这实际上是一种非常有效的方式。

周例会是每周半天的会议，由所有的结构师，加上硬件和软件实现人员代表和市场计划人员参与，由首席系统结构师主持。

该会议重点是创新，而不仅仅是结论。该小组试图发现解决问题的新方法，然后少数解决方案会被传递给一个和几个结构师，详细地记录到书面的变更建议说明书中。

接着会对详细的变更建议做出决策。这会经历几个反复过程，实现人员和用户会仔细地进行考虑，正面和负面的意见都会被很好地描述。如果达成了共识，非常好；如果没有，则由首席结构师来决定。

周例会的决策会给出迅捷的结论，允许工作继续进行。如果任何人对结果过于不高兴，可以立刻诉诸于项目经理。

随着时间的推移，一些决定没有很好地贯彻，一些小事情并没有被某个参与者真正地接受，其他决定造成了未曾遇到的问题。对于这些问题，有时周例会没有重新考虑，慢慢地，很多小要求，公开问题或者不愉快会堆积起来。为解决这些堆积起来的问题，我们会举行年度大会，典型的年度大会会持续两周。

□多重实现

机器和手册之间往往会在某一天出现不一致，人们通常会忽略手册。因为与机器相比，手册更容易改动，并且成本更低。

当存在多重实现时，情况就不是这样。这时，如实地遵从手册更新机器所造成的延迟和成本的消耗，比根据机器调整手册要低。

□电话日志

一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很不正式，但非常快捷和易于理解。

□产品测试

在最后的分析中，用户是独立的监督人员。在残酷的现实使用环境中，每个细微缺陷都将无从遁形。产品-测试小组则是顾客的代理人，专门寻找缺陷。

细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。