关于代码重构那些事

首先抛出观点：重构既有代码并不是一件讨好的事情，甚至是一件无功有过的事。

说个我朋友的事（我的一个朋友系列）。这个人颇有些强迫症。他在入职某家公司一段时间后，实在受不了负责模块那些祖传代码的组织方式，就用工作之余的的时间彻底重构了部分内容。也算幸运，他的重构工作没有影响生产业务。在年底进行绩效评估的时候，他将代码重构作为绩效的一部分汇报，却没有得到领导的认可。为什么呢？因为即使没有重构，以前的代码也能满足业务需求，而且重构后的代码并没有性能上的显著提升，他的工作被视为是可有可无的。

对于朋友的做法，我现在说不上不认可；对于当时他的领导的做法，我也能够理解。如果对代码进行重构的肇始是缘于洁癖或强迫症，那么最好三思三思三思而后行，至少也不要一开始就全面重构。因为既有的祖传代码虽然可能比较糟糕，但还是经过了生产业务的考验的。而修改后的代码必须得经过充分的测试才能投入生产。而这种测试我不认为是开发一个人进行自测就能充分覆盖完全的，项目组需要为这些改动多投入一些成本。

但是重构就是完全不能进行了么？我也没这么说。我只是强调了要优先保证生产环境的稳定性，并且需要顾及到团队投入的成本。重构还是要做的，但是要掌握好契机。

比如有新需求来的时候，如果继续用过往的代码适配新的业务逻辑会消耗太多的时间。这些时间甚至超过了重构的时间。那么此时优先选择重构。

再比如发现引入新的技术方案可以显著提升当前系统的性能，改善系统的短板。那么经过团队讨论后，可以在引入新方案的时候顺手实现代码的重构。

充分利用这些机会，就可以在不会过多占用团队资源的前提下，重构既有代码。