• 领导要我强吃屎山代码 该咋整?
  • 发布于 2个月前
  • 272 热度
    17 评论
领导叫我把一套代码的逻辑吃透,重写合入到另外一个 baseline 项目,但是写那个代码的人水平是真的次,应该是刚毕业的,都没咋写过代码就直接上手项目。(我们现在在做工业上位机项目,都是现场开发功能的,没有代码质量管理)。

这个成为屎山有点夸张了,顶多是一个屎堆,但是味儿绝对正点。

* 代码没任何注释
* 到处都是类级别的变量
* 变量和函数和类都是随意起名字 id ,根据名字完全看不出来这个 identifier 是干嘛的,需要去看引用的地方才能看出来,但是有的引用层次关系网异常复杂,绕几下都忘记我要看的是哪个变量了。
* 手拼 JSON ,Split 拆 JSON 等这种操作到处都是。
* 巨无霸代码,所有东西写在一起,有好几个 10000+行数的代码文件。

虽然我工作这么多年也见过非常多的屎山项目,以前做互联网后端,微服务兴起之前,我见到过比这大得多的多的屎山代码,全量编译都能编译个一二十分钟的都有。但是以前是只是在项目上再加点料就行了,而现在要做的是把整个项目吃透,我该怎么办?有没有啥好的策略?

