关与代码重构那些事
source link: http://www.zhyea.com/2019/04/02/think-of-project-reconfigure.html?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
首先抛出观点：重构既有代码并不是一件讨好的事情，甚至是一件无功有过的事。
说个我朋友的事（我的一个朋友系列）。这个人颇有些强迫症。他在入职某家公司一段时间后，实在受不了负责模块那些祖传代码的组织方式，就用工作之余的的时间彻底重构了部分内容。也算幸运，他的重构工作没有影响生产业务。在年底进行绩效评估的时候，他将代码重构作为绩效的一部分汇报，却没有得到领导的认可。为什么呢？因为即使没有重构，以前的代码也能满足业务需求，而且重构后的代码并没有性能上的显著提升，他的工作被视为是可有可无的。
对于朋友的做法，我现在说不上不认可；对于当时他的领导的做法，我也能够理解。如果对代码进行重构的肇始是缘于洁癖或强迫症，那么最好三思三思三思而后行，至少也不要一开始就全面重构。因为既有的祖传代码虽然可能比较糟糕，但还是经过了生产业务的考验的。而修改后的代码必须得经过充分的测试才能投入生产。而这种测试我不认为是开发一个人进行自测就能充分覆盖完全的，项目组需要为这些改动多投入一些成本。
但是重构就是完全不能进行了么？我也没这么说。我只是强调了要优先保证生产环境的稳定性，并且需要顾及到团队投入的成本。重构还是要做的，但是要掌握好契机。
比如有新需求来的时候，如果继续用过往的代码适配新的业务逻辑会消耗太多的时间。这些时间甚至超过了重构的时间。那么此时优先选择重构。
再比如发现引入新的技术方案可以显著提升当前系统的性能，改善系统的短板。那么经过团队讨论后，可以在引入新方案的时候顺手实现代码的重构。
充分利用这些机会，就可以在不会过多占用团队资源的前提下，重构既有代码。
如果没有理想的机会的时候也可以小范围的进行调整，或者拉一个新的分支在不影响生产系统的前提下实现对既有代码的改造。这样在真正需要大面积改造的时候也就有了足够的基础。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK