第一个版本：

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

后期迭代：

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

重构：

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

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

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

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

中小公司：

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

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

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

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

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

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

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

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

大公司也很难不写出来。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相对来说小公司的屎山更好解决一些，因为业务复杂度也许没那么高，输入输出场景也更单一一些
大厂大项目中的屎山，那业务复杂度你很有可能都吃不透，更别想重构了…
之前接手过一个老人的项目，服务端用了 4 种语言：PHP+Python+Go+Lua ，加起来得有差不多 2w 行代码，重构个锤子重构… 能勉强看懂这一坨并且能往前推一推就很不错了…

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

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

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

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

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

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

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

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

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

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

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

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

转载请注明：落伍老站长 » 感觉在中小公司，很难不写出屎山代码