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

[lagoon]

第一个版本：

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

后期迭代：

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

重构：

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

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

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

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

中小公司：

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

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

这篇帖子含屎量很高