代码重构在软件开发过程中，是一项重要非紧急的工作。但大多数情况下，人们都会因为其非紧急，而忽略其重要性。等到代码重构演变成重要且紧急的工作时，一般就只有放弃了，因为由于长期的技术欠债，此时代码已经变得无法扩展，成为一堆僵死的代码。

代码重构的重要性

代码重构是为了使代码具有很好的可读性、可维护性、可扩展性、可重用性。

为什么要进行代码重构？

代码在演化过程中，会由于各种不同的原因，不断产生bad smell。如果不及时清理，bad smell会不断积累，代码逐渐腐化，最终导致代码不可用。

代码腐化产生的可能原因

1. 为了赶进度，开发人员牺牲了质量。
2. 业务分析不透彻、技术设计不深入。
3. 开发人员经验和意识欠缺。
4. 对设计方案的评审和代码走查重视不够，或者根本就没有这个环节。
5. 没有专人从业务、技术、人员等各方面拉通全盘考虑。
6. 前期无法预测后面所有的变化。
7. 技术团队对使用的相关技术掌握得不够，无法最优化地使用。
8. 由于软件开发本身的客观规律，代码腐化本身就不可避免。

何时进行重构?

开发人员应该具有随时重构的意识，只要发现bad smell，就应该尝试重构。如果因为有其它原因，暂时无法重构的，我的建议是不超过两个月进行一次系统的重构。

重构涉及的相关人员

开发人员

开发人员是重构的具体执行者，需要具备很高的素质，才能做好重构工作。个人认为，比较重要的素质包括以下几方面：

1.技能

包括技术敏感度、重构的套路方法、系统思考的能力等。

2.责任心

要有很好的质量意识，随时保持对代码出现bad smell的警惕。

3.稳定的情绪

这应该是属于管理层面的问题。如果开发人员的情绪出现的波动，就不会就主动将工作做得更好。

测试人员

测试人员要与开发人员配合，通过各种测试手段和测试用例，降低或避免因重构而引入新的bug。

需求分析人员

需求分析人员除了理清基本的业务逻辑之外，还要能够将各业务进行拆分，理清业务的本质和各业务之间的相互关系。
当有新的需求引入，而导致之前的业务关系有变化时，尤其要重视。此时需求分析人员要与设计、开发、测试人员共同讨论，理清可能会对之前的代码产生哪些冲击，可能会带来哪方面的问题。

系统设计人员

系统设计人员要有非常强的系统思维，同时对业务和技术都能够掌控，这样才能将各功能划分的更清晰、更合理。

上级主管

上级主管不会直接参与重构，但如果上级主管不能够理解重构的重要性，则重构的工作开展到什么程度，完全由开发人员自己的经验、责任心来决定。
虽然重构是非常重要的，但由于重构的效果是偏隐性和长期的，如果重构工作得不到上级主管的认同，则开发人员的重构积极性会被严重挫伤。
等到代码不断腐化以至僵死，开发人员可能就会选择拍屁股走人，这时上级主管也会受到伤害。

为什么重构总是知易行难

这是我个人的感受，不代表所有情况。就我个人的经验，有以下原因：

1.人的惰性

虽然很多时候，开发人员都已经知道了该怎么重构，才能让代码具有更好的扩展性和重用性，但不重构而直接拷贝之前的代码再作简单的修改这样更省事。

2.能力的限制

重构这个概念大家都知道，但真正要能够及时识别出代码中的重构点，并采用最优的方法进行重构，则对能力的要求非常高。不同水平的人，体现在重构上的差别非常大。
这种能力的提升，主要是需要开发人员对自己的代码质量有很高的要求，并不断修炼。

3.没有合适的主导人员

合适的主导人员，在技术上要能够识别出重构点和重构时机，并能自己或者指导开发人员进行有效的重构。在沟通协调上，要能够争取到上级主管的支持和其它业务部门的谅解。

4.缺乏制度的保证

如果能够在制度上，将重构工作常态化，并配以合理的考核机制和主导人员，则我们开发出的软件产品将具有更高的质量、更长的生命周期、带来更大的价值。