中小公司，一般第一个版本，都是赶工上架，以我的感受，基本都是没需求、没计划、没测试（测试没时间，只能随便试试）、领导马上就要，必须上线的状态。
导致第一个版本，无论如何都是屎山。很难不想着“赶紧先交差”。
基础是屎山，屎山上加盖的建筑，很难不是屎山。
我的领悟是，小重构可以，绝对不要大重构。
除非领导要求，但领导能用就行，管 bug 、管功能、很少会管代码是不是屎山。
测试也是人，如果是新事物，比较容易认真测，如果是反复测试过的模块，很难用心测。码农也是人，新功能、新模块、思路清晰。大重构很容易大刀阔斧。
重构很容易重构出许多奇妙的、不易发觉的 bug 。写反而不会写出这样的 bug 。
如果是小重构，屎山代码，靠着小重构，根本无法应对下一波来屎（一年总是能遇到几次马上就要）
考虑到大家的水平比较高，我说的中小公司可能等于大家眼中的小公司。
目前呆过的互联网公司规模最大的 300+人，呆过的传统上市公司规模最大的 2000+人。
 |
101
fanyingmao Nov 8, 2021
大小厂都一样，而且大厂可能因为项目历史长，而叠出更高的屎山。
|
 |
102
m102 Nov 8, 2021
大厂也是如此。
曾供职于某业内前三大厂。 该厂某产品是 A 语言的开源框架基础上进行二次开发。 多轮迭代后硬生生的二开成了 B 语言。非常残暴。。。 |
 |
103
lap510200 Nov 8, 2021
上市了也是 需求变来变去 时间进度又不延期 为了赶工很难写出优雅的代码，而且经常岗位职责变动做其他事，接手的人的水平很难保证
|
 |
105
Anajiuzheyang Nov 8, 2021
现在天天写屎一样的代码，经常一个事情给一点点时间 赶着上线 然后要求能跑就好 上线后各种奇葩需求又来了又一点点时间 只能用最快的方式去解决 然后在屎山上叠屎 然后就是一座更高的屎山。
|
 |
106
duduaba Nov 8, 2021
所有公司有这样的，而且还很多。对，所有。
|
 |
107
onlyForward Nov 8, 2021
大公司的屎山比小公司要大得多,只有纯技术导向公司会稍微好一点
|
 |
108
charlie21 Nov 8, 2021
因为水平烂阿，还能因为什么？水平好的呢可以在工期紧 任务重 急忙上线 钱少时间紧的情况下，依然坚持不产出 shit 代码
|
 |
109
xuanbg Nov 8, 2021
只要是开发团队对业务的理解不够深入的，开发出来的产品就必然是屎山。因为从设计层面就错了，和代码水平反而没多大关系。
|
 |
110
leo108 Nov 8, 2021
借楼打个广告，我司有非常严格的 code review 流程，最近后端团队安排了 3 个月时间的代码质量专项训练，大到架构设计，小到变量命名。
我们在工作时有一项原则：『自己多思考，让同事少思考』。我们希望构建一个让工程师写起代码很舒服的项目环境。 招聘贴见 https://www.sunp.eu.org/t/795579 |
 |
111
Cloutain Nov 8, 2021
Oracle 传说是屎山之王
Windows 下很多应用层的管理器是屎山，包括 IE 。NT 内核还是不错的相对来说好得多 |
 |
112
decken Nov 8, 2021
只要不赶时间 + 有颗不断追求完美的心 在大小公司都可以让屎山更矮一点
|
 |
113
ww2000e Nov 8, 2021
都是那波人写的那波代码。。
|
 |
115
xw Nov 8, 2021
能用就行 /
|
 |
116
leeyom Nov 8, 2021 via iPhone
换工作其实就是从一个坑换到另外一个坑，坑其实都是💩山
|
 |
117
jsjgjbzhang Nov 8, 2021
先完成在完美，完成之后在看这个产品是否值得完美
|
 |
118
watzds Nov 8, 2021
哈哈，大公司的大，堆得更高😄
|
 |
