《代码大全2》读书笔记一

第一部分 打好基础
第2章 隐喻
重要的研发成果常常产自类比（analogy）。通过把你不太理解的东西和一些你较为理解、且十分类似的东西做比较，你可以对这些不太理解的东西产生深刻的理解。这种使用隐喻的方法叫做“建模”。

目前最合适隐喻：建造软件（Building Software）

第3章 前期准备（ Measure Twice, Cut Once）
测试只是完整的质量保证策略的一部分，而且不是最有影响的部分。

迭代开发往往能够减少“前期准备不足”造成的负面影响，但它不能完全消除此影响。

如果需求变更过于频繁，就建立一套变更控制程序（流程）。

错误处理

架构中应该清楚地说明一种“一致地处理错误”的策略。监测到一个错误时，应该“说”出来。

过度工程

在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积。

变更策略

架构应当清楚地描述处理变更的策略。架构应该列出已经考虑过的有可能会有所增强的功能，并说明“最有可能增强的功能同样也是最容易实现的”。

质量

你不应该担心架构的任何部分。架构不应该包含任何仅仅为了取悦老板的东西。它不应该包含任何对你而言很难理解的东西。你就是那个实现架构的人；如果自己都弄不懂，那怎么实现它？

第2部分 创建高质量的代码
第5章 软件构建中的设计（Design in Construction）
好的高层次设计能提供一个可以稳妥容纳多个较低层次设计的结构。

设计是一个“Wicked Problem” – 你必须把这个问题“解决”一遍以便能够明确地定义它，然后再次解决该问题，从而形成一个可行的方案。

软件设计的最重要目的是管理复杂度（Managing Complexity）。有两类复杂度：

本质的（essential）：一件事物必须具备，不具备就不再是该事物的属性。比如业务逻辑。

偶然的（accidental）：碰巧具有的属性。比如集成环境，编程工具等等。

大脑没法装下整个程序。好的设计，让人在一个时刻可以只专注于一个特定的部分。

你可以把它想做是一种心理上的杂耍（边抛边接：通过轮流抛接，使两个或两个以上的物体同时保持在空中） – 程序要求你在空中（精神上）保持的球越多，你就越可能漏掉其中的某一个，从而导致设计或编码的错误。

理想的设计特征（Desirable Characteristics of a Design）

最小的复杂度（Minimal Complexity）。要避免做出“聪明的”设计。因为“聪明的”设计往往都是难以理解的。如果你设计的方案不能让你在专注于程序的一部分时安心地忽视其他部分的话，这一设计就没什么作用了。

易于维护（Ease of maintenance）

松散耦合（loose coupling）

可扩展性（extensibility）

可重用性（reusability）

高扇入（high fan-in）。高扇入就是说让大量的类使用某个给定的类。这意味着设计出的系统很好地利用了在较低层次上的工具类。

低扇出（low fan-out）。低扇出就是说让一个类里少量或适中（小于7个）地使用其他的类。

可移植性（portability）

精简性（leanness）。伏尔泰曾说，一本书的完成，不在它不能加入任何内容的时候，而在不能删去任何内容的时候。

层次性（stratification）。假设你正在编写一个新系统，其中用到很多设计不佳的旧代码，这时你就应该为新系统编写一个负责同老代码交互的层。在设计这一层时，要让它能隐藏旧代码的低劣质量，同时为新的层次提供一组一致的服务。

标准技术（Standard techniques）

优秀设计师的一项重要特质就是对变化的预期能力。好的程序把变化所带来的影响限制在一个子程序、类或者包的内部。

测试友好的设计，往往是好的设计。

“你在应用某种设计方法时越教条化，你所能解决的现实问题就越少”。请把设计看成是一个险恶的、杂乱的和启发式的过程，不要停留于你所想到的第一套解决方案，而是去寻找合作，探求简洁性，在需要的时候做出原型，迭代，并进一步迭代。你将对自己的设计成果感到满意。

第6章 可以工作的类（Working Classes）
警惕有超过约7个数据成员的类。

优先使用“深层副本（deep copies）”，除非论证可行，才采用“浅层副本（shallow copies）。