这是一个创建于 698 天前的主题，其中的信息可能已经有所发展或是发生改变。
如何避免屎山代码
- 减少屎山代码产生的可能。实行单元测试和代码审查。但时间成本提高了。
- 减少产生屎山代码的人。多招高级工程师，不招初级工程师。但人力成本提高了。
 |
1
liuhmchn 2023-01-05 09:48:58 +08:00  7
|
 |
2
8355 2023-01-05 09:48:59 +08:00
屎山代码的核心问题就是产出屎山代码的人 通过面试就可以精准筛选 人力成本一定会提高 但这取决于你的需求
|
 |
3
wanguorui123 2023-01-05 09:49:15 +08:00 5
1 、架构设计
2 、代码分层 3 、强制约束 4 、应用正确设计模式 5 、化整为零 6 、严格的代码规范审核提交 |
 |
4
rwecho 2023-01-05 09:53:08 +08:00
1. 这是主官感受还是客观事实? 怎么定义是屎山
2. 是代码屎山还是需求屎山? 怎么确定是代码写的烂而不是需求烂 |
 |
5
hahaba 2023-01-05 09:53:29 +08:00
不要试图用各种规范各种设计模式各种合理需求来规避屎山代码
|
 |
6
ixixi 2023-01-05 09:53:36 +08:00
把需求和时间控制好就解决一大半问题
|
 |
7
Ritr 2023-01-05 09:54:11 +08:00
总的来说都要增加成本，没办法，不能又要马儿跑又要马儿不吃草
|
 |
9
itechnology 2023-01-05 09:59:00 +08:00
我觉得首先得放宽工期才行，就拿我们公司来说，每次上线时间都卡的很紧，研发根本没有时间去组织代码审查。
这一点不解决，我觉得招高级工程师也没用。 |
 |
10
dd991 2023-01-05 10:03:47 +08:00 1
为啥国外能写出牛笔的代码，因为时间充足，有时间考虑，以写的牛笔为荣，这边的老板，恨不得你马上完成，弄好后，马上滚蛋，哪有时间兼顾。人人都可以写出牛笔的代码
|
 |
11
1t1y1ILnW0x5nt47 2023-01-05 10:11:42 +08:00
换个 leader,然后新 leader 重构项目
|
 |
13
taogen OP @itechnology #9 在时间紧的情况下，高级工程师可能会好的。时间紧代码会差一点这是不可否认的，但很多最佳实践和编程规范高级工程师应该都养成了习惯。
|
 |
14
to2false 2023-01-05 10:20:57 +08:00 1
不如先解决需求端的能力问题，市面上大部分产品都是不合格的
|
 |
15
lpxxn 2023-01-05 10:26:37 +08:00 1
|
 |
16
xp999 2023-01-05 10:29:05 +08:00
DDD
|
|
17
8355 2023-01-05 10:29:49 +08:00 1
常规回答大量出现 真的很恐怖
|
 |
18
imingyu 2023-01-05 10:34:58 +08:00
只有水平不一，就会产生屎山，屎山无法杜绝！
|
 |
19
Kontinue 2023-01-05 10:38:39 +08:00
无法避免，因为屎山大多是需求端和快速开发导致的，更多都是当前各种妥协下的结果
|
 |
20
singerll 2023-01-05 10:41:44 +08:00 2
客户：
我要做个商城。 什么要半年？ 再有 20 天就过年了，我不管你用啥办法，20 天先给我上线一版。 |
 |
21
Sfilata 2023-01-05 10:42:20 +08:00
排工期不断重构，叫团队一起评审。这个东西没有时间就是无解。
|
 |
22
tianmalj0613 2023-01-05 10:47:31 +08:00 1
屎山代码也是 trade-off 的结果。比较大部分公司都选择了商业扩张优先于工程文化
|
 |
