论生产环境的屎山代码。

代码

屎山

生产

环境

71 条回复 • 2024-02-22 20:34:03 +08:00

1

lsk569937453

283 天前

5

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

2

kingterrors

283 天前

7

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

3

F7TsdQL45E0jmoiG

283 天前

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

4

Panameragt

283 天前

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

5

youyouzi

283 天前

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

6

calano

283 天前

3

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

7

jgh004

283 天前

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

8

fu82581983

283 天前

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

9

likunyan

283 天前

屎山雕花会吧？

10

dudubaba

283 天前

23

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

11

Noicdi

283 天前 via iPhone

2

粪海狂蛆.gif

12

woshinide300yuan

283 天前

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

13

ervqq

283 天前

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

14

xhatt510

283 天前

@dudubaba 绷不住了。还真是。

15

error451

283 天前

2

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

反正就击鼓传花呗

16

Yasuo666

283 天前

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

17

wuyadaxian

OP

283 天前

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

18

blackmirror

283 天前

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

19

liuidetmks

283 天前

2

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

20

gerefoxing

283 天前

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

21

scarlex

283 天前

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

22

yorkw

283 天前

1

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

23

z1154505909

283 天前

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

24

jones2000

283 天前

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

25

cabing

283 天前

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

就是加各种 adapter 吧

26

HaroldFinchNYC

283 天前

2

重构必须得有人支持

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

27

foolishcrab

283 天前 via iPhone

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

28

WDFWL

283 天前

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

29

opengps

283 天前

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

30

jatsz

283 天前

1

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

31

qiyilai

283 天前

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

32

qiyilai

283 天前

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

33

jielong

283 天前

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

34

857681664

283 天前

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

35

JingXiao

283 天前

屎上雕花

36

JingXiao

283 天前

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

37

corcre

283 天前

1

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

38

zzdgfv

283 天前

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

39

yyysuo

283 天前

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

40

tomkliyes

283 天前

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

41

andykuen959595

283 天前

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

42

asAnotherJack

283 天前

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

43

Myprajna

283 天前

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

44

visper

283 天前

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

45

mightybruce

283 天前

9

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

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

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

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

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

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

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

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

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

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

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