120
a852695 Nov 8, 2021
大公司的屎山可能更大，只是有人有经费去维持和改善而已
|
|
121
a852695 Nov 8, 2021
先把业务堆上线，看看外面用户反馈如何，至于什么重构优化，再说吧，大公司忙点的项目连周末都很难保证，更没有太多时间去做优化了，能把需求做完堆上线都算庆幸了。呆过 2 个大厂，大部门业务技术部门都这样，等上线了不行的话更没有人去维护了。
|
 |
122
liuzhiyong Nov 8, 2021 via Android
我在中小公司，领导对代码要求特别严格，一个空格都要管。
|
 |
123
HeyVincent Nov 8, 2021
@cubecube 说得太对了
|
 |
124
pengtdyd Nov 8, 2021
开源项目都是这样，开源项目代码优秀的也是凤毛麟角
|
 |
125
sgissb1 Nov 8, 2021
谁告诉你的大公司就没有 sh!t 山，而且 sh ！ t 山就不多的？认知偏差有点大啊
|
 |
126
kingfalse Nov 8, 2021 via Android
都一样，大厂也一样，全国 996 的风气能出什么好代码
|
 |
127
shayuvpn0001 Nov 8, 2021
@klarkzh 飞机火箭的代码里面屎也多，不过会用各种方法把这些屎尽量隔离开来，只要他们不聚集在一起，整体就不会出大的问题。由此还诞生了一个著名的安全管理模型：Swiss cheese model
|
 |
128
shyangs Nov 8, 2021
澳洲航空 72 號班機事故
電傳系統軟體錯誤 空中浩劫.S18E07.FreeFall |
 |
129
mapoor Nov 8, 2021  1
不可否认，随着时间的推移，质量再高的代码也会被下线。
软件工程师生产代码其实就是在传递价值。 大公司的工程师更倾向于花大量时间在软件设计，代码组织上。因为只有这样才能传递更多的价值给用户。 小公司的工程师则更倾向于在有限时间内产出更多的可运行软件。毕竟小公司死的速度太快了，工程师当然需要尽快地传递价值。 那么请思考下：一个没有任何人使用的软件，那这个软件算存在吗？ 那写这个软件的人那段时间存在吗？ |
 |
130
reedthink Nov 8, 2021
功能是资产，代码是债务，你猜猜为啥叫债务
|
 |
131
48y1951r9G8k7Zou Nov 8, 2021
大厂也不怎么样。最近刚入职国内互联网前三名的某大厂的大数据部门，接手了某基础设施的代码。
那代码真是一言难尽。说实话，质量还不如开源玩具的平均水平。 据说写这代码的人还是部门老大高薪从 facebook 拉过来的。很难想象他是怎么进来的，也不难理解他为什么半年就离职了。 |
 |
133
jessun1990 Nov 8, 2021
盲猜 window 10/11 的代码也有类似的情况。
我觉得没有 shi 山写法的代码反而不正常，太简单了，感觉反而可能不太适应生产环境。 这个世界本身就是多样复杂的，都是带着 bug 运行着的。 |
 |
134
ClericPy Nov 8, 2021
面试造火箭
上线用导弹 最离谱的是, 知道是导弹还要做载人航天 已经无力反抗 |
 |
135
AyaseEri Nov 9, 2021 1
不要害怕屎山，要勇于构建屎山。直到这坨 shit 不得不重构的时候，你就有时间码一座更香的屎山了。
|
 |
136
zerofancy Nov 9, 2021
重构提技术需求，出文档，走测试。
|
 |
137
walpurgis Nov 9, 2021
写屎山是程序员练级的必经之路，这个没办法，现在回头看几年前写的代码都不忍直视，就是单纯功力不够，想获得进步还是先找自身原因，然后才是外部原因
|
 |
