感觉在中小公司，很难不写出屎山代码

[lagoon]

第一个版本：

中小公司，一般第一个版本，都是赶工上架，以我的感受，基本都是没需求、没计划、没测试（测试没时间，只能随便试试）、领导马上就要，必须上线的状态。
导致第一个版本，无论如何都是屎山。很难不想着“赶紧先交差”。

后期迭代：

基础是屎山，屎山上加盖的建筑，很难不是屎山。

重构：

我的领悟是，小重构可以，绝对不要大重构。
除非领导要求，但领导能用就行，管 bug 、管功能、很少会管代码是不是屎山。

测试也是人，如果是新事物，比较容易认真测，如果是反复测试过的模块，很难用心测。码农也是人，新功能、新模块、思路清晰。大重构很容易大刀阔斧。

重构很容易重构出许多奇妙的、不易发觉的 bug 。写反而不会写出这样的 bug 。

如果是小重构，屎山代码，靠着小重构，根本无法应对下一波来屎（一年总是能遇到几次马上就要）

中小公司：

考虑到大家的水平比较高，我说的中小公司可能等于大家眼中的小公司。
目前呆过的互联网公司规模最大的 300+人，呆过的传统上市公司规模最大的 2000+人。

[fanyingmao]

大小厂都一样，而且大厂可能因为项目历史长，而叠出更高的屎山。

[m102]

大厂也是如此。
曾供职于某业内前三大厂。
该厂某产品是 A 语言的开源框架基础上进行二次开发。
多轮迭代后硬生生的二开成了 B 语言。非常残暴。。。

[lap510200]

上市了也是 需求变来变去 时间进度又不延期 为了赶工很难写出优雅的代码，而且经常岗位职责变动做其他事，接手的人的水平很难保证

[loveuqian]

@yyysuo #37 是什么让你产生了 iOS 的代码会好点的错觉 🙀

[Anajiuzheyang]

现在天天写屎一样的代码，经常一个事情给一点点时间 赶着上线 然后要求能跑就好 上线后各种奇葩需求又来了又一点点时间 只能用最快的方式去解决 然后在屎山上叠屎 然后就是一座更高的屎山。

[duduaba]

所有公司有这样的，而且还很多。对，所有。

[onlyForward]

大公司的屎山比小公司要大得多,只有纯技术导向公司会稍微好一点

[charlie21]

因为水平烂阿，还能因为什么？水平好的呢可以在工期紧 任务重 急忙上线 钱少时间紧的情况下，依然坚持不产出 shit 代码

[xuanbg]

只要是开发团队对业务的理解不够深入的，开发出来的产品就必然是屎山。因为从设计层面就错了，和代码水平反而没多大关系。

[leo108]

借楼打个广告，我司有非常严格的 code review 流程，最近后端团队安排了 3 个月时间的代码质量专项训练，大到架构设计，小到变量命名。

我们在工作时有一项原则：『自己多思考，让同事少思考』。我们希望构建一个让工程师写起代码很舒服的项目环境。

招聘贴见 https://www.v2ex.com/t/795579

[Cloutain]

Oracle 传说是屎山之王
Windows 下很多应用层的管理器是屎山，包括 IE 。NT 内核还是不错的相对来说好得多

[decken]

只要不赶时间 + 有颗不断追求完美的心 在大小公司都可以让屎山更矮一点

[ww2000e]

都是那波人写的那波代码。。

[levelworm]

@wellsc 老的那个还好吧

[xw]

能用就行 /

[leeyom]

换工作其实就是从一个坑换到另外一个坑，坑其实都是💩山

[jsjgjbzhang]

先完成在完美，完成之后在看这个产品是否值得完美

[watzds]

哈哈，大公司的大，堆得更高😄

[youyang]

@RubyJack 兄弟，agree no more

[a852695]

大公司的屎山可能更大，只是有人有经费去维持和改善而已

[a852695]

先把业务堆上线，看看外面用户反馈如何，至于什么重构优化，再说吧，大公司忙点的项目连周末都很难保证，更没有太多时间去做优化了，能把需求做完堆上线都算庆幸了。呆过 2 个大厂，大部门业务技术部门都这样，等上线了不行的话更没有人去维护了。

[liuzhiyong]

我在中小公司，领导对代码要求特别严格，一个空格都要管。

[iSteven]

@cubecube 说得太对了

[pengtdyd]

开源项目都是这样，开源项目代码优秀的也是凤毛麟角

[sgissb1]

谁告诉你的大公司就没有 sh!t 山，而且 sh ！ t 山就不多的？认知偏差有点大啊

[kingfalse]

都一样，大厂也一样，全国 996 的风气能出什么好代码

[shayuvpn0001]

@klarkzh 飞机火箭的代码里面屎也多，不过会用各种方法把这些屎尽量隔离开来，只要他们不聚集在一起，整体就不会出大的问题。由此还诞生了一个著名的安全管理模型：Swiss cheese model

[shyangs]

澳洲航空 72 號班機事故
電傳系統軟體錯誤
空中浩劫.S18E07.FreeFall

[mapoor]

不可否认，随着时间的推移，质量再高的代码也会被下线。
软件工程师生产代码其实就是在传递价值。

大公司的工程师更倾向于花大量时间在软件设计，代码组织上。因为只有这样才能传递更多的价值给用户。
小公司的工程师则更倾向于在有限时间内产出更多的可运行软件。毕竟小公司死的速度太快了，工程师当然需要尽快地传递价值。
那么请思考下：一个没有任何人使用的软件，那这个软件算存在吗？ 那写这个软件的人那段时间存在吗？

[reedthink]

功能是资产，代码是债务，你猜猜为啥叫债务

[majula]

大厂也不怎么样。最近刚入职国内互联网前三名的某大厂的大数据部门，接手了某基础设施的代码。

那代码真是一言难尽。说实话，质量还不如开源玩具的平均水平。

据说写这代码的人还是部门老大高薪从 facebook 拉过来的。很难想象他是怎么进来的，也不难理解他为什么半年就离职了。

[bclerdx]

@cubecube 说的太对了。领导就是为了赶时间、赶进度，好拿到钱到自己的腰包。

[jessun1990]

盲猜 window 10/11 的代码也有类似的情况。

我觉得没有 shi 山写法的代码反而不正常，太简单了，感觉反而可能不太适应生产环境。

这个世界本身就是多样复杂的，都是带着 bug 运行着的。

[ClericPy]

面试造火箭
上线用导弹
最离谱的是, 知道是导弹还要做载人航天

已经无力反抗

[AyaseEri]

不要害怕屎山，要勇于构建屎山。直到这坨 shit 不得不重构的时候，你就有时间码一座更香的屎山了。

[zerofancy]

重构提技术需求，出文档，走测试。

[walpurgis]

写屎山是程序员练级的必经之路，这个没办法，现在回头看几年前写的代码都不忍直视，就是单纯功力不够，想获得进步还是先找自身原因，然后才是外部原因

[imycc]

有点点强迫症，自认为是对自己代码比较负责的，之前也给项目内的同事做过 code review 。总体感受就是，shit 山是无法避免的。

追求完美是不现实的。代码开发是要解决实际问题，而需求是不断变动的。你无法预测到两三年后的功能需求，打补丁是在所难免的。
你无法保证自己每一段代码都是“完美的”，你也无法保证每个同事都对自己有高要求。即使你能保证自己的设计思路一致，别人再接手的时候，也不能再次还原你的想法。时间久了就夹杂着每代开发不同的“想法”在里面了。

反正我已经看开了。之前卡同事的代码卡得比较严。现在只要别歪得太离谱，我会先给过。
搞 code review 是累活，不少团队 leader 嘴上说着要有追求，要规范 blahblahblah ，等到评绩效的时候就对你的付出视而不见。
我会尽量保持对自己的要求，跟同样有兴趣的同事交流。至于其他人，我真的管不着了

[mapoor]

@mapoor 补充下，软件工程师最大化传递价值的方式，我认为就是开源。

[danhahaha]

这篇帖子含屎量很高

[hjq632233317]

事实是， 时间就是金钱 ，我的 baby ， 怎么算不是屎山， 你认为干净整洁的代码就可以迎合新的需求了么 ，谁能在做的时候想到新的需求是什么样的， 并且为新的需求留出扩展空间

[simo]

正在经历自己堆屎山的过程，需求一天 8 改，一个月推翻重来一次，技术团队临时拼凑（大家没有上下级，都是民工身份），开始我还做些架构，定一些规范给大家推荐一下，但是，两个月以后，只能尽力保证自己的粑粑香一点。。。。

[simo]

怎么感觉跟楼主在一个团队呢

[encro]

代码也有两种：
1 ，有人用：BUG 很多，不断改，熵越来越大；
2 ，没人用：完美

技术往往就是将一小木船，改为战舰，然后改为潜艇，再改为飞机，最后改为战争堡垒（堡垒中间还得来个伊甸园）。

所以通常人越少，架构越好，因为没有人力可以浪费在无关精要的功能和需求上；人少的时候很多人都能独挡一面，知道一项东西的来龙去脉，做出合理的设计，人一多就没法设计了----大家都有自己的思想。

为了兼顾大家的思想，我们设计出框架，框架解决了大部分问题，这时候有部分同学理解不够，没有跟上来，

后来分布式来了，异步来了，我们需要采用分布式的和异步的框架，但是这时候大部分同学跟不上了。。。

当然，将一首航行中的战舰改为潜艇，不是每个程序员的能掌握的。

[p1gd0g]

那，代码重要还是赚钱重要嘛。

[raptor]

大公司也一样，只是更大的屎山而已。部分外企相对好一点。看看开源代码就知道了

[Leee]

哈哈哈这个帖子好搞笑🤣🤣🤣

