重构概述

 你会提出的问题

• What is Refactoring
• Why Refactoring
• When Refactoring
• Who should do Refactoring
• Where should be suitable for Refactoring
• How to apply Refacotring

 

 

 

What is Refactoring

 

u   重构是对软件内部结构的一种调整，目的是在不改变外部行为的前提下，提高可理解性,降低修改成本。

u   重构是严谨、有序地对完成的代码进行整理从而减少出错的一种方法。

 

Two Hats

利用重构技术开发软件时会把时间分配给两种行为:[重 构]与[添加新功能]

u      添加新功能时，不应该修改既有代码，只管添加         

       新功能。 

u      重构时你就不能再添加功能，只管改进程序结构。

u      两顶“帽子”可交替进行，一会重构，一会添加 

       新功能。

 

Why Refactoring

u   改进程序设计

       程序员为了快速完成任务，在没有完全理解整体  架构之前就修改代码，导致程序逐渐失去自己的结构。

重构则帮助重新组织代码，重新清晰的体现程序结构和进一步改进设计。

u      提高程序可读性

      容易理解的代码很容易维护和增加新功能。代码首先是写给人看的，然后才是计算机看的。

u   助你找到程序错误

       重构是一个Code Review 和反馈的过程。在另 一个时段重新审视代码，会容易发现问题和加深对代码的理解。

u      助你提高编程速度

      设计和代码的改进都可以提高开发效率，好的设计和代码都提高开发效率的根本。

u      提高设计和编码水平

     对代码的重构，是快速提高设计和编码水平的方法。

When Refactoring

u   增加新功能时一并重构

        增加功能前需要理解修改的代码，如果发现代码不易理解且无法轻松增加功能，此时就需要对代码进行重构。

u       修补错误时一并重构

        通过重构改善代码结构，能够帮助你找出BUG原因。

u       Review代码时一并重构

       有经验的开发人员Review代码时能够提出一些代码重构的建议。

 

When I should notRefactoring

u   代码实在太混乱，重构还不如重写

u      项目即将结束时避免重构

       此时已经没有时间进行重构了，应该在早些时候进行重构。如果程序有必要重构，说明该项目已经欠下“债务”，需要项目完成后进行偿还。

 

 

Who should doRefactoring

 

Where should besuitable for Refactoring

 

How to applyRefacotring

(The way we do Refactoring)

Implementation：

1.      DuplicatedCode

2.      Longmethod

3.      LargeClass

4.      Longparameter list

5.      DivergentChange

6.      ShotgunSurgery

7.      FeatureEnvy

8.      DataClumps

9.     PrimitiveObsession

10.  SwitchStatements

11.  ParallelInheritance Hierarchies

12.  LazyClass

13.  SpeculativeGenerality

14.  TemporaryField

15.  MessageChains

16.  MiddleMan

17.  InappropriateIntimacy

18.  AlternativeClasses with Different Interfaces

19.  IncompleteLibrary Class

20.  DataClass

21.  RefusedBequest

22.  Comments

 

Function optimization：

1. Extract Method
2. Inline Method
3. Inline Temp
4. Replace Temp with Query
5. Introduce Explaining Variable
6. Split Temporary Variable
7. Remove Assignments to Parameters
8. Replace Method with Method Object
9. Substitute Algorithm

 

代码坏味道

 

1. 重复的代码 (Duplicated Code) ☆☆☆☆☆

         重复代码是最常见的异味，往往是由于Copy &Paste 造成的。

      重构方法:

u   重复代码在同一个类中的不同方法中，则直接提炼为一个方法

u   如果重复代码在两个互为兄弟的子类中，则将重复的代码提到父类中

u   如果代码类似，则将相同部分构成单独函数，或者用 Template Method 设计模式

u   重复代码出现在不相干的类中，则将代码提炼成函数或者放在独立的类中

2. 过长的函数(Long Method) ☆☆☆☆☆

         是面向结构程序开发带来的 “后遗症”，过长的函数降低可读性。

      重构方法:

u   将独立的功能提炼成新函数

       3.   过大类(LargeClass) ☆☆☆☆

           过大的类使得责任不清晰。

       重构方法

u   将过大类的功能拆分成多个功能单一的小类          

 

 

 

 

        4. 过长的参数列(Long Parameter List) ☆☆☆☆

         过长的参数列难以理解，而且容易传错参数。

      重构方法:

u   将参数列表用参数对象替换

 

       5. 发散式变化(Divergent Change) ☆☆☆

         一个类由于不同的原因而被修改。

      重构方法:

u   将类拆分成多个，每个类只因为一种变化而修改

 

 

         6. 霰弹式修改(Shotgun Surgery) ☆☆☆☆

         与发散式变化相反，遇到变化时需要修改许多不同的类。

      重构方法:

