第五章 画蛇添足
1. 本章的目标：结构设计师要避免向系统中添加很多不实际的功能（避免
画蛇添足）。
2. 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获
得对设计的信心，并且不会混淆各自的责任分工。
3. 面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低
的实现方法--挑战估算的结果。后者是固有的主观感性反应。此时，结构师
是在向开发人员的做事方式提出挑战。想要成功，结构师必须
牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而
不能支配；
时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能
达到目标的方法；
对上述的建议保持低调和平静；
准备放弃坚持所作的改进建议。
4. 一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，
功能 x 不超过 m 字节的内存和 n 微秒。这些值会在一开始作为决策的向导
，在物理实现期间指南和对所有人的警示。
5. 项目经理必须坚持至少拥有两个系统以上开发经验的结构师的决定。同时
，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和
目标在详细设计中得到完整的体现。
第六章 贯彻执行
1. 问题：项目经理如何确保每个人听从、理解并实现结构师的决策？对于有多个结构师
的小组如何保持系统概念上的完整性。
2. 手册、或者书面规格说明，是一个非常必要的工具。手册是产品的外部规格说明，它
描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
手册不但要描述包括所有界面在内的用户可见的一切，它同时还要描述用户看不见的事物。
后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构
设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实
现过程。
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都
必须重复所有的基本要素，所以所有文字都要相互一致。
3. 规格说明中，形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更
快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描
述阶段上或层次上的结构，以及提供例子。应同时包括形式化和记叙性定义两种方式。
4. 通过会议的方式，开发人员进行沟通和讨论问题。
5. 不同实现之间严格要求相互兼容。如果起初至少有两种以上的实现，那么定义会更加
整洁和规范。
6. 对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜
测一边工作。
一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。
每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很
不正式，但非常快捷和易于理解。
7. 在最后的分析中，用户是独立的监督人员。在残酷的现实使用环境中，每个细微缺陷
都将无从遁形。产品测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测
试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方
面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手
，与设计同时实现的重要环节。
