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

画蛇添足&＃xff08;The Second-System Effect&＃xff09;

□结构师的交互准则和机制
实际情况中&＃xff0c;尽早交流和持续沟通能使结构师有较好的成本意识&＃xff0c;以及使开发人员获得对设计的信心&＃xff0c;并且不会混淆各自的责任分工。
面对估算过高的难题&＃xff0c;结构师有两个选择&＃xff1a;削减设计或者建议成本更低的实现方法。--挑战估算的成果。

成本更低的实现方法&＃xff1a;结构师是在向开发人员的做事方式提出挑战。想要成功&＃xff0c;结构师必须
1&＃xff09;牢记是开发人员承担创造性和发明性的实现责任&＃xff0c;所以结构师只能建议&＃xff0c;而不能支配
2&＃xff09;时刻准备着为所指定的说明建议一种实现的方法&＃xff0c;同样准备接受其他任何能达到目标的方法
3) 对上述的建议保持低调和平静
4) 准备放弃坚持所作的改进建议
一般开发人员会反对体系结构上的修改建议。通常他是对的——当正在实现产品时&＃xff0c;某些特性的修改会造成意料不到的成本开销。

□自律——开发第二个系统所带来的后果
在设计第一个项目时&＃xff0c;会面对不断产生的装饰和润色功能。这些功能都被搁置在一边&＃xff0c;作为下一个项目的内容。
第二个系统是设计师们所设计的最危险的系统&＃xff0c;一种普遍倾向是过分地设计第二个系统。向系统添加很多修饰功能和想法。
开发第二个系统所引起的后果&＃xff08;second-system effect&＃xff09;与纯粹的功能修饰和增强明显不同&＃xff0c;也就是说存在对某些技术进行细化、精炼的趋势。

结构师如何避免画蛇添足——开发第二个系统所引起的后果&＃xff08;second-system effect&＃xff09;&＃xff1f;
是的&＃xff0c;他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险&＃xff0c;运用特别的自我约束准则&＃xff0c;来避免那些功能上的修饰。根据系统基本理念及目的变更&＃xff0c;舍弃一些功能。
一个可以开阔结构师眼界的准则是为每个小功能分配一个值&＃xff1a;每次改进&＃xff0c;功能x不超过m字节的内存和n微秒。这些值会在一开始作为决策的向导&＃xff0c;在物理实现期间充当指南和对所有人的警示。

项目经理如何避免画蛇添足&＃xff08;second-system effect&＃xff09;&＃xff1f;
他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时&＃xff0c;保持对特殊诱惑的警觉。他可以不断提出正确的问题&＃xff0c;确保原则上的概念和目标在详细设计中得到完整的体现。

贯彻执行&＃xff08;Passing the Word&＃xff09;

□文档化的规格说明——手册
手册是产品的外部规格说明&＃xff0c;它描述和规定了用户所见的每一个细节。同样的它也是结构师主要的工作产物。
手册不但要描述包括所有界面在内的用户可见的一切&＃xff0c;它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴&＃xff0c;而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特征准备一种实现方法&＃xff0c;但是他不应该试图支配具体的实现过程。
规格说明的风格必须清晰完整和准确。用户常常会单独提到某个定义&＃xff0c;所以每条说明都必须重复所有的基本要素&＃xff0c;所以所有文字都要相互一致。这往往使手册读起来枯燥乏味&＃xff0c;但是精确比生动更加重要。
如果想保持文字和产品之间的一致性&＃xff0c;则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。
对于在整个设计中&＃xff0c;保证这些看似琐碎的问题处理原则上的一致性&＃xff0c;决不是一件无关紧要的事情。

□形式化定义
形式化定义是精确的&＃xff0c;它们倾向于更加完整&＃xff1b;差异得更加明显&＃xff0c;可以更快地完成。但是形式化定义的缺点是不易理解。
记叙性文字则可以显示结构性的原则&＃xff0c;描述阶段上或层次上的结构&＃xff0c;以及提供例子。它可以很容易地表达异常和强调对比的关系它可以解释原因。
 将来的规格说明同时包括形式化和记叙性定义两种方式。但必须以一种作为标准&＃xff0c;另一种作为辅助描述&＃xff0c;并照此明确地进行划分。

□会议和大会
我们把会议分成两个级别&＃xff1a;周例会和年度大会--这实际上是一种非常有效的方式。
周例会是每周半天的会议&＃xff0c;由所有的结构师&＃xff0c;加上硬件和软件实现人员代表和市场计划人员参与&＃xff0c;由首席系统结构师主持。
该会议重点是创新&＃xff0c;而不仅仅是结论。该小组试图发现解决问题的新方法&＃xff0c;然后少数解决方案会被传递给一个和几个结构师&＃xff0c;详细地记录到书面的变更建议说明书中。
接着会对详细的变更建议做出决策。这会经历几个反复过程&＃xff0c;实现人员和用户会仔细地进行考虑&＃xff0c;正面和负面的意见都会被很好地描述。如果达成了共识&＃xff0c;非常好&＃xff1b;如果没有&＃xff0c;则由首席结构师来决定。
周例会的决策会给出迅捷的结论&＃xff0c;允许工作继续进行。如果任何人对结果过于不高兴&＃xff0c;可以立刻诉诸于项目经理。

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

□多重实现
机器和手册之间往往会在某一天出现不一致&＃xff0c;人们通常会忽略手册。因为与机器相比&＃xff0c;手册更容易改动&＃xff0c;并且成本更低。
当存在多重实现时&＃xff0c;情况就不是这样。这时&＃xff0c;如实地遵从手册更新机器所造成的延迟和成本的消耗&＃xff0c;比根据机器调整手册要低。

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

□产品测试
在最后的分析中&＃xff0c;用户是独立的监督人员。在残酷的现实使用环境中&＃xff0c;每个细微缺陷都将无从遁形。产品-测试小组则是顾客的代理人&＃xff0c;专门寻找缺陷。
细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面的原因&＃xff0c;设立测试小组是使设计决策得以贯彻执行的必要手段&＃xff0c;同样也是需要尽早着手&＃xff0c;与设计同时实施的重要环节。