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

[qwerthhusn]

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

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

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

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

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

[wangshushu]

ai 是一个方向，说不定将来 AI 继续 Scale Up ，真的有机会解决屎山问题

[sn0wdr1am]

屎要一口一口吃。🐶

先找主干，再找分支。

抓大放小，找主体结构。

再抽抽丝剥茧，层层扒拉，熟悉细节。

[pkoukk]

@LitterGopher 业务要是真那么逻辑清晰讲道理，代码就不会写成屎山了。

[majianglin]

钱给够吃屎都行，屎山代码算啥

[blankqwq]

不如吃透业务

[karnaugh]

硬吃呗，不过这东西就像医学一样，你如果上来就从底层细胞开始研究，那因为代码互相调用影响啥的，你很难从底层推出上层会发生什么

所以可以考虑从上层研究，先把功能点列出来，或者做个图谱之类的，然后从功能点一个一个下去看源码如何实现，这样子

[karnaugh]

哦对了，可以申请个带鱼屏，便宜的也就 1000 来块钱，超长屏幕同时看 4 段代码不成问题😂

[BugCry]

当成黑盒，包一层不就行了
又不是不能用.jpg

[Codingxiaoshi]

@cccvno1 我觉得这哥们儿说的可行

[MrVito]

我建议的两种解法，一种是直接把这部分代码封装，当成第三方库扔到 baseline 里面，然后根据需求在里面加点屎；另一种就是完全重写，从业务出发，完全不看这些屎。

[tool2dx]

@pkoukk OP 这个是工业项目，需求感觉也还好，仅仅是代码乱一点。APP 业务的需求，才是天花乱坠。

[mingliao]

@sn0wdr1am 精辟

[mars2023]

既然都重写了，那么你应该只需要梳理业务需求，然后结合测试用例重新写一个就好了。
又不是让你重构 🐶

[lasuar]

钱够就猛吃，不够就慢慢吃，总会吃完的，反正都得吃。PS: 只吐槽不会凸显你的技术水平多好。

[fredweili]

借助 copilot 之类的吧

[sss15]

画图，现在很多在线画图的画布都是无限大的，你就一层一层绕，一边绕一边画就行了

[zhu327808]

我最近接手的项目就是这样，只有一份代码，没有文档，只有一个可用的环境，我的方式是这样的，先理解产品的功能，从功能出发猜测大概是怎么实现的，当然要看的是主流程的功能，把一个整个功能流程了解透，再思考如果是自己做该怎么做

有了上一步的一个梳理带着到底是不是这么实现的，来看代码中的主要流程，先不要关注细节，梳理流程，然后把一整个代码的流程串起来

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

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

我现在就是尽量自己的新写的代码就把以前的功能完全重构掉，改不动就封装起来，下层的代码尽量要稳定，上层可以快速迭代

当然屎山就是屎山，不可能一步到位，只能走一步看一步了，也没有时间来完全重写

ps：我这里是一个 golang 的项目，然后被各位大佬硬是写成了 java 的风格，我也是服气的，然后上了他们手撸的依赖注入，导致看代码逻辑都是乱的，你都不知道这个对象是从哪里来的，我的妈呀，头疼

[xloger]

灵活应用 Copilot ，让 AI 来辅助你理解代码。
然后，要重构或者基于它改代码，重要的思路是：你自己要理清楚整个业务上怎么样的，结合现实中这个业务的流程和代码的实现，整理出一套接口 驱动这个旧代码。
这样里面的具体实现没那么重要了，你可以在不用完全理解里面实现细节的情况下驾驭它，哪怕有问题也能快速定位。

但是，但是哦，如果自己水平欠佳或者梳理到一半凑合了。后人接手你的代码，那观感就是这层山上又叠了一大层......

[sagaxu]

从功能出发，先熟悉这个程序的功能，然后看看需求文档（大概率没有或者出入较大），再自己从零开始设计一个方案，想想看自己开发会怎么做。

然后开始看代码，忽略细节，只到文件或类层级，把几个主干类加上注释，理清脉络，画出一个整体结构来，跟自己设计的方案对比一下，也许这个时候需要修正自己的方案。

接下来就是翻译了，把 A 架构代码翻译到 B 架构。在翻译前，把测试用例准备好，不用很全，覆盖主要功能就行。这个时候再去抠变量名和代码细节，边翻译边加注释。

我重写过很多个零文档的项目，别看代码量唬人，可能很多是复制粘贴重复的，很多是压根儿就没用到。

[lanif]

分成一个个小的部分丢给 chatgpt