重构原则（一）

知识点的梳理：

• 重构（名词定义）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本；
• 重构（动词定义）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构；
  • 在添加新功能时，不应修改现有代码，只管添加新功能；在重构时，不能添加新功能，只管改进程序结构；

    

• 何时重构？
  • 三次法则：第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，就应该重构；
    • 事不过三，三则重构；
  • 添加新功能时重构；
    • 此时重构的直接原因往往是为了帮助我们理解需要修改的代码；
    • 在前进过程中，把代码结构理清，可以从中理解更多的东西；
  • 修补错误时重构；
    • 当程序发生错误的时候，就是需要重构的信号，因为显然代码还不够清晰，没有清晰到让你能一眼看出BUG；
  • 复审代码时重构；
  • 什么代码需要重构？
    • 难以阅读的程序，难以修改；
    • 逻辑重复的程序，难以修改；
    • 添加新行为时需要修改已有代码的程序，难以修改；
    • 带复杂条件逻辑的程序，难以修改；
  • 因此，我们希望程序：
    • 容易阅读；
    • 所有逻辑都只在唯一地点指定；
    • 新的改动不会危及现有行为；
    • 尽可能简单表达条件逻辑；
• 何时不该重构
  • 代码太混乱，重构它不如重新写一个。
  • 项目已到最后期限；
• 重构要点
  • 如果发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性；
  • 重构前，先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验能力；
  • 重构技术就是以微小的步伐修改程序。如果犯了错误，可以很容易的发现它；
  • 不要多早发布接口。请修改你的代码所有权政策，使重构更顺畅；
  • 当你感觉需要撰写注释时，请先尝试臭狗狗，试着让所有注释都变得多余；
  • 确保所有测试都完全自动化，让它们检查自己的测试结果；
  • 一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需要的时间；
  • 频繁地运行测试。每次编译请把测试也考虑进去---每天至少执行每个测试一次；
  • 每当你收到bug报告，请先写一个单元测试来暴露这个bug；
  • 考虑可能出错的边界条件，把测试火力集中中在那儿；
  • 当事情被大家认为应该会出错时，别忘了检查是否抛出了预期的异常；
  • 不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug;