接了烂代码的项目,怎么玩好?

2020-08-06   阅读(56)  

来公司两年多了,一直在处理报表相关的业务。已散伙的团队留下了一个报表工具应用,没人跟我交接,这破鞋就到我手里了。

要把这个工具维护起来还是很麻烦的。

  • 没人交接,还好有个产品白皮书,能看到这个工具的功能
  • 源码只有最新的,历史版本的源码 tag 打了几个老早的版本
  • 还有一堆人找我解决其中的问题

 

接了这个烂摊子,我内心还是有点崩溃的。但是既来之则安之,把这个应用的前后端源码翻了一遍又一遍,一边改问题一边翻,同时记录各种处理逻辑。花了三个月的时间,才理的有点头绪,渐渐地处理这方面的问题也得心应手。我能一个人把这套工具撑起来,应该是超了领导的预期,当年还得了优秀员工的奖。

之后呢,我经历了一段有问题就处理,没问题就写文章、建博客、开发面试题小程序,日子过得还挺舒坦。但是心里还是放不下一个想法,就是把这个应用重构了,因为里面的代码写的真不怎么样。

比如:

  • 大量的重复代码
  • 大量的魔鬼数字
  • 大量的方法体内的代码大几百行,当参数为 1 时干嘛,当参数为 2 时干嘛......要弄明白它的整体逻辑,得花大量精力
  • 报表数据计算的很多算法,都杂糅在一起,扩展性和可读性都非常差
  • 前端页面交互很多方面不便捷,如报表的所有配置项堆在一起、配置流程不清晰缺乏引导
  • 想要进行功能的扩展,基本没有口,比如想加个排序功能,得把参数从入口方法到实际使用参数方法调用链中的方法都加上该参数,没有封装性可言

每天我都是在这么烂的代码中处理各种问题,想发力去重构它,但后来又有了其他的开发任务,只能继续忍着。

 

今年有个部门想基于这个工具进行功能扩展,老部门也要拆了,就顺势过去了。本以为自己对应用的源码已经掌握的挺熟,但真要能满足各种刁钻的需求,还挺费劲。

花了三四个月,终于快把扩展后 1.0 版发出去了,小范围重构了很多东西:

  • 配置页面全部重写了,老版本前端代码是专门的前端开发写的,其实很多可以一次跟后端交互搞定的问题,非要来来回回调很多次接口,前端的代码风格还不统一,function 的定义风格都不尽相同
  • 后端代码格式也进行了统一,tab 符去除统一使用空格、核心代码补上注释、修改拼写错误、重命名不清晰的变量名与方法名
  • 后端代码结构调整,if-else、循环、try-catch 嵌套太深的进行抽取、方法行数太多的进行拆分、公共的逻辑代码进行提取与复用、魔鬼数字与参数改用常量

然后在此基础上扩展了新功能,这算是 1.0 做到的。

 

接下来,就 1.1

  • 报表计算算法拆分与抽象
  • 请求参数封装,提高可扩展性
  • 加一些比较难实现的功能:类 excel web 设计器、包含 html 富文本的显示与打印

 

为了能把这玩意整好,我把极客时间-设计模式之美专栏看了三遍,扒了很多设计模式在 Java 中应用的源码。但学习了各种理论,可能最后还是写不好代码,或者只是把一堆垃圾代码打包整理,本质还是垃圾代码。

 

前段时间有位朋友在我建的交流群里说,想从后端转前端,原因大概是后端问题比较多,还需要跟产品经理和测试各种扯皮,他们公司的前端,画好页面写写逻辑每天按时下班。

我觉得,不管选择什么,其实都会遇到困难与瓶颈,把各种问题抓在手里很痛苦。但只要坚持,你现在为之饱受磨难的,也许是以后带你飞的东西。

 

ConstXiong 备案号:苏ICP备16009629号-3