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

[lagoon]

第一个版本：

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

后期迭代：

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

重构：

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

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

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

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

中小公司：

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

[MiniGhost]

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

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


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

[jasonchen168]

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

[2i2Re2PLMaDnghL]

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

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

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

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

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

[ilxv]

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

[xz410236056]

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

[supuwoerc]

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

[0xZhangKe]

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

[sxox]

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

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

又不是不能用