大约是工作三年后，职业倦怠毫无征兆的袭击了我，我莫名的感到：这一辈子就这样了，每天的工作就是写相同的代码，要命的是，自己在一个领域越精通，别人就越希望自己写同样的模块——再快一点。使我渡过这段时光的，是一些编程行业的老书，对于一个原本追求时髦技术的程序员来说，这样的反转令自己也很惊讶，其中就有这本《重构》，多年后，再次捧读，希望自己如《黑客帝国》里的neo，回到源码，去理解为何重构即不是传说中的银弹，却又如此重要。本篇为第一部分，先来说说看待重构的三心。
抛掉对重构的敬畏之心
1. 重构给出了具体的操作方法。
重构不是建立在空中的构建思想，而是从实践中归纳出来的操作手册。比如书中提到的要点之一：
事不过三，三要重构。
这条规则给出了重构时机的具体判断方法：一个值，一段代码，相同的功能，如果重复出现了 两次以上，就要提取为宏，变量，方法，或模块，以方便重用。这不是建议，从代码质量来说，这是要求，也是开发者从小工到专家的必由之路，事实上，除此之外，我不知道还有别的编写代码的方法。
2. 重构早已在开发者身边。
几乎所有开发工具（Eclipse、Xcode...）都内置重构工具，他们的使用与代码编辑器一样简单。
如果你是一名iOS开发者，请参阅Xcode8 五分钟重构起步
要对重构有耐心
由于重构不改变程序的外在表现，换而言之，即没有加入任何新功能，因此项目经理和老板不会主动要求开发者重构，甚至开发者提出时，会招来反对：这个项目还剩一个星期，还有N个需求未实现，现在你请求花费两天时间，什么都不做。开发者几乎都承担不了这样的压力，但是，比延误工期更严重的是，一个臃肿的，不易修改的项目，最终将面临添加需求困难，运行效率低下，以致达不到可用的性能，项目被砍掉，失败几乎不可避免。
那么作为开发者，应该怎么处理这个矛盾呢？一个可行的方法是，把重构当做开发的一部分，一边开发一边重构，先快速的堆叠代码，实现功能，然后在功能不变的基础上（写好单元测试），逐步重构。
对于吹嘘重构有戒心
不要对别人吹嘘重构
重构是一系列技法，就如一个优秀木匠不会吹嘘自己的刀法一样，他表现自己的，永远是作品，开发者的作品就是程序，可扩展，少改动，高效，稳健的程序，如果团队里有人说：我现在不重构就没法写代码。大概他就真的只是不会写代码而已。
本人面试过一些刚毕业的开发者，在最后的提问环节，他提出的问题是：你们用什么开发环境？接着他还进一步强调自己一定要使用**Source Insight
**（一种Windows平台流行的开发集成环境，基于代码语义管理代码），否则就无法写代码。当时我有点错愕，面对了解公司环境的宝贵机会，不问福利待遇，不问升职通道，却纠结一个开发工具。后来我发现，很多初学者（也包括我自己）对工具有种痴迷，这当然也不是坏事，但对自己用的开发工具夸夸其谈，只能说明开发者的眼界不够开阔，水平有局限。
当听到有人将重构奉为灵丹妙药，要格外小心，对此保持警惕。
有的技术领导人，动不动就说“下面我们进入重构阶段了”，仔细观察发现：每每他提出的时机，都是项目无法按时完成，某些功能实现不了时，公司领导还无法反驳，懂点技术的都明白重构的重要性。
那么，如何鉴别这种拿重构“忽悠”的行为呢？可以从以下几点：
- 检查要进入重构阶段的团队有没有写好对应的单元测试，这些测试是否自动测试。
- 是否为重构的项目新开版本管理库，如果是，那这不是重构，而是 重写。
- 最终确认最开始要求添加的需求是否被完成。
最后这点看起来有点二，但实际中常常发生，团队说，我开始重构啦，于是在大汗淋漓的两周后，团队只能保证“重构”后的项目勉强运行，项目进入了新阶段——bug修复，然后就再也没人提最初提出的新功能新需求了。
对于第一点，我们要理解重构的目标是
不改变代码外在行为的前提下，对代码进行修改，以改进程序的内部结构。
如何保证代码外在行为没有改变？就得靠单元测试了，这里将单元测试作为代码或重构的质量标准，谁也不想一个正在运行的程序，被修改后引入一堆Bug。
既然重构讲究的是小步修改，每次改完后都要通过单元测试，那么第二点也很好理解了，重建版本库则意味着大段地搬移代码，这个过程很难保证代码质量，得到的很可能是 未经验证 的代码。
既然重构是一种编程手法，那么实践中的重构是如何操作的？该如何避免重写而**优雅地重构呢？
下篇将通过一个具体的例子，体会重构的过程，请关注我的简书。