23
DinnyXu 2023-01-05 10:52:29 +08:00
这个“屎山”定义是什么？ 有待商榷......
目前我认为的屎山有以下几点： 1：代码不够简洁，有违代码简洁之道，简单的功能写的太复杂，看似各种容错，其实是各种漏洞 2：代码没有承上启下，不要写一些重复的东西，重复造轮子很蠢，很难维护 3：基于第二点，如果代码复用性差，维护起来成本就会增高，而且老人一走，新人维护简直是火葬场，也就成为了新人眼中的屎山 4：代码整体设计，这个是基于前 3 点，我个人认为一个项目应该有若干个版本，例如 1.0 、2.0 、3.0.....版本的升级维护，每一次的升级都是为了更好的优化代码，而不是堆屎山 还有你说的第二点：减少产生屎山代码的人。多招高级工程师，不招初级工程师。但人力成本提高了。多招高级工程师，简直是个伪命题，高级不代表能解决屎山的问题，架构都不一定能解决，因为每个公司对高级的定义是不一样的，普通公司的高级也就是大公司的中级，我这样说你能明白的吧...至少我身边有一些高级，我没觉得他写的代码不是屎山 |
 |
24
crazytudou 2023-01-05 10:54:46 +08:00
接手过这种项目，那真是上班都没心情，一打开项目心里就开骂。全是一些刚毕业或毕业一两年的人开发的，也没人审代码，真是不爆错就行，业务逻辑都走不通。
想杜绝屎山，那就从根上解决，出高价钱招人，要不然什么鬼方法都没用，因为那些人写代码就是这样的风格 |
 |
25
AyaseEri 2023-01-05 10:55:28 +08:00 6
2
你要减少产生屎山代码的人，需要多招高级产品经理，而不是工程师。 |
 |
26
tt67wq 2023-01-05 10:56:32 +08:00
不要尝试消灭屎山
|
 |
27
tool2d 2023-01-05 11:05:38 +08:00
最佳解决办法，把菜鸟同事换掉，但这通常是不太可能的。
退而求其次，那就是鼓励多写函数式编程，减少变量依赖。再用自研工具去合理管理代码。 屎主一般有两点特种，1 代码量太多，2 耦合性过强。针对性解决就好。 |
 |
28
Biggoldfish 2023-01-05 11:07:56 +08:00
1. 难道没有写 unit test 并经过的 code review 的代码能被 merge ？
|
 |
29
yaphets666 2023-01-05 11:16:16 +08:00
主要是工期问题，需求问题，成本问题。技术问题不是问题
|
 |
30
Rooger 2023-01-05 11:16:20 +08:00 3
提高人员的水平，但是首先提高自己的水平，同时也要清楚有些东西绝没有想象的那么简单，最近看了几本书，推荐给大家。
《人月神话》-- 往已经延期的项目中增加人力是无效的。虽然有一部分论点有些过时，但是其强调的大多观点目前仍适用，依然强烈推荐。 《代码整洁之道》-- 如何写出 Clean Code ，也就是屎山的对立面。 作者的精彩演讲视频： &t=539s 《软件设计的哲学》-- 如何控制复杂性，如何设计 作者的 Google talks 视频： &t=313s 该书 github 的翻译版本有些问题，由于时间问题，我只修正了从十二章开始的内容： https://github.com/luojiego/A-Philosophy-of-Software-Design-zh |
 |
31
Acoolda 2023-01-05 11:27:39 +08:00
无法杜绝，因为在今天你看一起来十分不合理的设计，说不定就是当时写的时候因为种种因素导致只能这么设计的，有时候很无奈。
|
 |
32
Jammar 2023-01-05 11:29:44 +08:00 1
除了你自己没有人关心你的代码是不是屎山,能赚钱的代码就是好代码
|
 |
33
jamosLi 2023-01-05 11:30:12 +08:00
绝大多数屎山不是开发堆的，是产品脑抽造成的。
代码精简不等于非屎山代码，精简的代码可能比屎山还恶心， |
|
34
taogen OP @yaphets666 #29
技术问题和工期问题，需求问题，成本问题一样，都是重要的。 现在假设工期给的是充足的，需求也是很合理的，成本也是允许提高的，但没有单元测试和代码审查等机制，让刚毕业的人来写代码，你认为代码会不会成为屎山呢？ 人是有惰性的，除非已经养成了好的编码习惯或者强制要求编码规范，否则很难主动去写好代码。 |
 |
