对于重构一词，很多人对它还停留在模糊的概念上，摸不清重构是什么，于是害怕影响项目进度或质量就会让人“谈重构色变”。下面我们从重构中获得什么，重构会不会造成严重的影响，有没有什么原则等角度即探讨一下重构的本质。

1、重构的目的
“代码结构的流失有累积效应，当人们只为短期目的而修改代码时，他们经常没有完全理解架构的整体设计，于是代码逐渐失去了自己的结构，程序员越来越难通过阅读源码来理解原来的设计。”
重构这件事想解决的就是上述问题，把难懂的代码变得容易理解，使得后续开发的人（极有可能这个人是自己）很容易在原来的基础上修改，重构是纯粹从经济利益角度出发的，而不是一味追求整洁光亮的代码，不要掉入“整洁的代码”“良好的工程实践”之类道德理由的陷阱。选择重构的唯一理由就是能让我们更快，开发功能变快、修复 bug 变快、交接代码变快。

2、软件开发如同行军
我们用左腿右腿来描述软件开发。在软件开发时，添加新功能先迈出了左腿，但之后发现修改一部分设计会好添加很多，花上十分钟进行重构迈出右腿，再继续添加功能…如此往复，我们的左右腿迈开了，唰唰唰快速而稳健地向前走。
在这个过程中我们左腿要迈，右腿也要迈。当然，不是说只迈一条腿就走不动路，完全可以拖着走嘛，只是那样不够稳健，就像一个瘸了腿的人。

3、士兵不是体育运动员
重构是一种小步快跑的行为，是我们开发过程中持续的、不起眼但无比重要的迈步。
当然有时团队会专门花几个星期甚至几个月的时间进行重构，以弥补他们之前对重构的忽视。这种急行军的行为确实会发生，但不可能一直发生，大部分的重构应该是不起眼的、伴随开发同步去做。这些重构的工作往往是立竿见影，给几个变量重命名、调整函数的功能——这些看似微小的改变就能在开发前让我们看清之前的设计，改造之前的设计，更好地敲代码。

“如果不做前面的重构，我可能永远都看不见这些设计问题，因为我不够聪明，无法在脑海中推演所有这些变化。Ralph Johnson 说，这些初步的重构就像扫去窗上的尘埃，使我们得以看到窗外的风景。”

4、令行禁止
如果有一块丑陋的代码能被隐藏在一个完全不需要改造/接触的API之下，就继续容忍它的丑陋。记住我们的目的，为了经济利益，只有需要理解其工作原理时，对其重构才有价值。漂亮的代码也需要很多重构，有时过度的设计会干扰现在的功能，或者当时很漂亮的设计并不容易修改代码，这些漂亮的石头需要从道路上搬开。

5、你们的队伍有指导员么？
一份重构的代码要如何才能保证与原来的软件行为不偏离呢？答案是也需要被指导——被测试指导。
“自测试的代码不仅使重构成为可能，而且使添加新功能更加安全，因为我可以很快发现并干掉新近引入的 bug。”

最后，重构不是包治百病的灵丹，也绝对不是所谓的“银弹”。它更像是一把钳子，在搭建新管道时发现旧管道的问题就修修补补，把控住我们的代码。一艘船被造出来是因为开始的良好设计，在海上航行不沉是因为日常的保养。