关于祖传“屎山”代码的一些思考

目前负责一个持续迭代了好几年的系统，同时还是两种技术栈并存，很多文件都是上千行的代码，完全不具备可阅读性，修改一个变量为了防止修改不完全，只能靠文件搜索找引用依赖，十分炸裂…

对于我这种有点代码洁癖的人来说，简直欲罢不能，时刻都在想着如何能改变“屎山”代码的现状…

重构？

但是很大的问题在于业务逻辑相当复杂，没人知道详细逻辑，而且线上稳定运行，使用频繁，风险很大。

然后还很难回答，重构能给业务带来什么收益？

越想越无力！～

偶然在知乎上看到这样两个问题：

• 如何妥善的应对祖传屎山(代码)?
  https://www.zhihu.com/question/347870607
• 你见过最烂的代码长什么样子？
  https://www.zhihu.com/question/265453795/answer/1453787207

看完下面各种欢乐的回答，感觉跟“屎山”代码和解了！～

这其中有一句话说得好：再差的代码也是经过线上验证过的！

而且，重构的代码从最终结果来看，不一定能赶上重构前的代码，至少没有经过线上各种情况的锤炼。

相信不论哪个系统，当不停迭代几年之后，或多或少都会有这样的问题。

原因很简单：那就是越到后面，迭代的人越需要小心翼翼，只能基于现有的设计与架构去新增业务逻辑，从而代码结构越来越变形，渐渐变成“屎山”代码。

从目前的情况，换个角度来看，实际上还是有很多有价值的东西的，比如

有哪些好的方式可以避免一个长期迭代的系统代码味道慢慢变味儿？

从最开始的系统架构、中间的迭代、最新业务逻辑的增加可以有哪些思路去规避最终的问题？

可以站在业务最终态的角度去思考业务系统的发展逻辑，有没有办法从最开始的架构设计上减轻目前的困境？

总的来说，学会妥协，并且从中发现能让自己有收获的点，一切都坦然了。