《代码大全2》读书笔记--2
第三章：三思而后行：前期准备
1、核对表
①是否辨明了自己所从事的软件的类型，并对所用的开发方法做出相应的剪裁？（许多项目是高度迭代的，某些则应该是序列式的）
②是否充分明确定义了需求？而且需求足够稳定，能够开始构建了？（详见需求核对表）
③是否充分明确的定义了架构，以便开始构建？（详见架构核对表）
④是否已经指出当前项目中独有的风险？（以避免构建活动面临不必要的风险）
2、在项目初期关注质量、发现问题，远比后期发现解决成本更低。
测试只是完整的质量保证策略的一部分，而且不是最有影响的部分。
迭代开发往往能够减少“前期准备不足”造成的负面影响，但它不能完全消除此影响。
如果需求变更过于频繁，就建立一套变更控制程序（流程）。
错误处理
架构中应该清楚地说明一种“一致地处理错误”的策略。监测到一个错误时，应该“说”出来。
过度工程
在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积。
变更策略
架构应当清楚地描述处理变更的策略。架构应该列出已经考虑过的有可能会有所增强的功能，并说明“最有可能增强的功能同样也是最容易实现的”。
质量
第五章：软件构建中的设计
好的高层次设计能提供一个可以稳妥容纳多个较低层次设计的结构。
设计是一个“Wicked Problem” – 你必须把这个问题“解决”一遍以便能够明确地定义它，然后再次解决该问题，从而形成一个可行的方案。
软件设计的最重要目的是管理复杂度。有两类复杂度：
-
本质的：一件事物必须具备，不具备就不再是该事物的属性。比如业务逻辑。
-
偶然的：碰巧具有的属性。比如集成环境，编程工具等等。
大脑没法装下整个程序。好的设计，让人在一个时刻可以只专注于一个特定的部分。
你可以把它想做是一种心理上的杂耍（边抛边接：通过轮流抛接，使两个或两个以上的物体同时保持在空中） – 程序要求你在空中（精神上）保持的球越多，你就越可能漏掉其中的某一个，从而导致设计或编码的错误。
理想的设计特征
-
最小的复杂度。要避免做出“聪明的”设计。因为“聪明的”设计往往都是难以理解的。如果你设计的方案不能让你在专注于程序的一部分时安心地忽视其他部分的话，这一设计就没什么作用了。
-
易于维护
-
松散耦合
-
可扩展性
-
可重用性
-
高扇入。高扇入就是说让大量的类使用某个给定的类。这意味着设计出的系统很好地利用了在较低层次上的工具类。
-
低扇出。低扇出就是说让一个类里少量或适中（小于7个）地使用其他的类。
-
可移植性
-
精简性。伏尔泰曾说，一本书的完成，不在它不能加入任何内容的时候，而在不能删去任何内容的时候。
-
层次性。假设你正在编写一个新系统，其中用到很多设计不佳的旧代码，这时你就应该为新系统编写一个负责同老代码交互的层。在设计这一层时，要让它能隐藏旧代码的低劣质量，同时为新的层次提供一组一致的服务。
-
标准技术
优秀设计师的一项重要特质就是对变化的预期能力。好的程序把变化所带来的影响限制在一个子程序、类或者包的内部。
测试友好的设计，往往是好的设计。
“你在应用某种设计方法时越教条化，你所能解决的现实问题就越少”。请把设计看成是一个险恶的、杂乱的和启发式的过程，不要停留于你所想到的第一套解决方案，而是去寻找合作，探求简洁性，在需要的时候做出原型，迭代，并进一步迭代。你将对自己的设计成果感到满意。
