论生产环境的屎山代码。

[wuyadaxian]

公司有几坨厚重的代码在生产环境跑着。
虽然能满足业务，但是代码效率低下。


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


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


生产环境代码，能不动就不要动。
就算是屎山，只要能稳定运行就是好代码。
性能不够？加硬件！

[lsk569937453]

屎山能不动就不动，重构就是给自己挖大坑。
遇到必须要改的需求，就在屎山上拉一坨新的。
屎山运行效率低，那就加机器。毕竟加机器又不是花的你的钱，你心疼什么？
----工作 8 年，见过无数屎山的老码农只能传授你如上经验了。

[kingterrors]

如果大家都是“又不是不能用”的心态工作，你就要融入进去，保留公司文化，创造屎山，提高“效率”。（ 99.9999%以上企业）
如果大家工作幸福感强，老板愿意在团队技能和个人提升方面投入时间和资源，恰好你也是一个追求极致的开发者，那你就多和同事老板沟通提出自己的优化想法和相关规划。（可遇不可求）
------
如果硬要作对，比如在屎山面前优化，或者在良好的团队内摆烂，那反正还是自己吃亏。hhh
----工作 12 年，啥代码都见过的老码农的一点个人看法。

[morenacl]

往屎山上添屎才是正确操作

[Panameragt]

应该是年轻人，但别提重构

[youyouzi]

至理名言：“人和代码，有一个能跑就行”

[calano]

怎么证明优化完不是另一座屎山？

[jgh004]

别没事找事，老板在乎它是不是屎山么，反正吃屎的不是他，是你。为了让你少吃屎就加大成本？不可能的。对他来说这是无效投入。

[fu82581983]

大部分场景算投入产出，假如能加硬件解决，绝对比重构+回归的人力投入便宜多了

[likunyan]

屎山雕花会吧？

[dudubaba]

小时候上厕所，遇到屎山不好拉，就在屎山旁边垫两块砖，下次继续舔砖就行。工作也是一样，除非你想当厕所保洁员。

[Noicdi]

粪海狂蛆.gif

[woshinide300yuan]

@dudubaba 我哭死，你太会讲情景了。

[ervqq]

优化了代码为公司带来了什么？这个模块快了？万一优化完有 bug ，业务部门会怎么想？（原来用得好好的，现在用不到了）

[xhatt510]

@dudubaba 绷不住了。还真是。

[error451]

@dudubaba 然后砖垒的太高，最后一个垫砖的人大概率要掉坑里。

反正就击鼓传花呗

[Yasuo666]

明知山有屎，偏向屎山行，你图啥？

[wuyadaxian]

@error451 砖太高了的话，就只能提裤子跑路了。

[blackmirror]

能满足业务，就是在为公司赚钱，修改完你能保证不出 BUG ，到时就是亏钱了，SO

[liuidetmks]

石山有的代码，是依赖另外的 bug 运行，你不知道具体业务，最好别改

[gerefoxing]

改了之后就墨菲定律，一定会出问题的

[scarlex]

除了原作者，谁都别想重构

[yorkw]

@liuidetmks #19 错进错出的代码，你以为是 bug ，其实是 feature

[z1154505909]

我现在就要维护一坨屎山,改不了,新需求通过拦截请求完成

[jones2000]

能运行，就不要乱动， 特别是不是自己写的代码。能用钱解决的问题，千万不要写代码去解决。

[cabing]

不要动，除非是有机会重构。

就是加各种 adapter 吧

[HaroldFinchNYC]

重构必须得有人支持

自己主导的重构，一旦出错，你死定了

[foolishcrab]

模块重构起码要+1 赞成
项目重构起码+2

[WDFWL]

抛开多余的责任心
当然要是地位够高可以带人弄重构

[opengps]

重构不是不行，而是你未必能考虑那么多问题，所以你看来的屎山，你重新拉出来未必更小

[jatsz]

屎山的是代码还好，当你重构到一半才发现业务本身就是屎山的，你该怎么办？这是趟这趟屎之前需要考虑的。

[qiyilai]

复杂且不明确的业务场景多次迭代后就是这个样子

[qiyilai]

重构也得是原班人马重构，换一批人搞到最后也就是新风格屎山

[jielong]

工作一半是创造，一半是毁灭，遵循事物发展规律

[857681664]

能跑就行，不然改坏了都得你背锅了

[JingXiao]

屎上雕花

[JingXiao]

有时候你惊讶的不是代码怎么不能跑了，而是这种代码居然也能跑起来，神奇

[corcre]

