记一次完整的系统业务代码重构——why

Posted 2020-11-27 sjlian

　　　　　　 记一次完整的系统业务代码重构(1)——why

0.为什么烂

　　优秀的代码优秀的出奇一致，烂代码却烂的千奇百怪。至于原因嘛，无非如下几种：

　　1.迭代和变更需求快，比翻书变脸还快，而且没有统一规划和为未来预留考虑。

　　2.公司人员流动快，代码换了一届又一届的主人，七朝元老都没站出来，三朝元老的代码都弱爆了。

　　3.神坑的技术人员，零注释、迷魂阵、障眼法没有最晕的代码只有更晕的代码。

　　

1.烂在何处

　　让所有的开发人员吐槽自己维护的代码烂在何处，估计说个3天3夜都说不完。这里总结下自身项目的缺点。由于项目内容涉及到一些商业机密问题，这里采取通俗简述的方式。

　　1.深度耦合，调用关系混乱，各自既维护自己模块同时也维护其他模块。

　　2.晦涩难懂，嵌套10+层，方法1k+行，0注释。

　　3.不懂优化，只为实现功能，慢到无法接受也无所谓。

　　4.隐藏地雷，平时没问题高并发场景下问题层出不穷，偶尔闹鬼一样的事故。

 

2.某程序员的经历

　　面向对象的java愣是被生生用成了面向过程，所有的设计模式统统抛在一边，要造车是吗？还，那我先切钢板、拧螺丝钉，历经千辛万苦终于造好了车。没见识过1个接口有5千行代码，和数据库交互2000次都不好意思说我的代码耦合度高。

　　突然说这个车不好看，改改样式；发动机不给力，换换吧。查询操作我忍忍也就算了，1个普通的修改操作，还需要在自己的方法中去维护另外的5个模块，想想都够了。

　　什么不是5个模块是6个，哦，又加了一个模块啊，那我改改，啊？什么时候加的，改的晚了，已经跑了一部分数据了，脏数据啊！没办法了，兼容吧。咋兼容呢，已经很复杂了，算了不管了，写一块吧if、else嵌套几次就ok了，我好聪明，这都能搞得定，大功告成。

　　什么，刚才移动端说你的接口有问题，啥问题？哦安卓需要这个字段、ios需要那个字段，好好好，别急，都返回给你们。第一步找到接口，然后加字段，查询，赋值给字段，搞定，皆大欢喜。

　　过了几天，改需求说某个字段不用了，然后又需要某个字段。改自动好说，说改咱就改啊，加入查询，查询再返回给前端，删除字段a这个我看看，好多地方调用这个方法啊，万一别的地方用呢，算了，反正不影响，留着吧，万一删错了还得背责任。就这样无效和无用的代码越积累越多，但是也完全不知道用不用。

　　听说又要改动某块逻辑了，哦哦，虽然生气，但是还得改啊。这次一定要小心，不能改漏地方了，所有调用这个的地方我都挨个核对去改，嗯嗯，就这样。加班加点无数次，终于一个不漏的改完了，看着北京凌晨三四点的风景心情别提有多舒畅了。也许这个时候你永远不知道，你改的代码中一半以上都是被上面类似的操作废弃但没有删除的，还是期望你不知道吧，免得伤肝火，还是好好睡觉吧。

　　开会加功能改需求，一个周期过完又来了一个周期，周而复始，虽然加班是常态，火冒三丈是常态，被烂代码坑的分分钟想摔电脑走人是常态，但是想想房贷车贷老婆孩子还是该debug还得debug，然后弱弱的去问测试，刚才怎么操作的来着。

　　直到有一天，有个模块要大改，而且是偏底层业务的模块，事态紧急，大老板要求必须1个月完工。没办法，咬咬牙继续，以前犯过的技术债，这次终于要偿还了，心里面想着等我改完一定要离开这里，但是还得没日没夜的去改。终于上线了，由于时间紧急改动较大，不出事故是不可能的，出了事故总得有人背锅吧，好了，小公司啊，就喜欢找技术人员的事情。

　　产品设计的太复杂，用户不会操作，或者设计的流程太严格，很难操作下去。于是每天无数个电话，要求改数据库数据让他们通过请求的，为了应对每天的需求，公司很贴心的给配了个座机，听着咚咚咚、咚咚咚的响声，心里面忍不住mmp，我tm到底是技术还是客服啊，一天24小时轰炸啊。

　　项目终于完结了，不用再受其痛苦了，苍天开眼了啊！万万没想到的是，分配到了另一个项目中。吐槽模式开启中：

　　注释写的啥玩意儿啊；1000+行的方法十几层嵌套当老子的脑袋是“栈”啊；100+行的sql语句嵌套在代码中给鬼看呢；A类调用B类、B调用C、C在调用D、D调用A和B，这tm能理得清，spring的bean是支持循环引用的，但是你们也不能这么玩啊。能不能别一次查询1个数据库记录好不好；LinkedList在for循环中还用get(i)的方式用迭代器不香吗；这个功能的状态真复杂啊拎不清。又一个循环开始了。

　　于是人员流动超快，但是问题还是解决不了。直到技术leader受不了了，不停的向大领导申请并打包票说，经过重构后没任何问题，而且保质保量的完成任务。大领导权衡再三，看看目前的状况，虽然心存疑惑，但还是下定了决心，改！而且要求改成国际通用的。