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

[lagoon]

第一个版本：

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

后期迭代：

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

重构：

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

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

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

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

中小公司：

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

[harde]

我会告诉你上市公司也是这样么

[JavaFirstMaster]

想多了, 大公司也是这样, 而且可能会更臭

[iClass]

粪土中容易培养好苗苗

[q447643445]

时间久了 现在的想法是能用就行,管它是不是屎山的

[chaosjohn]

大公司更甚

[wellsc]

微软够大吧？ windows 的文件管理器就是一坨屎山代码

[crazyhorse]

看一下国内各大厂开放平台的 SDK 代码和 API 规划 一样是屎山

[chendy]

屎山从来不看公司规模不看国内国外
中小公司是屎山，大公司是屎山脉
其实不止软件行业，制造业也有很多产品，看着像那回事，里面其实也一堆坑

[aababc]

大部分的都是表面光，各种个样的的历史遗留，各种个样的突破规范和魔改。

[virus94]

+1,我司就是屎中屎

[abigeater]

确实。第一版为了赶工 怎么省事怎么来。
现在有问题回头去看，想重写但又怕重新写出问题。
但因为领导在写第一版的时候说以后有时间再重写，现在已经慢慢重构一些地方

[cubecube]

大公司也很难不写出来。

国内公司的现状就是，大部分所谓的领导根本不清楚具体的方案难易程度，无法准确的考核工作成绩。

说个例子，一个对自己代码质量要求非常高的人，经常做需求的时候，设计思考设计原型的时间超过 60%，交付质量非常高，很少有比较严重的 bug 。
另外有一些人，干活毛毛糙糙，思维相对简单，干活急急冲冲而半灌水，出活猛操快，上线后各种问题，又猛操快的去解决自己埋的哪些问题。
虽然，最终，第一种人，整体更高效，但是一来一回，第二类人，第一版交付更早，领导觉得第二类人解决了众多的问题，工作量特别大，特别辛苦，年终考核都是第二类更佳

那第一类人何苦自己想那么多，埋屎谁不会

[itbeihe]

范围小了，去掉中小。大公司也这样，尤其是跑了好几年的 N 手代码。

[SeanChense]

打破你的思维误区，大公司更是屎山，屎的程度甚至超过你想象

[yyfearth]

大公司也一样
只要是产品主导 一定是各种赶鸭子

[onlyhuiyi]

感觉原因还是在于面向 money 编程

[ymmud]

想多了，包括很多大公司，甚至是金融类的应用一样是屎山。

[LowBi]

急着要，又没有天才开发者的大脑，能考虑到长远的未来，也只能写这种代码了呀

[Leonard]

只要公司项目功能足够复杂，屎山很难避免

[expkzb]

有人的地方就有屎山

[xwayway]

流程不规范的话，每个公司都一样。另外项目最一开始就写好单元测试，重构的时候你就知道单元测试有多重要了

[chiuan]

你这样理解是错误的.....屎不屎主要还是看写的人

[lingxi27]

个人经验，大公司的屎山更臭更难处理

[huangmingyou]

我的工作就是让屎山不崩。

[xwayway]

@xwayway 另外你还需要有一个足够刚的技术领导，把业务方不合理的需求都怼回去。一个功能最开始做的目标就是能实现目的就行了，不要想做得多复杂，多人性化，后期再慢慢加，不然一开始就做得大而全，很多东西根本用不上，徒增代码复杂性。

[zhanggg]

其实压根和公司没关系，看公司中高层对码代码这个事情的认知态度
如果领导面向业绩、成果管理，代码好不好看，干不干净，是不是屎山这并不是首要考虑目标，考虑长远？笑话
“东西都还没做出来你考虑那么长远干啥？”

[MuSeCanYang]

大公司也是一样的

[Mark24]

跟公司没关系。

跟人有关系

梦之队都是十几年有默契的团队。


现在哪个公司不是 人员流动的厉害。

你可以参考下装修队伍的现状，都是临时工的感觉。做出来的东西能有什么指望。

[Zien]

大公司最多某些比较边缘的新产品中新模块规范点吧。
毕竟跟风业务、紧急政策、领导拍脑袋什么的优先级最高。

[amundsen]

很多大厂一样的

[icyalala]

大公司屎山之大，超乎你想象。大公司，特别是业务做了很久的大公司，很难没屎山。

[beipiao]

完美的项目：完成开发：重构的时间=1：4

[sakura1]

大公司更多

[hash]

很多公司的屎山代码还没展现出后果的之前,公司就死了.

[coolmint]

