如何强行吃透一座屎山代码？

[qwerthhusn]

领导叫我把一套代码的逻辑吃透，重写合入到另外一个 baseline 项目，但是写那个代码的人水平是真的次，应该是刚毕业的，都没咋写过代码就直接上手项目。（我们现在在做工业上位机项目，都是现场开发功能的，没有代码质量管理）。

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

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

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

PS：跑路不能算是一个好策略，我在看这坨代码的时候晕头转向，满脑子都在想着跑路，但是现在工作太难找了，经历过后疫情的裁员后找工作从希望到失望到绝望的感觉，我宁愿继续啃这坨代码。

[meeop]

1 把所有代码喂给 ai
2 让 ai 梳理:
请帮我梳理所有业务逻辑,梳理文档
请帮我梳理所有上下游依赖
请帮我梳理所有方法调用链和相关逻辑
3 重构
请帮我重构整个项目,按照 xx 规范 xx 结构重写项目

看代码量,数千行的 cursor 应该就能做到了,更多代码量暂时不能这么干,但也快了

[7gugu]

先从画流程图开始，把整个项目的流程梳理清楚，不然重构都无从下手

[whp1473]

1 、可以先读完整的产品设计，然后自己先设计一套
2 、给核心接口写单元测试，以及 Debug 代码流程
3 、在这个过程中完善自己那套设计的细节
4 、输入输出保持不变，重写所有方法的逻辑
5 、执行所有单元测试通过
6 、编写历史数据迁移脚本
7 、提交给测试进行回归测试

[whp1473]

@whp1473 核心逻辑就是面向单测重构，一本书里专门讲了，这种是最保险的，缺点就是成本比较高

[oncethink]

别光想着和代码硬刚，一定要和领导讲清楚重构这些系统的难度，确定要让意识到不是你能力不行，而是重构有这些问题的旧系统，对任何技术水平的开发者都有难度；
第二是用 AI 来梳理代码，不要想着直接用 AI 重构，而是先用 AI 大概解读一下代码的功能，当前的 AI 还是解释能力强于重构能力。
楼上提到用 AI 直接梳理依赖关系目前还不现实，但是你可以用 AI 来写一些代码依赖的分析脚本，在这些脚本的加持下增进对代码的理解。

[cccvno1]

@sagaxu [可能很多是复制粘贴重复的，很多是压根儿就没用到] 太对味了

[oncethink]

还有楼上提到的梳理数据的思路也很好，采用滑铁卢风格理清整个系统的数据转换比理清楚代码行为更容易增强对系统的理解。

[darkengine]

完全看不出来这个 identifier 是干嘛的
-------
看懂一个 identifier 之后，马上用一个合理的名字把它换掉，记得使用 IDE 的 rename 功能（千万不要全局替换！！）。

[oncethink]

另外你可以考虑用使用一些代码的复杂度计算工具，例如看看循环复杂度，代码的不稳定度，然后从循环复杂度最低的函数开始看起，从易到难，然后再去重构哪些循环复杂度高的代码。

[spadger]

刚毕业的写不出 10000+行的代码的

[Dogtler]

要么重构，要么离职。
屎山代码一般都失去业务拓展可能性，钱给够就留，没给够看 offer

[Rorysky]

这种脏活累活只能交给 gpt 了

[guanhui07]

@Dogtler 没必要自己离职，到点下班 就得

[Ackvincent]

能用就不要动，不能用就包一层，只有屎山里只能存在屎。

[RandomJoke]

先理解业务，再理解代码，准备测试用例，再考虑一点点重构

[winterbells]

别吃了，我几年都没搞定公司服务器怎么连接
只能用现成的库
各种魔改 OKHTTP ，没有注释
里面的第三方库复制粘贴不知道改了什么，也不知道是粘贴的哪个版本，反正我替换成最新的就不能用了
十几个 class 内容相似，有些大小写不一样，有些属性不一样，但挡住 class 名称绝对分不清。它们之间有的可以互相转换，有的不能。现在要加变量，问是都加还是只加用到的。当然是都加，因为不知道什么鸟地方最后传个 API 了，少个值就报错了

[winterbells]

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

[shapper]

先把主框架给梳理出来（可以通过调试快速画出来 [函数调用] ），主框架出来了，分支可以细化分析

[jjwjiang]

首先现在有 AI ，可以非常大的降低这种事情的难度。

其次慢慢的做安全级别很高的重构，比如通过 IDE 或者 AI 把大块的业务摘出来，作为子方法，让主流程留下的是业务上的抽象方法，然后再挨个分析。

个人觉得这个不算多屎，因为他把所有东西放一起了，那充其量就是有点菜有点恶心而已。真正的屎是充满了自以为是的过度抽象化设计，不进断点都看不出来代码是怎么跑的那种。

[dododada]

先黑盒，简单了解输入输出，有空了再白盒吧