35
bk201 2023-01-05 11:32:09 +08:00
从大环境开始吧，大环境浮躁，喜欢年轻人加班干。
|
 |
36
cubecube 2023-01-05 11:32:37 +08:00
拉屎的是人。要么限制提交（手段很多），治标不治本
要么搞定人的问题 |
 |
38
PythonYXY 2023-01-05 11:36:42 +08:00
问题大部分在需求端
|
 |
39
whileFalse 2023-01-05 11:38:30 +08:00 via iPhone
@8355 跟人有关系，但即使有足够经验的开发也扛不住瞎几把改需求以及排期不够重构的情况。
|
 |
40
LXGMAX 2023-01-05 11:38:58 +08:00 1
工程师的角度来讲，给足够的时间去研究代码效率和架构、自身向高水平看起就有可能
反之前期正在形成体系的时候各种赶，后期修补的方式，屎山就越来越高 而现实更多的是后者 |
 |
41
yc8332 2023-01-05 11:38:59 +08:00
没用的。。代码是服务业务的，除非是不直接面对用户的业务。不然屎山是无法避免的。他们的要求千奇百怪
|
 |
42
zhangtest 2023-01-05 11:51:43 +08:00
我们项目一年换 6 个产品，每个产品刚来都大刀阔斧大改版，流程逻辑都改的那种，为了兼容线上历史数据代码慢慢堆成了屎山，你来告诉我怎么解决？高级工程师有预言家的能力吗？
|
|
43
8355 2023-01-05 12:00:08 +08:00
@whileFalse #39 客观原因从开发自身无力解决的，研发话语权主要是自身部门高层决定的。
如果是业务导向型继续堆就是了，开发只要尽可能做好全责范围就好了，对老板而言其实只要系统能用可能屎山是最低成本解决方案。 |
|
44
taogen OP @zhangtest 外部矛盾，只能使用六字真言。就像接受不了也改变不了国内环境的只能润。作为技术人更多地是去提倡去改善技术上的问题。尝试跳到产品需求合理的公司。
|
 |
45
xiaofan305 2023-01-05 12:13:15 +08:00 via Android
不写代码
|
 |
46
aijam 2023-01-05 12:18:08 +08:00
屎山是无法避免的，高级程序员应该比初级更懂得如何在屎山中游泳。
|
 |
47
janxin 2023-01-05 12:19:53 +08:00
你当然不可能既要又要还要。你在某些方面想节省成本，就必然在其他方面付出成本。不过，我们可以通过在某些方面付出一部分成本，以小搏大，换取更大的成本节省。
> 实行单元测试和代码审查。但时间成本提高了 时间成本并不等于一切，计算项目成本时，时间成本只是其中一环。我们的目标是让总成本最低，而不是所有方面的成本都无限低。 > 多招高级工程师，不招初级工程师。但人力成本提高了。 你的高级工程师很难拉平在同一水平上，产出必然会参差不齐。所以这种其实比投入时间成本更不靠谱。并且，即便是筛选了人员进入，仍旧需要进一步通过其他成本抹平这种参差，毕竟这就是个水桶，取决于你的短板。而且，工程的本身其实更希望是完成标准化从而实现规模化，换句话说，工程更希望的是提升下限。 屎山目前看完全没有办法避免，我们能做到的最好的办法就是在开发前开发中和开发后都投入成本维护，确保代码库尽量慢的变成屎山。 |
 |
48
westoy 2023-01-05 12:20:28 +08:00 1
正视屎山
直面屎山 融入屎山 |
 |
49
Mark24 2023-01-05 12:25:39 +08:00 1
有没有可能，工作本身属性就是 —— 屎上雕花。
你不会因为堆屎山，写代码烂而被找麻烦。 但是你会因为需求不能及时上线而被找麻烦。 有没有可能这样的工作本身就是在屎山属性。 |
 |
