领导叫我把一套代码的逻辑吃透,重写合入到另外一个 baseline 项目,但是写那个代码的人水平是真的次,应该是刚毕业的,都没咋写过代码就直接上手项目。(我们现在在做工业上位机项目,都是现场开发功能的,没有代码质量管理)。
这个成为屎山有点夸张了,顶多是一个屎堆,但是味儿绝对正点。
* 代码没任何注释
* 到处都是类级别的变量
* 变量和函数和类都是随意起名字 id ,根据名字完全看不出来这个 identifier 是干嘛的,需要去看引用的地方才能看出来,但是有的引用层次关系网异常复杂,绕几下都忘记我要看的是哪个变量了。
* 手拼 JSON ,Split 拆 JSON 等这种操作到处都是。
* 巨无霸代码,所有东西写在一起,有好几个 10000+行数的代码文件。
虽然我工作这么多年也见过非常多的屎山项目,以前做互联网后端,微服务兴起之前,我见到过比这大得多的多的屎山代码,全量编译都能编译个一二十分钟的都有。但是以前是只是在项目上再加点料就行了,而现在要做的是把整个项目吃透,我该怎么办?有没有啥好的策略?
PS:跑路不能算是一个好策略,我在看这坨代码的时候晕头转向,满脑子都在想着跑路,但是现在工作太难找了,经历过后疫情的裁员后找工作从希望到失望到绝望的感觉,我宁愿继续啃这坨代码。
其次慢慢的做安全级别很高的重构,比如通过 IDE 或者 AI 把大块的业务摘出来,作为子方法,让主流程留下的是业务上的抽象方法,然后再挨个分析。
个人觉得这个不算多屎,因为他把所有东西放一起了,那充其量就是有点菜有点恶心而已。真正的屎是充满了自以为是的过度抽象化设计,不进断点都看不出来代码是怎么跑的那种。
别吃了,我几年都没搞定公司服务器怎么连接。只能用现成的库,各种魔改 OKHTTP ,没有注释!里面的第三方库复制粘贴不知道改了什么,也不知道是粘贴的哪个版本,反正我替换成最新的就不能用了。十几个 class 内容相似,有些大小写不一样,有些属性不一样,但挡住 class 名称绝对分不清。它们之间有的可以互相转换,有的不能。现在要加变量,问是都加还是只加用到的。当然是都加,因为不知道什么鸟地方最后传个 API 了,少个值就报错了。
还有奇葩的点是 A 里面的 xxx 和 B 里面的 xxx 可能不是一个类型,转换的时候要把 xxx 转成的 yyy 。变量名也不是 JSON 名,因为有的指定了 serialization name…
第二是用 AI 来梳理代码,不要想着直接用 AI 重构,而是先用 AI 大概解读一下代码的功能,当前的 AI 还是解释能力强于重构能力。
楼下提到用 AI 直接梳理依赖关系目前还不现实,但是你可以用 AI 来写一些代码依赖的分析脚本,在这些脚本的加持下增进对代码的理解。
接下来就是翻译了,把 A 架构代码翻译到 B 架构。在翻译前,把测试用例准备好,不用很全,覆盖主要功能就行。这个时候再去抠变量名和代码细节,边翻译边加注释。我重写过很多个零文档的项目,别看代码量唬人,可能很多是复制粘贴重复的,很多是压根儿就没用到。
然后就可以开始解遗留的 bug 了,解 bug 的过程就是了解细节的过程,边解边把一些觉得值得重构的点打上 TODO 。
再然后就是接新的需求了,新的需求肯定是要改造现有的代码的,那就按自己思路做分层,实在改不动的代码就他妈先包成一个函数,写个自己能懂的函数名字,打上注释能用,不要轻易改动。
我现在就是尽量自己的新写的代码就把以前的功能完全重构掉,改不动就封装起来,下层的代码尽量要稳定,上层可以快速迭代,当然屎山就是屎山,不可能一步到位,只能走一步看一步了,也没有时间来完全重写。
ps:我这里是一个 golang 的项目,然后被各位大佬硬是写成了 java 的风格,我也是服气的,然后上了他们手撸的依赖注入,导致看代码逻辑都是乱的,你都不知道这个对象是从哪里来的,我的妈呀,头疼。
所以可以考虑从上层研究,先把功能点列出来,或者做个图谱之类的,然后从功能点一个一个下去看源码如何实现,这样子
先找主干,再找分支。
抓大放小,找主体结构。
再抽抽丝剥茧,层层扒拉,熟悉细节。
1. 旧代码中指不定存在一些不管你水平如何都要加个 if 的那种被迫垃圾的代码,而且有些情况不是很好判断具体是水平问题还是业务要求,别一不小心 “优化” 掉了。
2. 代码本来就服务于业务,更好的了解业务才能明白整个代码,而且即便代码看不下去想要从写也能有的放矢。尤其是对于整体代码逻辑的构建(代码框架)。