今天在知乎上看到一个话题：
“腾讯阿里这样的大厂代码会写成屎山吗？
先来认识一下“代码屎山”
代码屎山，其学名为“技术债务”，往往是一些祖传的代码，它们的结构混乱、难以维护、功能重复、缺乏注释。
一听到代码屎山，我们每一个程序员都对其恨之入骨，特别是当你整晚整晚地在代码屎山中定位bug、处理bug时，这种咬牙切齿的痛，只有经历过的人才能体会。
很多初出茅庐的新手程序员，一开始抱着满腔的热血要重写这些“屎山代码”，但现实往往是这样的……
大刀阔斧一顿操作后，结果又或者是这样的……
亚马逊的工程师曾这样形容他们的代码：“一座很大的屎山，你见过的最大的山，每次你想修复一个bug，你的工作就是爬到屎山的正中心去”。
所以业界有一条铁律：一个软件只要能够稳定运行，千万别去重构它，哪怕里面的代码写得再烂。
我们组有一个著名的5000行后端JS代码，没有面向对象封装，更没有良好的设计模式应用，纯靠几十个函数的互相调用。其中有好几个上千行的函数，带了二十多个形参，几个标志位，还有十几个乱七八糟的枚举值。至于注释？没有的，想要读懂代码多半得靠猜。
每一个接手过这段代码的人都会不约而同的发一条朋友圈以示佩服。
但神奇的是，代码在执行上基本没太多的问题。
直到几个月前，一个大牛在离职之前把这段代码全部重写了一遍，留下了至今都没有改完的bug。
大厂才是代码屎山的发源地
说了你别不信，只有大厂才可能有屎山代码，为什么这么说？
一方面小厂人少，就算写得再屎，也堆不成山。
而且大部分小厂的产品都活不过3、5年，堆成山的时间基数也不够。
我有个同学，前年刚从阿里离职，他们当时维护的系统差不多就是这种屎山级的代码，而且还是核心系统。
系统代码总量200万行，本地根本运行不起来，每次开发调试都只能在测试环境搞。
加一行日志，就得提交到CI上构建，至少20分钟，每次线上有bug，全部回滚都得至少40分钟。
而且系统用的都是集团内好多年没人维护的框架，真不敢想如果出了bug谁来背锅。
因为代码量太大，很多都是好多年前的前前前同事写的，压根没有单元测试。所以就导致了代码就算不规范，你也不敢改，因为只要你改了，所有的单元测试就得你补上。本来就天天加班，谁还愿意再给自己加餐呢？
还有，他们曾经做过的一个开发任务是给一个已经有250个字段的mysql表再增加100个扩展字段。
疯了吗？为啥要提前加这么多扩展字段呢？
因为这个表太大了，做了分库分表，总共的数据大小是5个多T，分表数量是16*1024，加一个字段就得两天，所以呢为了方便这个表后期继续扩展，就有了这个开发任务。
怎么样，很牛逼吧？
再来说说腾讯。据说QQ空间的代码已经重构过了，为什么要重构呢？还不是因为想在原来的代码屎山上迭代业务已经搞不动了。
有一篇介绍QQ空间技术重构的文章这样说道：
“QQ空间是一个祖上很阔的业务，代码量非常庞大，超150w行。由于代码频繁地交接和多团队的协同开发，空间的代码逐渐劣化，各项代码质量的指标几乎都在QQ产品中垫底。
代码的劣化导致历史 bug 难以收敛，即使一行代码不改，每个版本也会新增历史 bug30+。
面对如此庞大的历史债务，QQ空间已经到了寸步难行，不破不立的地步，重构势在必行。所以，借着空间 UI 升级的契机，空间团队开始空间历史上最大规模的一次重构。
由此可见，这些庞大的技术债务，往往由这些大厂产生，而且大部分情况下，也只有大厂才有能力来“偿还”。
代码屎山根本无法避免
技术债并非是技术壁垒，在软件工程里是无法避免的，哪怕做再多的 code review 都只是在延缓这一进程。
尽管如此，国内的这些大厂往往很少在版本更新中专门解决这类问题，大多数的版本迭代都是针对业务需求的调整，而非针对代码的可维护性进行优化。
至于为什么会产生这些代码屎山，程序员的代码水平往往只是影响因素之一，更主要的是由于业务逻辑的不断变化、紧急需求的临时添加、以及重构过程中可能引入的问题。
在我之前处理复杂代码的经历中，我注意到最初的代码架构通常是简洁的，但随着时间的推移，特别是在某个特定的commit之后，代码开始变得冗余和复杂，最终导致整个代码结构变得难以管理和控制。
所有的屎山代码，往往都始于一个if，一个for，然后随着时间的推移和开发人员的变更，最后数不清的if和好几层的嵌套for，以及莫名其妙的接口定义摧毁了整个结构。
最后，引用网友的一首打油诗，来表达我们程序员对代码屎山的无奈：
“你的屎山，我的屎山，好像都一样，
大厂小厂，发到线上，天天报异常。
加班迭代，为了市场，质量让一让，
自负盈亏，发现不对，业务都得黄。
关注「前端技术官」加星标，不错过圈内事
↓↓↓