138
imycc Nov 9, 2021 1
有点点强迫症，自认为是对自己代码比较负责的，之前也给项目内的同事做过 code review 。总体感受就是，shit 山是无法避免的。
追求完美是不现实的。代码开发是要解决实际问题，而需求是不断变动的。你无法预测到两三年后的功能需求，打补丁是在所难免的。 你无法保证自己每一段代码都是“完美的”，你也无法保证每个同事都对自己有高要求。即使你能保证自己的设计思路一致，别人再接手的时候，也不能再次还原你的想法。时间久了就夹杂着每代开发不同的“想法”在里面了。 反正我已经看开了。之前卡同事的代码卡得比较严。现在只要别歪得太离谱，我会先给过。 搞 code review 是累活，不少团队 leader 嘴上说着要有追求，要规范 blahblahblah ，等到评绩效的时候就对你的付出视而不见。 我会尽量保持对自己的要求，跟同样有兴趣的同事交流。至于其他人，我真的管不着了 |
 |
140
danhahaha Nov 9, 2021
这篇帖子含屎量很高
|
 |
141
hjq632233317 Nov 9, 2021
事实是， 时间就是金钱 ，我的 baby ， 怎么算不是屎山， 你认为干净整洁的代码就可以迎合新的需求了么 ，谁能在做的时候想到新的需求是什么样的， 并且为新的需求留出扩展空间
|
 |
142
simo Nov 9, 2021
正在经历自己堆屎山的过程，需求一天 8 改，一个月推翻重来一次，技术团队临时拼凑（大家没有上下级，都是民工身份），开始我还做些架构，定一些规范给大家推荐一下，但是，两个月以后，只能尽力保证自己的粑粑香一点。。。。
|
|
143
simo Nov 9, 2021
怎么感觉跟楼主在一个团队呢
|
 |
144
encro Nov 9, 2021 1
代码也有两种：
1 ，有人用：BUG 很多，不断改，熵越来越大； 2 ，没人用：完美 技术往往就是将一小木船，改为战舰，然后改为潜艇，再改为飞机，最后改为战争堡垒（堡垒中间还得来个伊甸园）。 所以通常人越少，架构越好，因为没有人力可以浪费在无关精要的功能和需求上；人少的时候很多人都能独挡一面，知道一项东西的来龙去脉，做出合理的设计，人一多就没法设计了----大家都有自己的思想。 为了兼顾大家的思想，我们设计出框架，框架解决了大部分问题，这时候有部分同学理解不够，没有跟上来， 后来分布式来了，异步来了，我们需要采用分布式的和异步的框架，但是这时候大部分同学跟不上了。。。 当然，将一首航行中的战舰改为潜艇，不是每个程序员的能掌握的。 |
 |
145
p1gd0g Nov 9, 2021
那，代码重要还是赚钱重要嘛。
|
 |
146
raptor Nov 9, 2021
大公司也一样，只是更大的屎山而已。部分外企相对好一点。看看开源代码就知道了
|
 |
147
Leee Nov 9, 2021
|
 |
148
lagoon OP @metrxqin 觉得叫屎山，也很贴切。因为就是如此，令人生理性的不适。
对于领导来说，虽然是屎山，但也是一坨好屎。但对于要处理屎山的人来说，哪怕是自己拉的屎，但也会觉得：这 TM 就是一坨屎！ |
 |
149
shawnsh Nov 9, 2021 via Android
正常了，你没发现自己就时时刻刻在屎山生存？各种社会事务中的屎山多不？各种政策屎山？
|
 |
150
alienjunx Nov 9, 2021
在前期试错的情况下，还没找到嗨点呢，不赚钱就投入大量精力优化不值得。
|
 |
151
nicholasxuu Nov 9, 2021
这时候才能显现出高级码工的意义，经历的屎山多了，能提前 n 步知道哪些形状的可能会带来严重的后果。
|
|
152
nicholasxuu Nov 9, 2021
之前工作过的公司，创始人一个周末 hack 出来的优秀功能，核心服务组 10 年后还有修它的任务，还都是严重级别的 bug 。
|
 |
153
rm0gang0rf Nov 9, 2021
知道为啥招新人吗？因为屎山需要新人来更新挖掘，因为新人更有动力挖屎
|
 |
