他们总在说重构，不过是重写

　　大约是工作三年后，职业倦怠毫无征兆的袭击了我，我莫名的感到：这一辈子就这样了，每天的工作就是写相同的代码，要命的是，自己在一个领域越精通，别人就越希望自己写同样的模块——再快一点。使我渡过这段时光的，是一些编程行业的老书，对于一个原本追求时髦技术的程序员来说，这样的反转令自己也很惊讶，其中就有这本《重构》，多年后，再次捧读，希望自己如《黑客帝国》里的neo，回到源码，去理解为何重构即不是传说中的银弹，却又如此重要。本篇为第一部分，先来说说看待重构的三心。

　　回到源码

　　抛掉对重构的敬畏之心

　　1. 重构给出了具体的操作方法。

　　重构不是建立在空中的构建思想，而是从实践中归纳出来的操作手册。比如书中提到的要点之一：

　　事不过三，三要重构。

　　这条规则给出了重构时机的具体判断方法：一个值，一段代码，相同的功能，如果重复出现了 两次以上，就要提取为宏，变量，方法，或模块，以方便重用。这不是建议，从代码质量来说，这是要求，也是开发者从小工到专家的必由之路，事实上，除此之外，我不知道还有别的编写代码的方法。

　　2. 重构早已在开发者身边。

　　几乎所有开发工具(Eclipse、Xcode...)都内置重构工具，他们的使用与代码编辑器一样简单。

　　如果你是一名iOS开发者，请参阅Xcode8 五分钟重构起步

　　要对重构有耐心

　　由于重构不改变程序的外在表现，换而言之，即没有加入任何新功能，因此项目经理和老板不会主动要求开发者重构，甚至开发者提出时，会招来反对：这个项目还剩一个星期，还有N个需求未实现，现在你请求花费两天时间，什么都不做。开发者几乎都承担不了这样的压力，但是，比延误工期更严重的是，一个臃肿的，不易修改的项目，最终将面临添加需求困难，运行效率低下，以致达不到可用的性能，项目被砍掉，失败几乎不可避免。

　　那么作为开发者，应该怎么处理这个矛盾呢?一个可行的方法是，把重构当做开发的一部分，一边开发一边重构，先快速的堆叠代码，实现功能，然后在功能不变的基础上(写好单元测试)，逐步重构。

　　庖丁解牛

　　对于吹嘘重构有戒心

　　不要对别人吹嘘重构

　　重构是一系列技法，就如一个优秀木匠不会吹嘘自己的刀法一样，他表现自己的，永远是作品，开发者的作品就是程序，可扩展，少改动，高效，稳健的程序，如果团队里有人说：我现在不重构就没法写代码。大概他就真的只是不会写代码而已。

　　本人面试过一些刚毕业的开发者，在最后的提问环节，他提出的问题是：你们用什么开发环境?接着他还进一步强调自己一定要使用Source Insight (一种Windows平台流行的开发集成环境，基于代码语义管理代码)，否则就无法写代码。当时我有点错愕，面对了解公司环境的宝贵机会，不问福利待遇，不问升职通道，却纠结一个开发工具。后来我发现，很多初学者(也包括我自己)对工具有种痴迷，这当然也不是坏事，但对自己用的开发工具夸夸其谈，只能说明开发者的眼界不够开阔，水平有局限。

　　木匠不会夸自己锤子好使

　　当听到有人将重构奉为灵丹妙药，要格外小心，对此保持警惕。

　　有的技术领导人，动不动就说“下面我们进入重构阶段了”，仔细观察发现：每每他提出的时机，都是项目无法按时完成，某些功能实现不了时，公司领导还无法反驳，懂点技术的都明白重构的重要性。

　　忽悠

　　那么，如何鉴别这种拿重构“忽悠”的行为呢?可以从以下几点：

原文转自：http://www.jianshu.com/p/bce0fe294655