重构-改善既有代码的设计：重构原则（二）

1.什么是重构

---

重构（Refactoring）：在不改变软件的功能和外部可见性的情况下，为了改善软件的结构，提高可读性、可扩展性和复用性性而对软件进行的改造，对代码内部的结构进行优化。

大型重构：

对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入bug的风险也会相对比较大。

小型重构：

对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名和注释、消除超大类或函数、提取重复代码等等。小型重构更多的是使用统一的编码规范。这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，引入bug的风险相对来说也会比较小。什么时候重构 新功能开发、修bug或者代码review中出现“代码坏味道”，我们就应该及时进行重构。持续在日常开发中进行小重构，能够降低重构和测试的成本。

2.为何重构

---

  1）改进软件设计（整理代码）

重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。

  2）提高代码质量和可读性，使软件系统更易理解和维护

 "任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员"。有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢？

软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。

对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！

  3）帮助尽早的发现错误（Defects）

孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。程序员经常对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的"感冒"。当你也发生这样的情形时，通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。

  4）提高编程速度

良好设计是维持软件开发速度的根本，重构可以帮助你更快的开发软件。因为它防止系统腐败变质。甚至还可以提高设计质量。当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。

    改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。

3.何时重构

---

    1）重构应该是随时随地进行。不应该为重构而重构。
    2）重构的原则：三次法则：第一次做某件事只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做 第三次 再做类似的事情，就应该重构了。
    3）添加功能：最常见的时机就是给软件添加新特性的时候，可以帮助我理解需要修改的代码。
    4）修复bug：当程序发生bug的时候，就是需要重构的信号，因为显然代码还不够清晰，没有清晰到让你能一眼看出BUG。
    5）复审代码，即Code Review时候
         

     重构可能会引入更多见阶层，重构往往需要把大型对象拆成多个小型对象。把大型函数拆成多个小型函数。间接层是把双刃剑：一是你需要管理多分内容。
    但间接层有以下作用：
    1）允许逻辑共享，小函数复用性高。
    2）分开解释意图和实现：可以选择类名和函数名解释实现意图的做法。
    3）隔离变化
    4）封装条件逻辑：对象有一种奇妙的机制：多态消息，可以灵活而清晰地表达条件逻辑。将条件逻辑转化为消息形式，往往能降低代码的重复。增加清晰度并提高弹性。

4.何时不该重构

---

    1）代码是在太混乱了，设计完全错误。
    2）如果项目已近最后期限，应该避免重构。 

    3）重构还不如重新编码。即重构的工作量显著的影响Estimate 

5.重构流程和原则

---

  流程：

   1）读懂代码（包括测试例子代码）

   2）进行重构

   3）运行所有的Unit Tests 

原则：

代码重构的过程中，需要遵循一些原则。这些原则确保了代码重构的方向性和有效性，使得重构后的代码更好地满足软件需求和实现目标。以下是几个常用的重构原则：

1.不改变程序行为：

在代码重构的过程中，必须确保重构后的代码与之前的代码具有相同的行为。否则，重构可能导致软件系统不稳定或出错。

2.小步重构：

代码重构需要分步进行，每次只进行小小的变更，以便避免对其他部分产生不必要的影响。

3.逐步演进：

代码重构应该是逐步进行的，每一步都是基于上一步的改进。这样可以确保代码的连贯性和稳定性。

4.保留代码的可读性：

代码重构后的代码应该更易于理解和维护。重构后代码中应该有明确的注释和命名，以提高代码的可读性。

6. 重构与设计

---

    1）很多人都把设计看作软件开发的关键换进。而把编程看作只是机械式的低级劳动。
    2）另外的观点就是：重构可以取代预先设计。你不必要做任何设计，只管按照最初的想法开始编码，让代码运作，然后再将它重构成型。

    实际上重构与设计是互补的,程序应该是先设计,而在开始编码后,设计上的不足可以用重构来弥补.设计应该是适度的设计,而不必过度的设计.如果能很容易的通过重构来适应需求的变化,那么就不必过度的设计,当需求改变时再重构代码 。

7.重构与性能

---

    三种快速编写软件的方法：

   1）时间预算法

        在设计时就对程序花费的时间进行预算,通常用于性能要求极高的实时系统.普通的企业应用程序一般对性能要求不高.只要不太慢就可以了 。

   2) 持续关注法

        要求程序员在任何时间都要设法保持系统的高性能.这个方法有个缺陷,就是大部分的程序90%的优化工作都是白费劲,这样会浪费大量的时间 。

   3) 良好的分解方式

       这个方式是在开发程序阶段不对性能投以任何关注,直到进入性能优化阶段,再分析程序中性能差的程序,然后对这些程序进分解,查出性能差的程序,进行优化。