扎心了！代码太乱，主动加班加点重构代码，结果却被扣绩效了

代码重构是个老生常谈的话题了，项目刚起步时，如果前期没有设计好，怎么个简单怎么来，随着业务模块不断地增加，情况可就没那么乐观了，要是这中间开发人员换了一批又一批，大家都在原先的基础上再添加自己的代码，那就更糟糕了。

 

原先一个很普通的需求，结果在经历过N次迭代后，渐渐形成一个庞大的功能，随着系统版本的不断迭代，维护起来的成本也随着越来越大，这样就形成了一种恶性循环。

 

 这种情况下，要是没有真正理解业务就轻易对其进行重构，因为重构后改出了问题，影响系统正常运行，可能得分分钟钟打包走人了，老板关心的重点可是公司业务是否盈利，而不是你编写的代码如何优雅，是否规范。

 

张工是一名程序员，入职到公司有两个多月了，最近刚接手了别人遗留下来的代码，发现有很多冗余代码，实在看不下去，特别是遇到需求变更需要对其做调整时，改动起来很费劲，于是主动加班对其进行代码重构，谁知程序上线后，被测试出两个bug，这个月的绩效恐怕又得被扣绩效了。

 

类似这样的经历或许你也有过：

• 工作几年后，再回头看看自己以前编写的代码，惊讶地发现，这么糟糕的代码，真的是我编写的吗？我居然能写出这样的代码？

• 糟糕了，这个业务点被我忽略了

• 重构时，发现那段代码没用地方调用，于是删掉了，结果出问题了，加上就好了

 

原来项目代码乱是乱了些，但并不影响正常业务运行，代码虽然冗余多，但起码系统稳定啊。

你这么一改，系统出问题了，这锅怕是得背定了。即使是重构后经过多次测试，也有可能隐藏其他问题。

 

别人遗留下来的代码有些乱，可能也是不得已而为之，我们也没有必要过于吐槽太多，即使是国内一线大厂，也并不是每个项目代码都很规范好维护，有些项目代码可能连基本文档都没有，更别谈代码规范了。

 

代码太乱，冗余太多，要不要对其重构？

 

毋庸置疑，代码冗余多，从维护成本上看，代码重构确实是一个很不错的解决方案，重构的成本比原基础维护的成本更小。但重构有风险，在对业务和现有框架没用真正理解透彻的情况下，重构就是给自己挖更深的坑。

 

对业务掌握得很透彻了，而有能力进行改造，这种情况可以考虑重构了。

 

从业务层面讲，把业务掌握透彻这点不用多层，从技术层上来说，在做代码重构前我们需要先理清这三点：

• 梳理原有源码逻辑关系

• 明确原有源码架构

• 构建新架构

 

现有代码冗余多，尤其是在多次迭代且多人经手的模块，模块之间过度耦合往往会导致牵一发而动全身，不容易确认控制影响范围，现有不易测试导致无法保证新代码的正确性，尤其是在测试用例不全的情况下。

 

只有充分知道改了这个模块，会不会对其他模块造成影响以及引出其他问题。只有在熟悉原先代码和业务的基础上，才能把重构风险降到最低。

 

关于重构，就好比情侣因为某个原因分手了，分手后双方各自都过得很好很，这时候就不要再去骚扰对方了，大家好聚好散，各自再进行重构。

 

刚接手别人遗留下来的代码，发现有很多冗余代码，改动起来很痛苦，要不要重构？不知对此你是怎么看待的，欢迎交流！

 

-END-

往期推荐

北京大妈嫌女孩让座慢，对其大骂：“臭外地的，到北京要饭来了”

腾讯副总裁痛批“部分低智低俗短视频长期影响用户心智”字节跳动副总裁回应

微信公众号：爱开发

 

 你若喜欢，别忘了点个【在看】