我们公司就这样，一模一样，开发十来个人吧。
小功能做到最后一天，测试随便点点，做了两周这种大功能，给测试两三天吧。哈哈哈

[yyysuo]

大厂小厂都一样吧，古今中外都一样，各行各业都一样吧。局部出现不屎山的情况才是意外。我很好奇，IOS 的代码会不会好一些。

[libook]

中小公司代码质量是和技术人员的能力有关的。
大公司有各种标准、制度，拿自由换取风险的降低而已，以及有钱堆人力来收拾屎山。

[cxe2v]

屎山不屎山，能产生实际价值的就是好山

写出一堆无比华丽优雅的代码，然后没产生一点实际价值，这不比屎山更没用

[xuhaoyangx]

@cubecube #13 正解啊。

这些领导巴不得，功能快快上，什么还要设计？难道不是边写边设计？

[windyCity1]

靠自觉很难，经历这么多公司，觉得有没有 codeReview 很重要，有代码审核制度会好很多

[28Sv0ngQfIE7Yloe]

大公司也不是所有组都干一个工作啊。。你把小公司类比成大公司的项目组就好了，有的大厂项目组写的也是一坨屎

[ily433664]

大公司也一样啊，微信小程序的接口返回参数还有 openid 和 openId 呢

[windyCity1]

@cubecube #13 线上出现很多问题，不影响绩效吗。。。。。

[ihipop]

国产大公司也这样，阿里也有屎山,看淘宝 top 的那个 php sdk 就知道了，公开的代码尚且那样。。

[zjsxwc]

推荐一本老书
https://gitee.com/zjsxwc/image-bed/raw/master/v2ex/DeepinScreenshot_select-area_20211108120147.png

[cubecube]

@windyCity1 更多的时候是问题，又不是导致严重生产事故的重大问题那种。比如性能很差，部分逻辑条件边界没处理完善之类的。
比如换个说辞，就是此需求导致性能压力巨大，处理逻辑异常复杂，需要进一步性能优化及流程优化，然后 xxxx 一阵搞，一个月后，第二、三个连带优化需求上线。

拉屎的赢两次

[auh]

当屎是一个问题的时候，他就很可能存在合理性。当合理的时候，屎又不是问题了。这怎么解释？

认知和态度决定一切。

[onikage]

我司(6000 多人)也是这样, 我一开始也是和楼上各位一样的想法. 每次需求变动改到吐血, bug 也多, 想花时间重构一下, 甚至自己加班重构, 但是领导不关心, 领导关心的是怎样把屎山卖出来钱, 以及你是否加班去改屎山了.
最近说实话, 我的认知发生了一些变化, 居然有点认可这种做法了. 虽然还在写代码, 但是也没以前那么吹毛求疵了, 差不多就行了, 卖出来钱, 年底有奖金就好, 省点时间回家陪陪老婆孩子. 可能是老了吧...

[waterlaw]

参见 程序员的酒后吐真言 http://www.ruanyifeng.com/blog/2021/06/drunk-post-of-a-programmer.html

[waterlaw]

酒后吐真言第 28 条
（ 28 ）人死了以后，你想让代码成为你的遗产吗？如果是那样，就花很多时间在代码上面吧，因为那是你的遗产。但是，如果你像我一样，更看重与家人、朋友和生活中其他人相处的时光，而不是写的代码，那就别对它太在意。

[vanton]

大公司屎山更可怕

[Junzhou]

讲讲我的体会，感觉主要还是历史遗留问题（工期，业务增长，业务变更），根本没法动这些代码，只能在需求迭代时逐步小范围的重构。

小公司很多项目演进的过程就是一个试错的过程，很多时候经验不足，项目启动时各种设计不是那么的合理，都会随着业务增长暴露出来， 但是只要能跑，能够缝缝补补，大概率不会选择重构，第一个是时间上不允许，第二个动这块代码会引入更大的风险，这部分代码在不断缝缝补补的过程中，已经面目全非了，文档不全或者注释不全的话，动起来真的是战战兢兢。

很显然，如果盈利不行或者没有技术驱动，基本不会选择重构，重构的风险太大了，说白了，你动这块代码，就不可避免的引入风险，有时候重构可不是重构一个方法，你要重构一个业务流程和基础逻辑，这个工作量很大的，要是没测试，没有历史变更文档，不出问题那才叫奇怪。

[fl2d]

一些复杂算法，调通以后，经常我自己都看不懂了。我基以确定，别人也看不懂。

[fan123199]

都是屎山，解决屎山必然的结果就是出生产 bug 。再修复个几轮 bug ，就会会好很多。然而紧急项目一来，继续堆屎。不过这个新的屎会香一些。

