重构

软件重构是指在不改变软件的功能和外部可见性的情况下，为了改善软件的结构，提高清晰性、可扩展性和可重用性而对软件进行的改造。简而言之，重构就是改进已经写好的软件的设计。

软件重构需要借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。在极端编程的方法学中，重构需要单元测试来支持。

 

---

什么是Refactoring?

1.Refactoring是对已经完成的代码进行改进的过程。在不对代码的外部行为进行改动的情况下，对代码内部的结构进行优化。

2.Refactoring是严谨地对完成的代码进行清理的从而减少出错的一种方法。

3.Refactoring的实质是对完成代码的设计进行改进。

4.Refactoring是XP项目中每天的例行练习。

5.Refactoring必须和Test-Driven Design and Development 伴随进行。

 

为什么要Refactoring?

1.　改进软件的设计。

程序员对代码所做的为了满足短期利益代码改动，或再没有完全清楚增个架构下的改动，都很容易是代码失去它的清晰结构，偏离需求或设计。而这些改动的积累很容易使代码偏离它原先设计的初衷而变得不可立即和无法维护。 Refactoring则帮助重新组织代码，重新清晰的体现结构和进一步改进设计。

2.　提高代码质量，可维护性。

容易理解的代码可以很容易的维护和做进一步的开发。即使对写这些代码的程序员本身，容易理解代码也可以帮助容易地做修改。

程序代码也是文档。而代码首先是写给人看的，让后才是给计算机看的。

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

Refactoring是一个code review和反馈的过程。在另一个时段重新审视自己或别人代码，可以更容易的发现问题和加深对代码的理解。 Refactoring是一个良好的软件开发习惯。

４. Refactoring可以提高提高开发速度

Refactoring对设计和代码的改进，都可以有效的提高开发速度。好的设计和代码质量实体提高开发速度的关键。在一个有缺陷的设计和混乱代码基础上的开发，即使表面上进度较快，但本质是试延后对设计缺陷的发现和对错误的修改，也就是延后了开发风险，最终要在开发的后期付出更多的时间和代价。

 

 

什么时候适合做Refactoring?

1.在开始增加一个新的功能之前

为了增加一个新的功能，程序员需要首先读懂现有的代码。

2.在修复一个错误的时候

为了修复一个Bug,程序员需要读懂现有的代码。

3.在做Code Review的时候

 

 

什么时候不适合做Refactoring?

1.代码太混乱，设计完全错误

与其Refactor，不如重新开始。

2.明天是DeadLine

永远不要做Last-Minute-Change。推迟Refactoring，但不可以忽略，即使进入Production的代码都正确的运行。

3.Refactoring的工作量显著的影响Estimate

一个Task的estimate是３天，如果为了Refactoring，需要更多的时间（ ２天或更多）。推迟Refactoring,同步可以忽略。可以把这个Refactoring作为一个新的Task，或者安排在Refactoring的Iteration中完成。

 

Refactoring的流程

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

2.Refactoring

3.运行所有的Unit Tests

本文转自passover 51CTO博客，原文链接：http://blog.51cto.com/passover/425916，如需转载请自行联系原作者