重构：改善既有代码的设计——笔记

思维导图（转载）

https://www.processon.com/view/60fbcae1e401fd7e997aa66e

重构的基本功：识别坏味道、测试先行、行为保持

1. 识别坏味道、测试先行、行为保持的变更动作，是重构的基本功。

2. TDD：测试驱动开发 先写测试，再写实现代码，用测试来驱动代码的设计和开发。
   TDD 的基本循环（三个步骤）——也叫 红绿重构循环（Red-Green-Refactor）

   1. Red（写失败的测试）
      写一个还没实现功能的测试代码，运行它，测试必然失败。

   2. Green（写代码通过测试）
      写最简单的代码让测试通过，不求完美，只求通过。

   3. Refactor（重构代码）
      在测试通过的前提下，优化实现的结构，让代码更优雅、可维护。

   然后重复这个循环：写下一个测试，再实现，再重构。

3. 保持代码易读、易修改的关键就是重构。

4. 需求的变化使重构变得必要

5. 设计模式为重构提供了目标

6. 重构前，先检查自己是否有一套可靠的测试集。这些测试必须有自我检验能力，否则就得耗费大把时间来回比对，这会降低开发速度。

7. 在做任何提炼前，我一般都会先移除局部变量。

8. 如果重构引入了性能损耗，先完成重构，再做性能优化。

9. 重构过程的精髓所在：小步修改。每一步都伴随着一次编译、测试以及向本地代码库的提交。
   特别是在事情变复杂时。

10. “计算逻辑的差异是由类型代码确定”最自然的解决办法：类型多态。

11. 更愿意有自测试的代码，但如果没有，自动化重构的工具包也很好。

12. 如果你对大多数程序进行分析，就会发现它把大半时间都耗费在一小半代码身上。

13. 除了用来记述将来的打算之外，注释还可以用来标记你并无十足把握的区域。
    你可以在注释里写下自己“为什么做某某事”。这些信息可以帮助将来的修改者，尤其是那些健忘的家伙。

14. 测试应该是一种风险驱动的行为，我测试的目标是希望找出现在或未来可能出现的 bug。
    所以我不会去测试那些仅仅读或写一个字段的访问函数，因为它们太简单了，不太可能出错。
    测试的重点应该是那些我最担心出错的部分，这样就能从测试工作中得到最大利益。

15. 当测试数量达到一定程度之后，继续增加测试带来的边际效用会递减；
    如果试图编写太多测试，你也可能因为工作量太大而气馁，最后什么都写不成。
    你应该把测试集中在可能出错的地方。