《Working Effectively with Legacy Code》经典读后感有感

《Working Effectively with Legacy Code》是一本由Michael Feathers著作，Prentice Hall出版的Paperback图书，本书定价：USD 64.99，页数：456，特精心收集的读后感，希望对大家能有帮助。

《Working Effectively with Legacy Code》读后感(一)：重构与测试的纠结

如果你想重构,重要的前提就是有强力的测试.哪怕你有自动化重构工具在手.

如果你想对既有代码进行测试,你就必须先重构,因为代码根本就没有办法在测试工具中实例化.

……

新写的代码大多是可以先进行测试,然后再挂接到原有代码中.而对付遗留的代码,我们则需要一点点地把代码抠出来测试.修改遗留代码时,我们需要将代码解依赖出来,建立其测试,然后才对它进行修改.

并不是所有的重构手法都需要测试,特别是我们已经有了自动化的重构工具.书中说的一些解依赖技术就是一些特殊的重构技术.只要我们小步地前进,细心地操作,并借且自动化重构工具,无须测试就能进行重构.而这些重构技术的目标就是为重构出来的代码建立测试.一旦测试建立,则可对代码进行更为自信的修改,则可对代码进行更自信的进一步重构.

《Working Effectively with Legacy Code》读后感(二)：重新翻阅，此发现值得再次拥有

遗留代码

1.为什么这个问题重要？

普遍性- 大多数程序员的每天工作都是这样子的；

重要性- 如果出问题，影响很大，因为系统已经上线

典型性 - 大多是人改代码都是凭本能，问题很多

2. 什么是遗留代码？

expensive to change

code without test

3. 遗留代码有什么特点？

新增代码只有已有代码的1/100，1/1000

代码已经有客户使用， 要稳定还有增加性功能

4. 修改遗留代码的原因： fix bug 、 加功能、重构、优化

5. 修改遗留代码的两种方式： 本能 vs 专业（ 修改和祈祷 vs 覆盖和修改）

6 . 遗留代码的冲突图和解决方式

遗留代码的冲突图

7 重构的算法

- 找到你要修改的地方

- 寻找测试点

- 建立安全网

- 建立测试

- 修改

- 验证

《Working Effectively with Legacy Code》读后感(三)：内容组织是灾难

我整理了一下笔记之后，直接把评分从 4 星降到了 3 星。这本书的章节的安排简直是匪夷所思。粗看目录，还以为是 Part II、Part III 能当 cookbook 用，仔细读了才发现不是那么回事儿。

我举几个例子。

(1) Chapter 14 - Dependencies on Libraries 这一章的全部内容只有 1.5 页，你没有看错，是 1.5 页。我也不知道作者为什么要把它放到 Chapter 13 - I Need to Make a Change, but I Don’t Know What Tests to Write 和 Chapter 15 - My Application Is All API Calls 中间。其实 Dependencies on Frameworks/Libraries 的问题在 Chapter 10 - I Can't Run This Method in a Test Harness 中已经讲了。

(2) Chapter 13 - I Need to Make a Change, but I Don’t Know What Tests to Write 简单讲了测试要怎么写、要写哪些测试；然后 Chapter 18 - My Test Code Is in the Way 讲了两个问题：一是测试类怎么命名，二是测试类的代码应该放哪里。这紧密相关的内容，你分两章就算了，一个在 13 章、另一个在 18 章是几个意思？完全估不到作者的思路。

(3) 最灾难的是 Chapter 25 - Dependency-Breaking Techniques。一共 24 个重构/测试小技巧，我今天才发现作者是按小技巧名字的首字母排序的！然后这些小技巧的名字还是作者自己起的，所以这个顺序本质上是随机的。大哥你好歹分一下类吧？有的技巧是修改测试目标类、有的是修改 dependency，大部分是 object seam 的范畴、小部分是 link seam/preprocessing seam。你就大喇喇的 24 条一起扔那儿，这样好吗？

我个人对这 24 条的分类：

03. Definition Completion / 13. Link Substitution / 23. Template Redefinition / 24. Text Redefinition 是 link seam/preprocessing seam 技巧，我基本用不上，先放一边。

04. Encapsulate Global References / 05. Expose Static Method / 11. Introduce Instance Delegator 这三条超简单的，算是边缘的辅助技能。

剩下的技巧大范围分成两类：一是逃离 dependency 而不消灭 dependency，二是通过 substitution (包括 fake/mock) 消灭 dependency。

第一大类是 02. Break Out Method Object / 06. Extract and Override Call / 17. Pull Up Feature / 18. Push Down Dependency。它们本质都是把测试目标类一分为二，把测试目标方法挪到脱离 dependency 的新类中 (另一个新类中，dependency 依然存在)。

第二大类是这么一个思路：(1) 要把 dependency 放到 object seam 里，否则没法做替换；(2) 如果 dependency 的替身不好做，我们就虚化、弱化 dependency 的结构；(3) 给 dependency 做替身。

第一步可以用 07. Extract and Override Factory Method / 08. Extract and Override Getter / 14. Parameterize Constructor / 15. Parameterize Method / 19. Replace Function with Function Pointer / 20. Replace Global Reference with Getter / 22. Supersede Instance Variable.

第二步可以用 01. Adapter Parameter / 09. Extract Implementer / 10. Extract Interface / 16. Primitivize Parameter.

第三步可以用 12. Introduce Static Setter / 21. Subclass and Override Method .

第二大类技能最常见的落脚点是 21. Subclass and Override Method.

补一张我个人的分类图：

最后我要吐槽一下 09. Extract Implementer / 10. Extract Interface。如果你有一个 Dependency class，我们叫它 ”Dep“ 好了。如果你改成了一个 interface IDep 和一个实现 class Dep implements IDep，这个技术叫 10. Extract Interface；如果你改成一个 interface Dep 和一个实现 class DepImpl implements Dep，这个技术叫 09. Extract Implementer。作者的意思是：有时候你不好判断 "Dep" 是更适合做 class name 还是 interface name。OK, fair enough，但是你这两个 topics 一个写了 7 页，一个写了 6 页，我只能觉得你是闲得 XX。

17. Pull Up Feature / 18. Push Down Dependency 本质也是一样的。