PS:跑路不能算是一个好策略,我在看这坨代码的时候晕头转向,满脑子都在想着跑路,但是现在工作太难找了,经历过后疫情的裁员后找工作从希望到失望到绝望的感觉,我宁愿继续啃这坨代码。
用户评论
  • 叫我小透明
  • 如果不能跑路的话,那就只能硬吃了。看一下有没有当初的项目文档,需求说明书,设计文档之类的,然后也可以看一下能否找到该系统的核心用户,跟他们交流一下这个项目的的整体功能需求,然后从功能模块入手,一个个模块去拆解吃透。
  • 2024/9/14 22:59:00 [ 0 ] [ 0 ] 回复
  • 奥特蛋
  • 首先现在有 AI ,可以非常大的降低这种事情的难度。
    其次慢慢的做安全级别很高的重构,比如通过 IDE 或者 AI 把大块的业务摘出来,作为子方法,让主流程留下的是业务上的抽象方法,然后再挨个分析。
    个人觉得这个不算多屎,因为他把所有东西放一起了,那充其量就是有点菜有点恶心而已。真正的屎是充满了自以为是的过度抽象化设计,不进断点都看不出来代码是怎么跑的那种。
  • 2024/9/14 15:21:00 [ 0 ] [ 0 ] 回复
  • 心已凉
  • 别吃了,我几年都没搞定公司服务器怎么连接。只能用现成的库,各种魔改 OKHTTP ,没有注释!里面的第三方库复制粘贴不知道改了什么,也不知道是粘贴的哪个版本,反正我替换成最新的就不能用了。十几个 class 内容相似,有些大小写不一样,有些属性不一样,但挡住 class 名称绝对分不清。它们之间有的可以互相转换,有的不能。现在要加变量,问是都加还是只加用到的。当然是都加,因为不知道什么鸟地方最后传个 API 了,少个值就报错了。


    还有奇葩的点是 A 里面的 xxx 和 B 里面的 xxx 可能不是一个类型,转换的时候要把 xxx 转成的 yyy 。变量名也不是 JSON 名,因为有的指定了 serialization name…

  • 2024/9/14 15:20:00 [ 0 ] [ 0 ] 回复
  • 那场梦
  • 别光想着和代码硬刚,一定要和领导讲清楚重构这些系统的难度,确定要让意识到不是你能力不行,而是重构有这些问题的旧系统,对任何技术水平的开发者都有难度。
    第二是用 AI 来梳理代码,不要想着直接用 AI 重构,而是先用 AI 大概解读一下代码的功能,当前的 AI 还是解释能力强于重构能力。
    楼下提到用 AI 直接梳理依赖关系目前还不现实,但是你可以用 AI 来写一些代码依赖的分析脚本,在这些脚本的加持下增进对代码的理解。
  • 2024/9/14 15:17:00 [ 0 ] [ 0 ] 回复
  • 我怕黑
  • 从功能出发,先熟悉这个程序的功能,然后看看需求文档(大概率没有或者出入较大),再自己从零开始设计一个方案,想想看自己开发会怎么做。然后开始看代码,忽略细节,只到文件或类层级,把几个主干类加上注释,理清脉络,画出一个整体结构来,跟自己设计的方案对比一下,也许这个时候需要修正自己的方案。

    接下来就是翻译了,把 A 架构代码翻译到 B 架构。在翻译前,把测试用例准备好,不用很全,覆盖主要功能就行。这个时候再去抠变量名和代码细节,边翻译边加注释。我重写过很多个零文档的项目,别看代码量唬人,可能很多是复制粘贴重复的,很多是压根儿就没用到。
  • 2024/9/14 15:16:00 [ 0 ] [ 0 ] 回复
  • 顾及谁
  • 我最近接手的项目就是这样,只有一份代码,没有文档,只有一个可用的环境,我的方式是这样的,先理解产品的功能,从功能出发猜测大概是怎么实现的,当然要看的是主流程的功能,把一个整个功能流程了解透,再思考如果是自己做该怎么做。有了上一步的一个梳理带着到底是不是这么实现的,来看代码中的主要流程,先不要关注细节,梳理流程,然后把一整个代码的流程串起来。

    然后就可以开始解遗留的 bug 了,解 bug 的过程就是了解细节的过程,边解边把一些觉得值得重构的点打上 TODO 。

    再然后就是接新的需求了,新的需求肯定是要改造现有的代码的,那就按自己思路做分层,实在改不动的代码就他妈先包成一个函数,写个自己能懂的函数名字,打上注释能用,不要轻易改动。

    我现在就是尽量自己的新写的代码就把以前的功能完全重构掉,改不动就封装起来,下层的代码尽量要稳定,上层可以快速迭代,当然屎山就是屎山,不可能一步到位,只能走一步看一步了,也没有时间来完全重写。

    ps:我这里是一个 golang 的项目,然后被各位大佬硬是写成了 java 的风格,我也是服气的,然后上了他们手撸的依赖注入,导致看代码逻辑都是乱的,你都不知道这个对象是从哪里来的,我的妈呀,头疼。
  • 2024/9/14 15:15:00 [ 0 ] [ 0 ] 回复
  • Zappos
  • 我建议的两种解法,一种是直接把这部分代码封装,当成第三方库扔到 baseline 里面,然后根据需求在里面加点屎;另一种就是完全重写,从业务出发,完全不看这些屎。
  • 2024/9/14 15:14:00 [ 0 ] [ 0 ] 回复
  • Cactus
  • 硬吃呗,不过这东西就像医学一样,你如果上来就从底层细胞开始研究,那因为代码互相调用影响啥的,你很难从底层推出上层会发生什么。
    所以可以考虑从上层研究,先把功能点列出来,或者做个图谱之类的,然后从功能点一个一个下去看源码如何实现,这样子
  • 2024/9/14 15:13:00 [ 0 ] [ 0 ] 回复
  • APAC
  • 屎要一口一口吃。
    先找主干,再找分支。
    抓大放小,找主体结构。
    再抽抽丝剥茧,层层扒拉,熟悉细节。
  • 2024/9/14 15:12:00 [ 0 ] [ 0 ] 回复
  • 弄潮儿
  • 如果是我的话我不会从代码入手,而是从业务入手。两个原因:
    1. 旧代码中指不定存在一些不管你水平如何都要加个 if 的那种被迫垃圾的代码,而且有些情况不是很好判断具体是水平问题还是业务要求,别一不小心 “优化” 掉了。
    2. 代码本来就服务于业务,更好的了解业务才能明白整个代码,而且即便代码看不下去想要从写也能有的放矢。尤其是对于整体代码逻辑的构建(代码框架)。
  • 2024/9/14 15:10:00 [ 0 ] [ 0 ] 回复
  • 原木风
  • 只能借助 AI ,一个函数一个函数拆解了。让 AI 给你写注释,然后你快速看一下,大概那些功能在那些函数里面。你如果要新增功能的话,单独开新的问题,单独写。
  • 2024/9/14 15:09:00 [ 0 ] [ 0 ] 回复
  • 张蜚
  • 为什么喜欢隔这吃屎呢?都定屎山了,要么搅乱,要么别管,让后你自己拉坨新的,你为什么要去研究怎么吃透.......
  • 2024/9/14 15:07:00 [ 0 ] [ 0 ] 回复