为什么很多屎山代码。异常稳定?

中英文泡椒

一、很多人误会了“稳定”的来源

很多人刚入职那会儿，打开老系统:

· 几千行一个文件
· 变量名a、b、c
· if else套十几层

第一反应就是：这玩意儿我能重写一版更好的。上来就想“优化”。结果大多是:

改完代码，测试一跑，出现各种莫名其妙的bug……

稳定不是因为写得好，是因为被现实反复打磨过。

二、每一行“丑代码”，基本都有事故背景

在公司实习的时候，有一次删了一段“看起来没用"的判断。上线后一周，直接对账错乱。回滚之后才发现:

那段代码，是几年前某个客户特殊case的补丁。你现在看不懂，不是它没用，是上下文已经消失了。

现实是:

· 一个if，可能对应一次线上事故
· 一个魔法值，可能是某个接口的坑
· 一个try-catch，可能是凌晨三点才会触发的问题

你看到的是“丑”，系统记住的是“教训”。



三、“不动它”，本身就是稳定策略

老系统里，总有这种东西:

1. //这里不要动//改过，炸过

复制代码

很多人会觉得这是技术债。但你干久了会发现：这其实是经验结晶。

我发现很多网友特别喜欢“顺手优化”。结果是:

每次改动都引入新问题，最后反而拖慢整个项目节奏。

后来总结经验:

不确定的地方，宁可包一层，也不直接动。听起来不优雅，但在生产环境里稳定，比优雅重要

四、重写，大概率是踩坑重来一遍

很多人觉得："这破代码，我重写一版就好了。"

我见过的同学，真的这么干过。

前两周:

· 架构清晰
· 代码优雅
· 一切完美

第三周开始:

· 奇怪bug出现
· 边界case漏掉
· 线上问题开始积累

原因很简单：旧系统的稳定性，是时间堆出来的。你重写，相当于把所有坑，再踩一遍

五、最重要的一点:工程不是写代码，是控制风险

这是我后来才真正理解的。写代码只是第一步。真正难的是：

· 你敢不敢改
· 改了会不会炸
· 炸了谁背锅

所以你会看到一个反直觉的结论：越复杂、越丑的系统，往往越保守。

因为没人敢动，动一次代价太大。于是它就这么“稳定”下来了。

六、如果你真的接手了屎山，怎么做



别想着拯救世界，先做三件事:

1.先理解，再动手：搞清楚依赖关系，比写代码重要
2.小步改，不要大改：一次只动一点点，出问题好回滚
3.先补测试，再优化：没有测试的重构，就是盲拆炸弹

代码好不好看，是工程师的审美问题。系统稳不稳定，是业务的生死问题。大多数时候，你要选后者。