说道重构，不同的人有不同的看法。作为一个工作了四五年的码农，我也谈谈自己的看法。正好今天参加了关于代码整洁之道的培训，也印证的自己对于重构的一些想法。
在互联网高速发展的今天，重构和持续集成一样，成为了软件开发中不可或缺的一部分，伴随着软件的整个生命周期。但是重构和持续集成不一样，重构是程序员的一种自发行为，有时候很难得到boss们的理解和支持，特别是一些从没有写过代码的PM，可能觉得重构根本就是在浪费时间。因为重构很难去衡量和计算KPI。对于他们来说，好的程序员和坏的程序员没有本质的区别。加上整个大环境的因素，很难有程序员能安心去把重构进行到底。所以和BOSS们的沟通很重要，要让PM认识到重构的重要性和必要性。
既然重构这么重要，那什么是重构，为什么要重构和如何要重构呢？这些疑问会马上进入到你的大脑中。
什么是重构？这里引用Martin Fowler在重构这本书中的定义。重构是对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，使用一系列重构的方法，调整其结构，提高其可理解行，降低其修改成本。从这个定义来说，重构就是整理代码。从技术角度来说，重构就是利用一系列高效且受控的代码整理技术来修改代码，提高代码的可读性，稳定性，可扩展性和可维护性。重构的前后，不改变或者很少改变软件可观察行的外部外部行为。这里主要有两点，第一重构的方法，第二改变内在和不改变外在。
为什么要重构？从软件设计来说，在整个软件生命周期中，需求的变更是不可避免的一直会发生的。程序员在没有充分考虑整个软件设计的前提下，就去修改代码，程序会逐渐失去原有的设计结构，代码变得越来越难以阅读和维护。最典型的就是在一个function中没添加一个需求，就增加一堆if/else。等积累到一定程度，可能根本就没有人能读懂它，维护成本可想而知。从设计角度来看，架构设计是基于一些基础条件的，在运行过程中，承载的数量级的变化，这些基础条件很可能发生变化，当到达一个瓶颈的时候，软件系统很可能会发生各种各样的意外。重构就要求代码在这些基础条件发生时，能够有利于扩展和修改。这也从另外一个方面说明，架构师应该是参与代码的实现，从实现中去反馈设计的一些缺陷，减少风险。
那如何重构呢？重构是针对代码的行为，首先要找出哪些代码需要重构。好的代码不需要重构，只有坏的代码需要重构，所以我们要找出坏的代码。用Martin Fowler的话来说，就是坏的代码散发的坏的味道。我们通过一定规则来辨别坏的代码。 好的代码的好处可能各有不同，但是坏的代码的危害，大家却是有目共睹。比如，重复代码，由于各种各样的原因，copy无处不在，就连Microsoft也经常发生这样的事情(去google一下，就会发现很多这样的小故事)。还有救是函数体积过于庞大，一个function可能有几千行代码，根本就没法读，更何况维护和修改。更多的坏味道，可以去参考Martin Fowler的书“重构”，相信你会发现，我们每天都在犯的错误。
重构是一种程序员行为，是对自己工作负责的一种态度，所以，首先态度上要肯定重构，设别代码的坏味道，学习重构的技能，然后把这些养成习惯，融入到每天的coding中去。共勉之。