重构是在编写代码后在不更改代码的外部行为的前提下通过更改代码的内部结构来改进代码的过程。
一、何时需要重构
1、代码中存在重复的代码；
如果类中有重复的代码块，需将其提炼出一个新的独立方法，如果是不同类中具有相同的代码，将其提炼成一个新类。
2、过大的类和过长的方法；
过大的类往往是类抽象不合理的结果，类抽象不合理将降低代码的复用率。当看到一个过长的方法时，需要想办法将其划分为多个小方法。
方法中的代码行数越多，则方法越难理解。我们推荐每个方法中只包含 20-25 行代码。但有些人说 1-10 行更合理，这只是些个人喜好，没有硬性的规则。抽取方法是最常见的重构方式之一。如果你发现一个方法过长，或者已经需要一个注释来描述它的目的了，那么你就可以应用抽取方法了。人们总是会问一个方法到底多长合适，但其实长度并不是问题的根源。当你在处理复杂的方法时，跟踪所有局部变量是最复杂和消耗时间的，而通过抽取一个方法可以节省一些时间。可以使用 Visual Studio 来抽取方法，它会帮助你跟踪局部变量，并将其传递给新的方法或者接收方法的返回值。
3、牵一发而动全身的修改；
修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。
4、类之间需要过多的通讯；
A 类需要调用B 类的过多方法访问B 的内部数据，是不是这两个类根本就不应该分开。
5、过度耦合的信息链；
代码中常常会使用中间层来达到松耦合的目的，但过多的中间层，层层相连，是否需要考虑减少中间层。
6、功能相似的类或方法；
7、不完美的设计；
8、缺少必要的注释；
9、始终控制类的大小
超大的类在尝试做太多的事情，这违反了单一职责原则（SRP），也就是面向对象设计原则 SOLID 中的 S。
为什么一定要将两个职责分离到单独的类中呢？因为每一个职责都是变化的中心。在需求变更时，这个变更将会出现在负责该职责的类中。如果一个类承担了多个职责，就会有一个以上的原因导致其变化。如果一个类有多重职责，则说明这些职责已经耦合到了一起。并且某个职责的变化将有可能削弱或限制这个类满足其他职责的能力。这种耦合将会导致非常脆弱的设计，进而在职责发生变化时，设计可能被意想不到的破坏了。
下面两条可以归为重写范畴，代码规范问题。
10、避免过多的参数
通过声明一个类来代替多个参数。创建一个类，用于包含所有的参数。通常来讲，这是一个较好的设计，并且这个抽象非常的有价值。
11、避免复杂的表达式
复杂的表达式意味着其背后隐藏了一些涵义，我们可以通过使用属性来封装这些表达式，进而使代码更易读些。
if(product.Price>500 && !product.IsDeleted && !product.IsFeatured && product.IsExported) { // do something }
二、C# VS2010中的几点重构