问题来了，出 bug 是要扣钱挨骂的。

[gengchun]

说起在各位有多少人看过《人月神话》的？

看了这个贴，我打算看一下。

[hxy100]

有 review 总比没有 review 好，有的小公司代码直接都没有 review 环节的。

[metrxqin]

不理解 “屎山” 这个叫法怎么流行起来的，国外叫 legacy 怎么翻译过来变得如此的恶俗？ 显然 legacy code 是有价值的，但是为什么要冠以 屎山的称号？ 好像一文不值一样？

[xnotepad]

只要不是开源的代码，都会变成屎山。

[salmon5]

自己拉的屎山，又何妨？
最怕的是别人拉的屎山，要你吃；
最最怕的是别人拉的屎山（在职，活的好好的），要你吃；
最最最怕的是别人拉的屎山（在职，活的好好的），要你吃（你还要被迫说：真香！）

[MiniGhost]

相对来说小公司的屎山更好解决一些，因为业务复杂度也许没那么高，输入输出场景也更单一一些

大厂大项目中的屎山，那业务复杂度你很有可能都吃不透，更别想重构了...


之前接手过一个老人的项目，服务端用了 4 种语言：PHP+Python+Go+Lua ，加起来得有差不多 2w 行代码，重构个锤子重构... 能勉强看懂这一坨并且能往前推一推就很不错了...

[jasonchen168]

@yyysuo iOS 有啥特别的地方？一样的屎山啊。。。

[2i2Re2PLMaDnghL]

一
根据简单的「热力学第二定律」
将一堆代码视为封闭系统的话，屎山代码不会自发地变成不屎山的代码，但不屎山的代码会自发地变成屎山代码
这叫做屎增定律。
因此，必须采用开放系统自外部输入自由能才能达到屎减，也就是说需要程序员对代码做功。

二
但如果把程序员的心智和代码再视为一个封闭系统，你会发现，程序员对代码做功把屎山代码变成不屎山的代码其实是把屎铲进自己脑壳里去，屎的总量还是没有减少
仍然符合屎增定律
因此，必须需要时刻添加新程序员来装屎。

三
但程序员们总喜欢产生新的代码，这会导致代码越来越多，从而导致屎增速度也越来越快，所以就需要追加更多的新程序员来装屎。
所以可以论证，一个能够维持存在的软件公司必定是在膨胀的。

四
但是膨胀不是无极限的。即使把装满了屎的程序员请出去，上述过程仍然以几何级数增长，从而导致最后公司无法维持那么多的程序员存在，结局就是化粪池爆炸。

五
当然，第三条是有例外的，那就是时不时地把一些代码也切割出去。
这就是 Google 一直在关停项目的必然逻辑根源。

[ilxv]

根本还是人的问题，不是规模的问题

[xz410236056]

“测试也是人，如果是新事物，比较容易认真测，如果是反复测试过的模块，很难用心测。”
所以有个东西叫测试用例啊，每次发版本所有用例走一遍

[supuwoerc]

我见过一个我司 NLP 的工程里面集成了钉钉和讯飞的 SDK ，还对外可以支持 web 以及云调用，然后前端的页面部分用 Angular ，部分 Vue ，部分 React ，README 没人维护，注释看了眼来自四个团队长达 6 年的代码，各种分支和冗余代码，真是庞大的屎山，可以说是喜马拉雅的规模了。

[0xZhangKe]

大公司只是让屎山变得更大了。

[FsL4V3Y8pTLe6qyc]

实话告诉你，大公司的是更大更大更大的屎山，说话不该说的，假如换位思考下，你坐到了你领导那个位置上，这些根本不是最重要

[4771314]

人和代码，有一个能跑就行

[Huelse]

你这视角还是局限了，到哪都能写出屎一样的代码的

[aladdinding]

最可气的是。自己花时间重构后又被改成了屎山

[dfkjgklfdjg]

不不不，就算你在最开始的时候觉得是完美架构了，
过了一年回过头来看还是会觉得自己写了屎山，就 TMD 想重构它。

而且会有一些坑你最开始预留了，后续需求被砍了，这个坑就一直在哪里了。

[florianX]

有个模块权限功能临时表创建的 sql create select 是写死的，mysql 启用 GTID 后不支持这种写法，组长让我改成先 create ，再 insert 的方式。因为不好确定临时表结构，我就用 select sql 语句解析下确定表结构 并做成了一个公共方法可以解析不同的 select sql 的字段和数据类型，很快测试完毕没毛病。
然后魔幻来了，我的组长说，你这样写太复杂了，不直观，让我直接把字段写死。。。我说不同的临时表表结构不同，每个写死后期如果源表结构或者业务逻辑发生变化手动改很麻烦，而却容易出错。。。他说就按他的来，理由是这样能少执行一条 sql 。。
我被恶心到了，sql 不长表也不大，个人觉得多执行一条对运行速度没有影响，而且既然交给我的活儿，都不信任我做？我都测试完成了，非要按照他的思路再改一遍，还不好改因为写死字段得一个个比对。很难受！