@scarlex 原作者: "啥啊? 这啥啊? 这写的啥啊? 这我写的? 这干什么用的? 这玩意没见过啊? "

[zzdgfv]

老板都没提，建议别多管，出问题你背锅，干好了顶多夸你一句

[yyysuo]

@opengps 重点是要先把屎山吃了。看到大家对屎山这么有经验，我就放心了。

[tomkliyes]

能产生价值的屎山，就不能叫屎山

[andykuen959595]

能跑就别动！哈哈哈 一坨好屎

[asAnotherJack]

重构完过段时间同样会变成别人眼里的屎山 2.0

[Myprajna]

自己的事业可以试试，别人的事业就算了。

[visper]

一山还有一山高。我们不断在吐槽屎山，谁知道是不是又要创建新的屎山。

[mightybruce]

此时搬出架构师考试的内容

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

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

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

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

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

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

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

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

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

集成策略
第 2 象限为高水平、低价值区，即遗留系统的技术含量较高，但其商业价值较低，可能只完成某个部门（或子公司）的业务管理；这种系统在各自的局部领域里工作良好，但从企业全局来看，多个这样的系统，他们各自基于不同的平台，不同的数据模型，无法互联互通，数据还不一致，这就是很严重的问题了。

[54xavier]

接手项目是两个屎山，几千行代码没有啥注释，变量命名随意，很多全局变量，每次需求调整都是在屎山上雕花。每次调整都担心触发新的 bug （线上事故损失需要开发承担），还好我兢兢业业，小心翼翼，8 个月来还没造成过事故，然后在今年年初提了离职，人跑了！

[thinkwei2012]

拆分或许是个好一点的办法，这或许就是微服务的好处吧。小屎山总比大屎山好处理一点吧，🐶

[forbreak]

不是不能重构，只是你不会觉得你重构完了，就不是屎山了吧。

[zt5b79527]

肚子疼，拿着纸进了厕所，发现一座屎山，你的做法是：
a 拉就完事了
b 拿着木棍巴拉开，从颜色和形状分辨一下都特么是谁拉的
c 向领导申请时间：这座山存在太久了，我找几个人重新拉一座新鲜热乎的山，参与的至少都是在座各位的熟人，知根知底心里接受度高一些

这样一想就明白怎么做了吧

[jasonyang9]

千万不要重构💩，否则所有大小 bug 都是你搞出来的😂

[Ackvincent]

封装 把屎山都打包进隔离区。

[meeop]

重构又如何,有谁的代码不是屎山吗?

不存在完美的代码,特别是在追求结果而不在乎过程的商业公司环境下,能用就行

[duron600]

我比较好奇这帖子里有没有一个真的会“重构”这项技术。

[Duanpei]

不要重构，不要重构， 不要重构！ 能跑就行！ 一定要保持上班身心愉悦

[chevalier]

屎山不是不能优化（重构），具体要衡量一下收益。

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

比如通过优化可以把业务指标提升多少，然后给自己晋升添加素材，让老板知道升职加薪等

[wangsd]

基本上能用就行了，投入的人力成本堆在硬件上效果可能更好。

[woshinide300yuan]

刚拉完一泡，好舒服。

[xixibb]

@dudubaba #10 大佬，添砖可以，舔砖可不行啊。。。

[xixibb]

@lsk569937453 #1 大部分情况下，添加设备的费用比重构的费用加风险低多了，而且重构大概率会从一坨屎山变成另外一坨屎山。

[dog82]

能静下心，抽丝剥茧也不错，但是没啥收益，领导不会因为你优化了给你加薪

[xuanbg]

自己也在屎山上拉屎，拉的多了，屎山也就不那么臭了。毕竟上面自己也拉了很多🐶

[nuanshen]

谁没经历过屎上雕花呢

[sbldehanhan]

程序员这个职业好艰难。大龄的话面临失业，就算保住工作，也得在屎山上工作。

[IamUNICODE]

重构这个玩意，要是还能用，而且不能一次性把整个系统换了，就不要去动了，要牵扯的太多了。

[zw1one]

考虑下重构的投产风险、投入产出比

[wanwaneryide]

重构了又能怎能样，业务运行几年之后，还不是一坨屎山。重构的风险和代价不是一般的大。

[weaving]

@morenacl 顺便再捏个尖

[SkyLine7]

啥屎山不屎山的，能跑就行

[xiangsoft]

@dudubaba 哈哈 你这个让我想起了草莓塔

[spadger]

所有公司业务代码都避免不了成为屎山的命运

[Steaven]

@spadger 确实