154
300 Nov 9, 2021
|
 |
155
Vindroid Nov 9, 2021
只要业务导向的后期肯定是屎山，架构得再好也跟不上各种奇思妙想的需求
|
 |
156
mghio Nov 9, 2021
推荐 [刘未鹏]( http://mindhacks.cn) 译的一本书《修改代码的艺术》
|
 |
157
mghm Nov 9, 2021
很久很久以前，有十几年了吧，我在一家公司做网站，我们的工作是做模板站的，一般一个员工一个月能出三五个模板站就不错了，必经还要跟客户进行沟通。我们团队就有一个同事一个月能做十几个，当然一个月工资收入也很高。在一次团建中，团队领导还表扬他，让我们跟他学习，提升效率。但是，我发现一个有趣的现象，每进来一个实习的员工基本上都是在处理他的屎，提成他拿走了，也得到领导了信任了。说白了，中层领导能看不到吗？但是，领导为什么对他做的事情置若罔闻，说白了还是利益。本质上，他和领导的利益是站在一起的。
|
|
158
rm0gang0rf Nov 9, 2021
又看见了，想笑，大公司的屎山可能味道和成分比较多，有选择性
|
 |
159
matrix67 Nov 9, 2021
质量差的代码就像肿瘤，外部边界清晰的模块，是良性肿瘤，可以随时切掉。
外部边界模糊的是恶性肿瘤，无药可救，只能尽量延长生命。 是这样, 所以一个不朽的架构在诞生之初就是伟大的, e.g. UNIX, PLAN9, 而现今码农写的业务可能都是朝生夕死, 连婴儿期都没过去业务就没了. Cloud NAIVE 仿佛就是个池塘, 专门孵化孑孓. 孑孓死了直接被系统降解回收, 孑孓变成了苍蝇, 也自然不在池子里再部署了. 我们 Cloud NAIVE 程序员别说领域驱动设计了, 连设计模式早都不用了. 面向啥切面搞, 微服务重写一遍都比想个设计模式快. FAAS 才是未来 |
 |
160
lockelee Nov 9, 2021
我们不生产屎山，我们选择屎上雕花
|
 |
161
zhuangzhuang1988 Nov 9, 2021
有人的地方就有江湖
|
 |
162
yuruizhe Nov 9, 2021
自信点，去掉“感觉”和“中小”
|
 |
163
lithium4010 Nov 9, 2021
重构还是要写测试的
|
|
164
lithium4010 Nov 9, 2021
抓新人去重构写测试还能快速上手
|
 |
165
rudder Nov 9, 2021
大小公司都一样，还是程序员的问题。有的人改 bug 或加新需求不会去读老代码。最后也没人负责 review ，到后边越来越屎
|
 |
167
z1113456051 Nov 9, 2021
不动绝对不会有事。
|
 |
168
cizixs Nov 9, 2021
有哪些做法可以预防或者减少屎山呢？
|
 |
170
fuermosi777 Nov 10, 2021
这是一个系统性问题，一个解决办法是分割服务，把屎控制在可冲范围内。
|
 |
171
SteinsGate Nov 10, 2021 via Android
因为每个人想法不同，水平不同，你眼里的好代码在别人看来可能就是💩
|
 |
172
rayw0ng Nov 10, 2021
@metrxqin 国外叫 `shit code` https://shitcode.net/ ， 委婉点的叫 `code smell` 或者 `bad smell`。
|
 |
173
windsound Nov 10, 2021
唉，当初看着屎山，也想着，改是改不动了，那就争取不添吧。后来忙起来，赶需求，想想还是算了吧，这么紧的时间，先上了再说。于是乎... ...
|
 |
174
flyn Nov 10, 2021
“屎山代码” 用英文怎么说？
|
 |
175
fakeshadow Nov 10, 2021
网友们纷纷对着屎山发出感概，全然忘记了自己也是拉屎的
|
 |
176
Myprajna Nov 12, 2021
所以个人独立开发者会好点吗？产品，设计，代码都是同一个人做的。
|
Select Language