暂且不说让我多干活儿这个事儿，就觉着这种在代码中写死字段名的方式，我实在想不通到底有什么好的。。这些老代码本来就很屎了，硬是让我拉了一坨。。。唉！无奈

[mouxinzi]

差的模块问题多多.解决的过程被人各种恭维.夸赞.让平稳运行模块的心里膈应的不行..

[zzfer]

感觉主要还是看技术总监。之前在一家小公司里，技术总监要求代码很严格，项目很标准，看起来很美观，注释都写好，命名全部规范。后来去了大公司，反而没那么规范，也就是你们说的屎山

[daguaochengtang]

《能跑就行》
《要啥自行车》

[mxT52CRuqR6o5]

大公司一样会有屎山+1 ，甚至是更大的屎山，只不过是大公司有方法论和更靠谱的人能 hold 住更大的屎山

[FaXiaoKe]

那我一直在屎中穿行，刚开始前两年还试图重构，现在是万💩丛中过，片💩不沾身。

[BiChengfei]

300+ 人的互联网公司已经不算小了

[lamesbond]

又不是不能用

[liubaicai]

大小公司都呆过，大公司真的是大屎山，小公司是小屎山，没啥区别

[timedivision]

80 条回复，一共 88 个屎字

[klarkzh]

我现在比较好奇，控制飞机火箭运行的代码里面屎多不多

[leon0918]

重构还是要的，按照科学流程来。之前花了很久重构了一个大模块，算上奖金晋升等七七八八的收益有 100 多 w 。

[ffffb]

@klarkzh 这个世界都是草台班子搭建出来的。只要涉及大量人力的工作，我猜都没有本质区别

[3dwelcome]

@waterlaw “（ 28 ）人死了以后，你想让代码成为你的遗产吗？如果是那样，就花很多时间在代码上面吧，因为那是你的遗产。但是，如果你像我一样，更看重与家人、朋友和生活中其他人相处的时光，而不是写的代码，那就别对它太在意。”

可生而为人，好不容易来世间一次，我还是想留下一点点什么，哪怕代码也是好的。

[hqs0417]

不用吐槽别人，先把自己的代码写好吧，多写出容易阅读的代码。

[cyrivlclth]

中小公司是屎山，大公司就是屎海屎星了

[blessyou]

荆棘里种花 🌝🌝

[yiios]

@klarkzh 阿波罗登月的代码是开源的，就是 TM 看不懂

[jiayong2793]

国内所有企业都是这样，要么假大空不能落地，要么经常改，最常见的就是做到后面钱不够、时间不够，各种裁剪需求妥协上线，然后一堆问题

[hereIsChen]

需求一层层加，而且还会来回变动
结果就变得越来越复杂

[weidaizi]

只要是在公司里写的代码，很难在规模扩大以及多人合作的情况下不出现混乱的代码。想起曾经的老梗: 让为客机开发控制系统的程序员去乘坐跑着自己程序的飞机，其中有 80%的人觉得不安全而选择不去，还有 20%的人欣然前往，因为他们心里很清楚这玩意压根飞不起来

[zi]

没需求才最要命，开个会放一下 PPT ，所有功能请自由发挥…

[uiosun]

@2i2Re2PLMaDnghL 建议大佬牵头研究“沼气”相关的生物科技，使这一循环更加有机 🥳

[DrJoseph]

相同的公司不同的业务的代码质量也差很多，跟业务本身的重要性有关，跟 TL 对 CR 的态度有关系，也跟我们自身对代码规范的重视程度有关

[nash]

可能跟语言也有关系，像 PHP 这种可以自由发挥的语言更容易屎，像 JAVA 这种工业级别的就算屎也屎不到哪里去。。。

[linora]

所谓敏捷开发，哈哈！！！！！！

[cstj0505]

@cubecube
> 经常做需求的时候，设计思考设计原型的时间超过 60%

以前我也很诧异这个问题，后来发现现实是时间不等人，有项目来了，乌央乌央把几十号人都召集过来，规划，思考？不存在的，让十几几十号人等着设计，不可能的。谁让老板只看工期和结果呢，质量往后排。

[RubyJack]

可悲的事，大厂也不重视代码质量