论生产环境的屎山代码。

2024 年 2 月 21 日
 wuyadaxian
公司有几坨厚重的代码在生产环境跑着。
虽然能满足业务,但是代码效率低下。


前段时间我尝试优化这部分代码,
改来改去发现全都是坑,
只能全部重构。


最后研究了半天,得出的结论是,让老板买新设备,生产环境整体迁移过去。


生产环境代码,能不动就不要动。
就算是屎山,只要能稳定运行就是好代码。
性能不够?加硬件!
9541 次点击
所在节点    程序员
71 条回复
andykuen959595
2024 年 2 月 21 日
能跑就别动!哈哈哈 一坨好屎
asAnotherJack
2024 年 2 月 21 日
重构完过段时间同样会变成别人眼里的屎山 2.0
Myprajna
2024 年 2 月 21 日
自己的事业可以试试,别人的事业就算了。
visper
2024 年 2 月 21 日
一山还有一山高。我们不断在吐槽屎山,谁知道是不是又要创建新的屎山。
mightybruce
2024 年 2 月 21 日
此时搬出架构师考试的内容

遗留系统的演化策略
把对遗留系统的评价结果分列在的四个象限内,对处在不同象限的遗留系统采取不同的演化策略:

淘汰策略
第 3 象限为低水平、低价值区,即遗留系统的技术含量较低,且具有较低的商业价值。对这种遗留系统的演化策略为淘汰,即全面重新开发新的系统以代替遗留系统。

完全淘汰是一种极端性策略,一般是企业的业务产生了根本的变化,遗留系统基本上不再适应企业运作的需要;或者是遗留系统的维护人员、维护文档资料都丢失了,经过评价,发现将遗留系统完全淘汰,开发全新的系统比改造旧系统从成本上更合算。

对遗留系统的完全淘汰是企业资源的根本浪费,应该善于“变废为宝”,通过对遗留系统功能的理解和借鉴,可以帮助新系统的设计,降低新系统开发的风险。

继承策略
第 4 象限为低水平、高价值区,即遗留系统的技术含量较低,可满足企业运作的功能或性能要求,但具有较高的商业价值,目前企业业务对该系统仍有很大的依赖性。

对这种遗留系统的演化策略为继承,在开发新系统时,需要完全兼容遗留系统的功能模型和数据模型;为了保证业务的连续性,新老系统必须并行运行一段时间,再逐渐切换到新系统上运行。

要做到对遗留系统的继承,必须对系统进行分析,得到旧系统的功能模型和数据模型,这种分析可以部分代替或验证系统的需求分析;如果遗留系统的维护文档不完整,而又必须解析系统的功能模型和数据模型,那将是一项十分艰巨的任务。这时可使用有关系统重构的 CASE 工具,通过分析系统的代码生成系统结构图或其他报告。

改造策略
第 1 象限为高水平、高价值区,即遗留系统的技术含量较高,本身还有较大的生命力,且具有较高的商业价值,基本上能够满足企业业务运作和决策支持的要求;这种系统可能建成的时间还很短,对这种遗留系统的演化策略为改造。

这些改造包括系统功能的增强和数据模型的改造两个方面:系统功能的增强是指在原有系统的基础上增加新的应用要求,对遗留系统本身不做改变;数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型转化的过程。

集成策略
第 2 象限为高水平、低价值区,即遗留系统的技术含量较高,但其商业价值较低,可能只完成某个部门(或子公司)的业务管理;这种系统在各自的局部领域里工作良好,但从企业全局来看,多个这样的系统,他们各自基于不同的平台,不同的数据模型,无法互联互通,数据还不一致,这就是很严重的问题了。
54xavier
2024 年 2 月 21 日
接手项目是两个屎山,几千行代码没有啥注释,变量命名随意,很多全局变量,每次需求调整都是在屎山上雕花。每次调整都担心触发新的 bug (线上事故损失需要开发承担),还好我兢兢业业,小心翼翼,8 个月来还没造成过事故,然后在今年年初提了离职,人跑了!
thinkwei2012
2024 年 2 月 21 日
拆分或许是个好一点的办法,这或许就是微服务的好处吧。小屎山总比大屎山好处理一点吧,🐶
forbreak
2024 年 2 月 21 日
不是不能重构,只是你不会觉得你重构完了,就不是屎山了吧。
zt5b79527
2024 年 2 月 21 日
肚子疼,拿着纸进了厕所,发现一座屎山,你的做法是:
a 拉就完事了
b 拿着木棍巴拉开,从颜色和形状分辨一下都特么是谁拉的
c 向领导申请时间:这座山存在太久了,我找几个人重新拉一座新鲜热乎的山,参与的至少都是在座各位的熟人,知根知底心里接受度高一些

这样一想就明白怎么做了吧
jasonyang9
2024 年 2 月 21 日
千万不要重构💩,否则所有大小 bug 都是你搞出来的😂
Ackvincent
2024 年 2 月 21 日
封装 把屎山都打包进隔离区。
meeop
2024 年 2 月 21 日
重构又如何,有谁的代码不是屎山吗?

不存在完美的代码,特别是在追求结果而不在乎过程的商业公司环境下,能用就行
duron600
2024 年 2 月 21 日
我比较好奇这帖子里有没有一个真的会“重构”这项技术。
Duanpei
2024 年 2 月 21 日
不要重构,不要重构, 不要重构! 能跑就行! 一定要保持上班身心愉悦
chevalier
2024 年 2 月 21 日
屎山不是不能优化(重构),具体要衡量一下收益。

这里的收益不是指给公司带来的收益,是给自己的收益。

比如通过优化可以把业务指标提升多少,然后给自己晋升添加素材,让老板知道升职加薪等
wangsd
2024 年 2 月 21 日
基本上能用就行了,投入的人力成本堆在硬件上效果可能更好。
woshinide300yuan
2024 年 2 月 22 日
刚拉完一泡,好舒服。
JZ8ZW193q6W9Awgy
2024 年 2 月 22 日
@dudubaba #10 大佬,添砖可以,舔砖可不行啊。。。
JZ8ZW193q6W9Awgy
2024 年 2 月 22 日
@lsk569937453 #1 大部分情况下,添加设备的费用比重构的费用加风险低多了,而且重构大概率会从一坨屎山变成另外一坨屎山。
dog82
2024 年 2 月 22 日
能静下心,抽丝剥茧也不错,但是没啥收益,领导不会因为你优化了给你加薪

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1017106

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX