标签：
说到重构，估计所有程序员都能想到出自Martin Fowler的《重构》一书。这本书究竟到了什么样的高度呢？有人这样说：
如果说《设计模式》是程序设计层次的圣经，《面向模式的软件架构》是架构设计层次的圣经的话，《重构》则当之无愧地可以称为企业级应用的圣经。
作为《优雅内涵》栏目第一个系列的《消灭坏味道》，会秉承大师的意志，教会大家：
当然在优雅程序员这里，不需要看英文，也不需要看不那么本土化的代码。
在开始消灭一个个坏味道之前，我们先来看看Martin Fowler大师是如何看待重构的：
我并不想说重构能够解决软件中所有的问题，它不是“银弹”。然而重构是非常有价值的工具，它是你可以用来很好地控制代码的“银钳子”。重构能够，也应该，被用来完成软件上的诸多目标。
重构能改善软件设计
不重构，程序的设计将随着时间腐坏。如果碰到临时需求跟设计有冲突，或者对设计没有整体的理解，这时改代码很难保证程序的设计不被破坏。随着“破坏”的积累，不管谁都很难再从代码中看出设计。重构更像是在整理代码，它可以移除没待对地方的代码。程序设计的“破坏”有加速累计的效应。越难看到代码里的设计，越难保持，然后腐坏的就越快。日常的重构能保持代码的设计。
设计差的代码完成相同的功能需要更多代码，通常是因为有大量的重复，因此改善代码设计的一个重要方面就是消除代码重复。减少重复代码并不会让系统跑的更快，但是却会给将来修改代码带来很大的不同。代码重复越多，就越难保证正确修改，因为有更多代码需要阅读和理解。你改了这个地方后，系统并没有按照你认为的方式工作，因为你没有修改另外一个稍有差异但完成相同功能的地方。通过消除重复，你的代码针对每件事情，只说一遍，并且是唯一的一遍，这是好设计的基本要素。
重构使软件更易理解
编程是和计算机对话的一种方式。你写代码告诉电脑做什么，它严格执行后给予反馈。很容易的，你把“想要什么”和“告诉电脑怎么做”扯到了一起。你写的代码全是在说怎么做。但是你的代码还有另外一个用户，你的同事会在几个月后为了完成某项功能而尝试修改你的代码。我们很容易忘记这个“额外”的用户，然而这个用户才是最重要的。有谁会关心电脑是否会多花点时间做编译？重要的是你的同事可能要花一周才能看懂你的代码，然后做个小修改。如果你的代码容易看懂，他也许一个小时就可以搞定。
问题就是当你正在努力让程序工作的时候，根本就没有想到你的同事。当你的程序能工作的时候，花点时间重构可以让你的代码更有结构，更能表达出它的意图。你的代码应该总是在说你想要什么。也不是我无私，这个“同事”通常就是我自己。
我通过重构来理解不熟悉的代码。当我看到不熟悉的代码时，我必须试着理解它做了什么。通过重构，我并不只是停留在用脑子记，而是实际地把代码修改成我理解的样子，然后通过重跑程序（测试）来验证我的理解是否正确。一开始的时候，我只能修改其中一些小的细节，当代码修改的越来越清晰的时候，我发现能看到之前看不到的设计。如果没有重构过这些代码，可能永远也无法理解到这些，我还没有厉害到可以把这一切都虚拟到脑子里。当学习代码的时候，重构可以逐步让我理解高层的设计。
重构有助于找到Bug
帮助理解代码也会帮我找到Bug。我承认我并不善于找Bug，有些人能够仅仅通过读一大段代码就找出其中的Bug，我却不能。然而重构代码时，我会深入地理解代码做了些什么，然后我带着这些理解再去看新代码时，有些Bug就不可避免的自然出现了。这让我想起了Kent Back经常说的一句话“我并不是伟大的程序员，我只是有伟大习惯的好程序员。”重构让我能高效地编写高质量的代码。
重构有助于提高编程速度
从前面的观点可以看出：重构能帮助你提高编程速度。
听起来有点不可思议。当我讨论重构时，人们容易理解它能改进代码质量。改进设计，可读性，减少Bug，所有这些都是改进代码质量。难道这些没有降低了开发速度吗？
我非常肯定好的代码设计是软件快速开发的基石。实际上，之所以要好的设计，就是为了快速开发。没有好的设计，你只是快一时，不久后就会慢下来。你花费时间在找Bug，修复Bug，而不是实现新需求。当系统里面有重复代码时，你要花更长的时间理解，花更长的时间修改代码。当补丁上打补丁时，再加新需求会需要更长的时间，更多的代码。
好的设计是软件快速开发的必要条件，重构能够帮你快速开发软件，因为它不仅能防止设计腐坏，还能改善设计。
标签：
原文地址：http://www.cnblogs.com/yoyaprogrammer/p/refactor.html