50
stonesirsir 2023-01-05 12:26:30 +08:00 via Android
都按严格的流程和标准来就好，但是这个很难实现😂
|
 |
51
NiceFSH 2023-01-05 12:52:22 +08:00 via Android
本身大部分都在生产屎，你拉你的我拉我的，重要的是你要有看懂别人屎的能力，然后还要有在这坨屎上小心翼翼的加上自己的那坨，让他看起来像本来就是一坨。升职加薪
|
 |
52
likunyan 2023-01-05 13:17:33 +08:00
有一滴屎的山，也是屎山，逃不掉的
|
 |
53
icyalala 2023-01-05 13:20:50 +08:00
如果需求就是屎，那代码是不可能没有臭味的
|
 |
54
murmur 2023-01-05 13:34:19 +08:00
大家都是在屎里摸爬滚打，项目开发就是这样，产品经理不知道怎么做，用户也不知道想干嘛，都是先做个东西给用户看看，然后等反馈再改，一步到位的项目只有梦里才有。
|
 |
55
fkdog 2023-01-05 13:40:42 +08:00 1
你自己写的觉得不是屎山的代码在别人看来也许就是一坨屎山。
|
|
56
yaphets666 2023-01-05 13:52:34 +08:00
@taogen 反证法，需求瞎来一会这样，一会那样，工期紧张每天上 16 个小时班，谁能保证不写屎
|
 |
57
lanlanye 2023-01-05 13:58:47 +08:00 1
选 1 ，
理想情况下至少需要一套完整的 CI 流程，别的就无所谓了。靠测试保证功能可用，迭代的时候不需要关心研发是怎么改的，打补丁到一定程度改不动了自然需要重构，重构就可以避免 shit 。 第 2 的话，没有合理的制度保障，你就算招的全是专家估计也没用。 |
 |
58
qzhai 2023-01-05 14:13:34 +08:00 via iPhone
还有就是人事变动，要有足够的条件避免频繁的人事变动
|
 |
59
jackbrother 2023-01-05 15:11:47 +08:00
“屎山”的定义带有很强的主观意识
|
 |
60
rm0gang0rf 2023-01-05 15:17:55 +08:00
有人的地方就有江湖
|
 |
61
Building 2023-01-05 15:25:29 +08:00
首先你要定义什么是屎山啊
有些人几个环境写下来代码可能连整齐都做不到，你一眼看过去代码就跟狗啃的一样，但是逻辑很顺很高级，跑起来啥问题没有，性能也快得很，算不算屎山？ 有些人写的代码十分整齐，一眼看过去就赏心悦目的，注释说明比方法还长两倍，但是实际看下来你发现这逻辑那是一踏糊涂，算不算屎山？ |
|
62
whileFalse 2023-01-05 15:37:14 +08:00
@Building 这都只算是💩，💩⛰️是💩的交叠
|
 |
63
txy3000 2023-01-05 15:59:15 +08:00
和代码和解，接受世界是墒增有那么难吗？
|
 |
64
pkoukk 2023-01-05 16:05:07 +08:00
@Building 屎的 N 次方才是屎山，屎一样的架构设计，数据库结构，模块设计，外部依赖，最后才是代码逻辑。
如果前面的基础打的很好，代码写的烂只是在山里拉屎 |
 |
65
zhanlanhuizhang 2023-01-05 16:08:02 +08:00
怎么说了。定期重构，是最好的办法。但一般的商业公司很难实现这个。
|
 |
66
mrblacklu 2023-01-05 16:22:19 +08:00
很难，项目基本多人维护，维护人员写代码的行为不可控，除非每个人的编码素质都很高，都能写可维护性比较高的代码，而且在维护的过程中需要根据业务或者实际需求的需要进行一定的重构调整。
|
 |
67
did 2023-01-05 17:59:57 +08:00
写代码五年了 还没见过哪个公司项目里没有屎山代码的
|
|
68
did 2023-01-05 18:03:00 +08:00
说都很好听 但资本一发话你没有选择 而且何苦呢 你加班把代码搞的再好看 公司会给你涨工资吗
|
 |
