目前负责一个持续迭代了好几年的系统，同时还是两种技术栈并存，很多文件都是上千行的代码，完全不具备可阅读性，修改一个变量为了防止修改不完全，只能靠文件搜索找引用依赖，十分炸裂…
对于我这种有点代码洁癖的人来说，简直欲罢不能，时刻都在想着如何能改变“屎山”代码的现状…
重构？
但是很大的问题在于业务逻辑相当复杂，没人知道详细逻辑，而且线上稳定运行，使用频繁，风险很大。
然后还很难回答，重构能给业务带来什么收益？
越想越无力！～
偶然在知乎上看到这样两个问题：
- 如何妥善的应对祖传屎山(代码)?
https://www.zhihu.com/question/347870607 - 你见过最烂的代码长什么样子？
https://www.zhihu.com/question/265453795/answer/1453787207
看完下面各种欢乐的回答，感觉跟“屎山”代码和解了！～
这其中有一句话说得好：再差的代码也是经过线上验证过的！
而且，重构的代码从最终结果来看，不一定能赶上重构前的代码，至少没有经过线上各种情况的锤炼。
相信不论哪个系统，当不停迭代几年之后，或多或少都会有这样的问题。
原因很简单：那就是越到后面，迭代的人越需要小心翼翼，只能基于现有的设计与架构去新增业务逻辑，从而代码结构越来越变形，渐渐变成“屎山”代码。
从目前的情况，换个角度来看，实际上还是有很多有价值的东西的，比如
有哪些好的方式可以避免一个长期迭代的系统代码味道慢慢变味儿？
从最开始的系统架构、中间的迭代、最新业务逻辑的增加可以有哪些思路去规避最终的问题？
可以站在业务最终态的角度去思考业务系统的发展逻辑，有没有办法从最开始的架构设计上减轻目前的困境？
总的来说，学会妥协，并且从中发现能让自己有收获的点，一切都坦然了。
