《修改代码的艺术》 - 书摘精要

(序) 需求总是在改变；

(前言)

没有编写测试的代码是糟糕的代码；

编程可以是一项回报丰厚并让人感觉是一种享受的工作；

(P4) 在不改变软件行为的前提下改善其设计的举动称为重构；

(P6)

问题总是不可避免；

要想保持熟练，唯一的途径就是经常练习；

(P8) 精湛的软件改动就像精湛的外科手术一样，除了细心之外还要有深厚的技术。如果没有辅以正确的工具和技术，即便“小心下手”也起不到多大作用；

(P11) 一个需要耗时十分之一秒才能执行完的单元测试，就已算是一个慢的单元测试了；

(P14)

依赖性是软件开发中最为关键的问题之一；

遗留代码的困境 —— 我们在修改该代码时，应当有测试在周围“护”着。而为了将这些测试安置妥当，我们往往又得先去修改代码；

(P22) 遵循为独立单元编写测试的理念，我们最终写出来的就会是短小而易于理解的一个个测试，这会使得我们的代码变得更易理解；

(P40) 重构 —— 对软件内部结构的一种调整，目的是在不改变软件的外在行为的前提下，提高其可理解性，降低其修改成本；

(P72)

依赖倒置原则 ——

如果你的代码依赖于一个接口，那么这个依赖一般来说是很次要的。除非这个接口发生改变，否则你的代码是无需改变的，而接口的改动频率通常情况下要远远低于接口背后的那些代码。在接口不变的前提下，不管是修改实现了该接口的类，还是添加实现了该接口的新类，接口的客户代码都不会受到影响；

因为这个原因，较好的做法是让代码依赖于接口或抽象类，而不是依赖于具体类。当代码依赖的是较为稳定的东西时，因特定改动而导致大规模重编译的可能性也就被降到了最低；

当为了解依赖而往设计中引入了额外的接口和包之后，重新构建整个系统的时间就会稍微变长一点。因为有更多的文件要去编译。但基于需要被重编译的文件而进行的局部重建的平均时耗反而大大缩短了；

(P79) 测试驱动开发与遗留代码 —— 测试驱动开发的最有价值的一个方面是它使得我们可以在同一时间只关注于一件事情。要么是在编码，要么是在重构；永远也不会在同一时刻做两件事情；

(P116) 好的设计应当是可测试的，不具可测试性的设计是糟糕的；

(P180) “CRC” —— “类”(Class)、“职责”(Responsibility)和“协作”(Collaboration)；

(P200) 单一职责原则 —— 每个类应该仅承担一个职责：它在系统中的意图应当是单一的，且修改它的原因应该只有一个；

(P212) 接口隔离原则 —— 如果一个类体积较大，那么很可能它的客户并不会使用其所有方法。通常我们会看到特定用户使用特定的一组方法。如果我们给特定用户使用的那组方法创建一个接口，并让这个大类实现该接口，那么用户便可以使用“属于它的”那个接口来访问我们的类了。这种做法有利于信息隐藏，此外也减少了系统中存在的依赖。即当我们的大类发生改变的时候，其客户代码便不再需要重新编译了；

(P231) 开放/封闭原则 —— 开放/封闭原则是由Bertrand Meyer首先提出的。其背后的理念是：代码对于扩展应该是开放的，而对于修改则应该是封闭的。也就是说，对于一个好的设计，我们无需对代码做太多的修改就可以添加新的特性；

(P249) 编程是关于同一时间只做一件事情的艺术；

(P260) 接口应传达职责而非实现细节，这样的接口令代码易于阅读和维护；

(P289) 提取接口时并不一定要提取类上的所有公有方法，你可以依靠编译器来帮助你发现哪些方法需要加到接口上去；