u   将类似的功能放到一个类中

 

 

 

 

 

7.  依恋情结(Feature Envy) ☆☆☆

         函数对某个类的兴趣高过对自己所处的类，通常是为了取其他类中的数据。

      重构方法:

u   将函数部分功能移到它感兴趣的类中

8.   数据泥团(Data Clumps) ☆☆☆

          在多个地方看到相同的数据项。例如：

      多个类中相同的变量，多个函数中相同的参数列表，并且这些数据总是一起出现。

      重构方法:

u   将这些数据项放到独立的类中

9.   分支语句(Swtich Statements) ☆☆☆☆

         大量的分支、条件语句导致过长的函数，并且可读性差。

      重构方法:

u   应将它变成子类或者使用State和 Strategy模式

 

 

 

10.   过度耦合的消息链(Message Chains) ☆☆☆

        一个对象请求另一个对象，后者又请求另外的对象，然后继续。。。。，形成耦合的消息链。

      重构方法：

u   公布委托对象供调用

11.  过多的注释(Comments) ☆☆

         代码有着长长的注释，但注释之所以多是因为代码很糟糕。

      重构方法：

u   先重构代码，再写上必要的注释

12.   夸夸其谈未来性(Speculative Generality)☆☆☆

        现在用不到，觉得未来可以用到的代码，要警惕。

      重构方法：

u   将用不上的代码去掉

13.    纯粹的数据类(Data Class) ☆☆☆

         将数据类中数据以Public方式公布，没对数据访问进行保护。

      重构方法：

u   将数据封装起来，提供Get/Set方法

 

以上是代码开发和程序维护过程中经常遇到的问题，并不是坏味道的全部。在开发中应避免出现坏味道。

 

重构名录实例

 

1、提炼函数 （Extract Methods）

将代码段放入函数中，让函数名称解释该函数的用途

2、将函数内联化(Inline Method)

如果函数的逻辑太简单，则把其移到调用它的代码中，取消这个函数

 

3、将临时变量内联化（InlineTemp ）

变量被一个简单的表达式赋值一次，则将变量替换成那个表达式

 

 

4、以查询取代临时变量（ReplaceTemp with Query ）

临时变量保存表达式的结果，将这个表达式提炼到独立的函数中。

 

 

 

5、引入解释性变量（Introduce Explaining Variable ）

将复杂表达式结果放入临时变量，用变量名来解释表达式用途

 

 

6、剖解临时变量（Split TemporaryVariable ）

一个临时变量多次被赋值（不在循环中），应该针对每次赋值，创造独立的临时变量。

 

7、以卫语句取代嵌套条件语句

     （Replace Nested Conditionalwith Guard Clauses）

函数中条件语句使人难以看清正常的执行路径，用卫语句替换嵌套条件

 

 

8、分解条件表达式（Decompose Conditional ）

从复杂的条件语句分支中分别提炼出独立函数

 

 

 

引用译者的一段话作为结束：

 ‘重构已经变成了我的另外一种生活方式，变成了我每天的面包与黄油，变成了我们整个团队的空气与水，以至于无须到书中寻找任何神谕。’

 

 

References:

 

 

http://refactoringmanifesto.org/

1. Make your products live longer! Refactoring means taking the opportunity to keep your product alive. Don't ditch it, stitch it! Don't end it, mend it! Refactoring is not a needless cost. It is anti-needless complexity that prevents change.
2. Design should be simple so that it is easy to refactor. Product designers: Make your products easy to change. Write clean, understandable code. Consumers: Buy products that are continuously refactored, or else find out why the developers didn't do that. Be critical and inquisitive.
3. Refactoring is not rewriting. Rewriting is throwing away the broken bit. This is NOT the kind of refactoring that we're talking about.
4. What doesn't kill it makes it stronger. Every time we refactor code, we add to its potential, its history, its soul and its inherent beauty.
5. Refactoring is a creative challenge. Refactoring is good for the imagination. Using new techniques, tools and materials ushers in possibility rather than dead ends.
6. Refactoring survives fashion. Refactoring is not about styling or trends. There are no due-dates on continuously refactored code.
7. To refactor is to discover. As you refactor objects, you'll learn amazing things about how they actually work. Or don't work.
8. Refactor – even in bad times! If you think this manifesto is not relevant during recession, forget it. This isn't about effort, it's about mentality.
9. Refactoring is about independence. Don't be a slave to legacy code – be its master. If it's broken, refactor it and make it better. And if you're a master, empower others.
10. You can refactor anything, even total crap. But we'd recommend avoiding total crap. Refactoring stops code from becoming crap.