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

[lagoon]

第一个版本：

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

后期迭代：

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

重构：

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

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

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

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

中小公司：

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

[windyCity1]

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

[Morii]

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

[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]

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