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