读书笔记: 修改代码的艺术
https://book.douban.com/people/fleure/annotation/2248759/
当你绝望时
<原文开始>对付遗留代码是件苦差事，这一点没什么好否认的。尽管各自情况不同，但有衡量工作价值的方式是相同的：算算你能从中得到什么。对某些人来说也许是薪水——这没什么不好意思的，毕竟人人都得生活。但我认为肯定还有其他什么原因让你成为一个程序员的。</原文结束>
<原文开始>要想在对付遗留代码时保持积极向上的心态，关键是要找到动力。尽管有很多程序员的生活都较小，但工作时有一个良好的环境，有你所尊敬的并且知道如何快乐工作的人做同事仍然是一个非常大的诱惑。</原文结束>
<原文开始>如果你的团队士气低迷，而且是由于代码质量太低而低迷当饿，那么有个办法可以试一试——从项目中找出一组最糟糕的类，将它们置于测试之下。一旦你们作为一个团队共同克服了一个最困难的问题，那么就会感觉一切不过如此了。这种情况我经历得太多了。</原文结束>
## 处理大类
<原文开始>封装是好事情，但可别对测试人员这么说，他们可不这样想。过分庞大的类往往隐藏了过多的东西。</原文结束>
职责识别
<原文开始>关键是要能够看清职责并学习如何将它们很好地分离开来。</原文结束>
<原文开始>我们并没有创造出新的职责，而仅仅是识别出本来就存在的职责。</原文结束>
<原文开始>如果你迫切需要测试一个私有方法，那么该方法就不应该是私有的；如果将它改为公有会带来麻烦，那么可能是因为它本就应属于另一个独立的职责。</原文结束>
<原文开始>寻找成员变量和方法之间的关系。“这个变量只被这些方法使用吗？”</原文结束>
<原文开始>当一个类的接口呈现出负责多样事务的形态时，它就在接口层面违反了单一职责原则。</原文结束>
<原文开始>然而我们最为关心的 SRP 违反是实现层面的。简单地说就是，我们关心的是该类是否真的做了这些事情，还是仅仅将其委托给其他的类来完成。如果属于后者，那么该类并不能算是一个巨大的单片类；而只不过是一大帮小类的“前端”，一个更容易掌控的 facade。</原文结束>
## 反省你们的交流或讨论
<原文开始>在对付遗留代码时，我们一般都不愿看到系统里面再出现新的抽象了。</原文结束>
<原文开始>代码基中一些其他代码也有很漂亮的，但大块大块的过程式代码仿佛对人有种催眠的魔力：吸引人再往里面加代码。</原文结束>
<原文开始>实际编码可不像纸上谈兵那样只要意思到了就行，而是需要满足更强的约束，但若是在交流与实际编码之间没有一个牢固的共性，就得问问为什么了。</原文结束>
## 目标测试
<原文开始>许多特征测试就像定心丸一样。它们不去测试大量的特殊情况，而只是检验某些特定的行为是否存在。在一番移动或提取代码的重构之后，只要看到这些行为仍然存在，我们就可以放心地告诉自己：我们的重构保持了行为。</原文结束>
## 影响和封装
<原文开始>我在向人们展示本书中的一些解依赖技术时，他们常常会指出许多解依赖技术都破坏了封装性。没错，的确如此。... 封装有助于我们对代码进行推测。... 没错，打破封装会令代码中的影响推测变得更难，然而若是最终我们能够给出具有很好的说明和阐述作用的测试，情况就恰恰相反了。因为一旦一个类有了测试用例，就可以使用这些测试用例来更为直接地进行影响推测了。</原文结束>
<原文开始>实际上封装与测试覆盖也并不总是冲突的，只不过，当它们真的发生冲突时，我会倾向于选择测试覆盖。通常它能够帮助我实现更多的封装。</原文结束>
## 修改时应该测试哪些方法
<原文开始>倘若你的代码结构良好，则其中的大多数方法的影响结构也会比较简单。实际上，衡量软件好坏的标准之一便是，看看该软件对外部世界的相当复杂的影响能否由代码内的一组相对简单得多的影响所构成。</原文结束>
进行影响推测的工具：
<原文开始>每门语言中都存在所谓的“防火墙”，即能够阻止影响继续传播的语言结构。</原文结束>
<原文开始>我们对影响的扩大范围的限制越是严厉，便起程序来就越容易，从而减少理解一段代码所需的前提知识。最极端的情况便是使用像 scheme 或 haskell 这样的函数式编程语言来编程。</原文结束>
## 时间紧迫，但必须修改
<原文开始>本章罗列了一系列技术，借助于它们，你无需将现有类纳入测试便可以对其进行修改。从设计的角度上讲，很难说清到底应该怎样来理解它。许多时候，这么做使得我们能够在新旧职责之间拉开一段距离。换句话说，我们正朝着更好的设计前进。然而在另一些情况下，之所以去创建一个新类唯一的原因就是我们想要编写受测试的新代码，而目前还没有时间将那个现有类纳入测试。这是个很现实的情况。当你在实际项目中这样做时，将会看到新的类和方法在旧的、巨大的类旁不断冒出来。但接下来会发生一件有趣的事情：一段时间后，你对于总是避开旧类庞大的身躯变得厌烦了，于是开始试图将它纳入测试中。而这项工作的一个成分就是去熟悉你要纳入测试的类，所幸的是，因此把它纳入测试也就变得越来越不可怕了。此外，这项工作的另一个部分就是要避开厌烦情绪。</原文结束>
## 时间紧迫，但必须修改
新生方法：
<原文开始>
1. 确定修改点
2. 如果你的修改可以在一个方法中的一处地方以单块连续的语句序列出现，那么在修改点插入一个方法调用，而被调用的就是我们下面要编写的、用于完成有关工作的新方法
</原文结束>
<原文开始>只要你发现待添加的功能可以写成一块独立的代码，或者暂时还没法用测试来覆盖待修改方法时，我都建议你采用新生方法。这比往原方法中添加代码好多了。</原文结束>
<原文开始>新旧代码被清楚地隔离开。这样即使暂时没法将旧代码置于测试之下，至少还能单独去关注所要做的改动，并在旧代码之间建立清晰的接口。</原文结束>
新生类
<原文开始>我们想要添加的只是一个小小的功能，可以将它放入一个现有的类中，但问题是我们无法将这个类放入测试用具。哪怕至少能将它编译进测试用具，也还能试着用新生方法技术，只可惜有时候连这点运气都没有。</原文结束>
<原文开始>弄清这两种情况的关键在于认识到虽说它们之间的动机不同（一个是为了避免职责混淆，另一个则是因原类无法放入测试用具），但从结果来看其实并无显著区别。一个功能是否强大到足以成为一个新的职责，完全凭个人判断。</原文结束>
## 解依赖
<原文开始>依赖性往往是进行测试的最为明显的障碍。这表现在两个方面：一是难以在测试用具中实例化目标对象；二是难以在测试用具中运行方法。通常在遗留代码中你得先解依赖而后才能将测试安置到位。</原文结束>