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