69
zw1one 2023-01-05 18:12:05 +08:00
你要接受这个世界就是屎山构成的，不仅是代码。
|
|
70
zw1one 2023-01-05 18:15:57 +08:00
减少屎山的话，需要一个能平衡代码质量与业务需求的 leader ，也可以你自己成为他。
|
 |
71
timethinker 2023-01-05 18:17:19 +08:00
只需要一个像 Linus Torvalds 这种强有力的领导者即可
|
 |
72
miv 2023-01-05 19:49:46 +08:00 via Android
很多人都是说架构啊，设计呀，代码。其实一开始是需求，你理得不清楚，产品经理不行的话，那你很容易搞出浪代码。
|
 |
73
pengtikui 2023-01-05 21:35:45 +08:00
持续 & 小规模的重构
|
 |
74
YYYeung 2023-01-05 23:42:32 +08:00
不断重构
|
 |
75
SteveZou 2023-01-05 23:49:29 +08:00 via iPhone
插个话：看这个帖子我才发现自己已经分不清有些回答是不是 chatgpt 了……
|
 |
76
allgy 2023-01-06 09:18:43 +08:00
no code
|
 |
77
summerLast 2023-01-06 09:23:57 +08:00
屎山代码 本身可以描述成代码的混乱程度即可以用代码的熵来形容，方法有两个 一个是尽量少的代码和单位代码质量比较高，工程上能做的就是如何从这两个方向下手，1 就是功能能否简单的设计 2 是提高代码质量，可以参考 Unix 哲学
|
|
78
summerLast 2023-01-06 09:27:47 +08:00
我们现在遇到的绝大部分问题前人都遇到过，去学习那些大牛如何做的在根据实际情况做出相对调整即可，没有完美的方法和全部适用的具体做法，没有银弹
|
 |
79
skyqing 2023-01-06 09:28:34 +08:00
有的项目代码写的还可以，但是业务太繁琐了，要加各种判断各种兼容，导致代码可读变差
|
 |
80
agagega 2023-01-06 10:27:53 +08:00
屎山这个词到底从哪来的？这个词翻译味特别重，并不太像原生中文词，但我搜了半天也没看到有英语世界的人用 shit mountain 形容代码
|
 |
81
yoloMiss 2023-01-06 11:27:04 +08:00
没办法避免，大多数中小公司奉行的业务系统必须具有及时响应和支撑业务的能力，这样就带来了工期的上紧张的问题，例如重复的代码，不明意义的代码，没有更新维护的文档，甚至八百年前就没有动过的注释、项目初始的开发人员离职也会造成错误的理解。这样的问题都会造成楼主形容的代码问题。
|
 |
82
vipppppp 2023-01-06 11:37:05 +08:00
只要需求来的快，什么架构和设计都没用=。=
|
 |
83
edis0n0 2023-01-06 14:33:28 +08:00
82 条回复没有一条说到点上
1. 提高工资 2. 减小工作量 这两条比什么都重要 |
 |
84
Ycode 2023-01-06 15:42:26 +08:00
之前我也认为主要是开发水平问题导致屎山多。
在我从一个产品水平合格的公司跳到一个产品不如回家养猪的公司之后，我更赞同屎山代码更多来自于需求端。 当然项目工期仍然是个重要因素。 |
 |
85
casbal 2023-01-06 17:14:29 +08:00
及时冲马桶可以避免屎堆积成山
|
|
86
zhangtest 2023-01-10 14:05:58 +08:00
@taogen 要互相理解，小公司尤其是创业型公司需求本来就需要变来变去试错，怎么可能如你所愿，你能完成任务就行，老板不会看你代码的。
十几年前 asp 的天下，也有人写所谓的“优雅高大上”代码，现在还不是被时代抛弃，这种东西目的就是完成任务赚钱，屎不屎都不重要，你又不会把你写的代码传给下一代。 |
 |
87
hetingting 84 天前
需求定好后，等你做的差不多的时候，开始要频繁改需求了，就算是高级工程师，也会产生 s 山吧
|
Select Language