@metrxqin
其实我觉得这个帖子的“屎山”可能跟 legacy code 是不一样的东西吧。。

然后我现在想把这个帖子告诉我的朋友但是都不知怎么翻译哈哈哈哈哈

[lagoon]

@metrxqin 觉得叫屎山，也很贴切。因为就是如此，令人生理性的不适。
对于领导来说，虽然是屎山，但也是一坨好屎。但对于要处理屎山的人来说，哪怕是自己拉的屎，但也会觉得：这 TM 就是一坨屎！

[shawnsh]

正常了，你没发现自己就时时刻刻在屎山生存？各种社会事务中的屎山多不？各种政策屎山？

[alienjunx]

在前期试错的情况下，还没找到嗨点呢，不赚钱就投入大量精力优化不值得。

[nicholasxuu]

这时候才能显现出高级码工的意义，经历的屎山多了，能提前 n 步知道哪些形状的可能会带来严重的后果。

[nicholasxuu]

之前工作过的公司，创始人一个周末 hack 出来的优秀功能，核心服务组 10 年后还有修它的任务，还都是严重级别的 bug 。

[rm0gang0rf]

知道为啥招新人吗？因为屎山需要新人来更新挖掘，因为新人更有动力挖屎

[winterbells]

@cubecube #13 说得对

在上家时候，弱智队友留一堆 bug 下班了。老板一看哟，能用了，真不错。什么？ crash 了。发现我在就让我改，我 TM 自己正准备下班呢。最后糊弄一下能跑就行了

[Vindroid]

只要业务导向的后期肯定是屎山，架构得再好也跟不上各种奇思妙想的需求

[mghio]

推荐 [刘未鹏]( http://mindhacks.cn) 译的一本书《修改代码的艺术》

[mghm]

很久很久以前，有十几年了吧，我在一家公司做网站，我们的工作是做模板站的，一般一个员工一个月能出三五个模板站就不错了，必经还要跟客户进行沟通。我们团队就有一个同事一个月能做十几个，当然一个月工资收入也很高。在一次团建中，团队领导还表扬他，让我们跟他学习，提升效率。但是，我发现一个有趣的现象，每进来一个实习的员工基本上都是在处理他的屎，提成他拿走了，也得到领导了信任了。说白了，中层领导能看不到吗？但是，领导为什么对他做的事情置若罔闻，说白了还是利益。本质上，他和领导的利益是站在一起的。

[rm0gang0rf]

又看见了，想笑，大公司的屎山可能味道和成分比较多，有选择性

[matrix67]

质量差的代码就像肿瘤，外部边界清晰的模块，是良性肿瘤，可以随时切掉。
外部边界模糊的是恶性肿瘤，无药可救，只能尽量延长生命。

是这样, 所以一个不朽的架构在诞生之初就是伟大的, e.g. UNIX, PLAN9, 而现今码农写的业务可能都是朝生夕死, 连婴儿期都没过去业务就没了. Cloud NAIVE 仿佛就是个池塘, 专门孵化孑孓. 孑孓死了直接被系统降解回收, 孑孓变成了苍蝇, 也自然不在池子里再部署了.

我们 Cloud NAIVE 程序员别说领域驱动设计了, 连设计模式早都不用了. 面向啥切面搞, 微服务重写一遍都比想个设计模式快. FAAS 才是未来

[lockelee]

我们不生产屎山，我们选择屎上雕花

[zhuangzhuang1988]

有人的地方就有江湖

[yuruizhe]

自信点，去掉“感觉”和“中小”

[lithium4010]

重构还是要写测试的

[lithium4010]

抓新人去重构写测试还能快速上手

[rudder]

大小公司都一样，还是程序员的问题。有的人改 bug 或加新需求不会去读老代码。最后也没人负责 review ，到后边越来越屎

[zhuzhibin]

@nash 牛呀，估计又要开始 battle 大战了

[z1113456051]

不动绝对不会有事。

[cizixs]

有哪些做法可以预防或者减少屎山呢？

[RiceMarch]

@cubecube 太真实了...

[fuermosi777]

这是一个系统性问题，一个解决办法是分割服务，把屎控制在可冲范围内。

[SteinsGate]

因为每个人想法不同，水平不同，你眼里的好代码在别人看来可能就是💩

[rayw0ng]

@metrxqin 国外叫 `shit code` https://shitcode.net/ ， 委婉点的叫 `code smell` 或者 `bad smell`。

[godwinma]

唉，当初看着屎山，也想着，改是改不动了，那就争取不添吧。后来忙起来，赶需求，想想还是算了吧，这么紧的时间，先上了再说。于是乎... ...

[flyn]

“屎山代码” 用英文怎么说？

[fakeshadow]

网友们纷纷对着屎山发出感概，全然忘记了自己也是拉屎的

[Myprajna]

所以个人独立开发者会好点吗？产品，设计，代码都是同一个人做的。