文章探讨了大公司中代码质量低下的一些原因，包括历史遗留问题、复杂的业务逻辑、追求快速迭代和不同技术栈的不统一。开发者可能会接手代码质量参差不齐的项目，导致代码变得臃肿和难以维护。此外，开源项目快速交付的压力也可能导致内部代码质量下降，形成‘代码屎山’。在这样的环境下，改善代码质量往往需要付出额外的努力。
点击“开发者技术前线”，选择“星标🔝”
在看|星标|留言, 真爱
来自：开发者技术前线
作者：可可
最近有一位朋友进入梦寐以求的某大公司，入职没多久就和我抱怨了下，他们公司代码写的也不怎么好，连他一个菜鸡都能看出逻辑漏洞，但却没人改。
让他有点怀疑人生了。那么为什么有的大公司代码也会如此烂呢？
他发现团队高工的写得代码和开源的代码一对比后，公司的代码写非常臃肿，差距也非常大。甚至好多代码，写的都比较复杂。这哥们告诉我：一个好简单的功能要研究1-2天才能摸清代码怎么改。。最后写一行代码。
为什么大公司代码写的并不好？
历史遗留
如果是老的项目，几乎新人一入职不久就接手了，如果之前维护这个项目的人，技术水平比较高，代码行云流水、代码规范，逻辑严谨度都很高，恭喜你，你获取一个学习优秀代码的成长起点。对于你是幸运的，之前接触过这样的项目，真是写的好，巧妙的设计模式，逻辑清晰，和读系统源码一样。但是你没那么幸运，接手一个水平不是很高的团队维护的代码，那你就有事情做了，重新写，还是重构。烂代码跟一坨屎一样，很多时候就是和一坨屎共处千万别深挖，说不定把哪里挖塌了把你埋了，扔一坨代码到屎山上，达到自己目的，能跑就行了，你还要搞清楚山上的屎哪一坨是谁拉的，拉的人吃了什么，就没什么意思了。能在超级大的屎山上扔一坨代码进去，把自己的事干了，也是本事真的，毕竟谁没维护过烂代码。复杂度足够大，都会成为屎山的，什么设计模式都没什么鸟用。这时候可以花时间加班来重写吧，不然你干不下去的，等着你的要么走人。
有一天来个架构师，也只能把垃圾代码装到垃圾箱，但垃圾代码还是垃圾代码。并没有改变。
业务逻辑
业务逻辑复杂，一个系统和N多系统集成，一个业务对象上百个字段和几十种状态，一个流程几十个环节，自己业务依赖他人的，别人写的烂，自己也会被影响，反正写的烂无所谓了。看着别人集成的代码反正也不知道哪里不对劲，代码能跑就行，谁动谁背锅。
然后扔一坨代码到本来的屎山上，那就更烂了。
追求开源
大公司技术团队基本考虑利好招人、技术宣传，一般都会做开源项目，开源项目发起后，基本要在短时间内交付一个可使用的版本，在还没有开源之前。通常项目会在内部团队进行接入实验，因此首先被恶心的就是公司自己内部的团队，项目Bug多，和已有的服务系统不兼容，各种接口适配、包装。最后开源项目对外开源了，但内部业务团队的遗留的接入层没人维护，甚至开源项目对外开源后，造轮子的团队完成KPI后，就抛弃不维护、或者作者已经离职去其他大公司继续造轮子了。
这样造成代码屎山有人堆，没人铲的局面，越来越臭。
注重效率
大公司对项目要求迭代快，尤其在大公司的孵化项目的初创团队，人员配置不完善，并且高层们为了拿下市场份额，会给业务施加压力。所以要求短时间内版本要上线，这样一来，业务开发就没时间去关注质量，在这边copy，那边copy, 先上线再说，久而久之，后面的自己看到自己写的代码都会恶心死，本想改下？改了能有KPI？算了反正当前程序能跑，懒得改。
技术栈不统一
大公司技术团队由非常多的业务部门组成，不同部门之间技术栈未必全部统一，每个业务部门一把手为了自己的一亩三分地，害怕自己团队被其他部门吃掉，稳住技术护城河，通常也不愿意接入其他部门开发的轮子，甚至还要自己造轮子后恶意竞争，于是形成了不同部门有自己的技术栈，有的后端用Java, 有的用go。这样一来，在部门间协作时会遇到系统无法互相调用，两边的开发人员又会开始疯狂开发适配层接口，在本来就不怎么好的代码上又打补丁，让这座代码屎山堆地更加高了。一旦某个部门被裁或者合并，这座代码屎山会越来越薰，臭是晕留下的对方部门的技术同事。
最后留言说说你遇到的烂代码，并且它是怎么样的？
— 完 —
点这里👇关注我，记得标星呀～
前线推出学习交流一定要备注：研究/工作方向+地点+学校/公司+昵称（如JAVA+上海扫码加小编微信，进群和大佬们零距离END
后台回复“电子书” “资料” 领取一份干货，数百面试手册等
历史推荐
好文点个在看吧！
扫一扫
6362
到【灌水乐园】发言
