数字商贸网

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

2021-06-07 04:53:02

搜搜电影网 https://www.sosovcd.cc

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

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

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

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

  

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

  工作几年后,再回头看看自己以前编写的代码,惊讶地发现,这么糟糕的代码,真的是我编写的吗?我居然能写出这样的代码?糟糕了,这个业务点被我忽略了重构时,发现那段代码没用地方调用,于是删掉了,结果出问题了,加上就好了

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

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

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

  代码太乱,冗余太多,要不要对其重构?

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

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

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

  梳理原有源码逻辑关系明确原有源码架构构建新架构

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

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

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

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

上一篇:

下一篇:

Copyright© 2015-2020 数字商贸网版权所有