熟读代码简洁之道，为什么我还是选择屎山

作者：蚂小蚁

原文：https://juejin.cn/post/7255686239756533818

代码简洁仍然是一个程序员的基本素养，大家也都对屎山代码非常关注；但是关注归关注，执行起来却非常困难；我明明知道这段代码的最佳实践，但是我就是不那样写，因为我有很多难言之隐；

没有严格的卡口

没有约束就没有行动，比方说eslint，eslint只能减少很少一部分屎山，而且如果不在打包机器上配置eslint的话那么eslint都可以被绕过；对我个人而言，实现一个需求，当然是写屎山代码要来的快一些，我写屎山代码能够6点准时下班，要是写最佳实践可能就要7点甚至8点下班了，没有人愿意为了代码整洁度而晚一点下班的。

没有CodeReview，CodeReview如果不通过会被打回重新修改，直到代码符合规范才能提交到git。CodeReview是一个很好地解决团队屎山代码的工具，只可惜它只是一个理想。因为实际情况是根本不可能有时间去做CodeReview，连基本需求都做不完，如果去跟老板申请一部分时间来做CodeReview，老板很有可能会对你进行灵魂三连问：你做为什么要做CodeReivew？CodeReview的价值是什么？有没有量化的指标？对于屎山代码的优化，对于开发体验、开发效率、维护成本方面，这些指标都非常难以衡量，它们对于业务没有直接的价值，只能间接地提高业务的开发效率，提高业务的稳定性，所以老板只注重结果，只需要你去实现这个需求，至于说代码怎么样他并不关心；

没有代码规约

大厂一般都有代码规约，比如：2021最新阿里代码规范（前端篇）^[1]、百度代码规范^[2]

但是在小公司，一般都没有代码规范，也就是说代码都无章可循；这种环境助长了屎山代码的增加，到头来屎山堆得非常高了，之后再想去通过重构来优化这些屎山代码，这就非常费力了；所以要想优化屎山代码光靠个人自觉，光靠多读点书那是没有用的，也执行不下去，必须在团队内形成一个规范约定，制定规约宜早不宜迟

没有思考的时间

另外一个造成屎山代码的原因就是没时间；产品经理让我半天完成一个需求，老大说某个需求很紧急，要我两天内上线；在这种极限压缩时间的需求里面，确实没有时间去思考代码怎么写，能cv尽量cv；但是一旦养成习惯，即使后面有时间也不会去动脑思考了；我个人的建议是不要总是cv，还是要留一些时间去思考代码怎么写，至少在接到需求到写代码之前哪怕留个5分钟去思考，也胜过一看到需求差不多就直接cv；

框架约束太少

越是自由度高的框架越是容易写出屎山代码，因为很多东西不约束的话，代码就会不按照既定规则去写了；比如下面这个例子： stackblitz.com/edit/vue-4a…^[3]

这个例子中父组件调用子组件，子组件又调用父组件，完全畅通无阻，完全可以不遵守单向数据流，这样的话为了省掉一部分父子组件通信的逻辑，就直接调用父组件或者子组件，当时为了完成需求我这么做了，事后我就后悔了，极易引起bug，比如说下一次这个需求要改到这一部分逻辑，我忘记了当初这个方法还被父组件调用，直接修改了它，于是就引发线上事故；最后自己绩效不好看，但是全是因为自己当初将父子组件之间耦合太深了；

自己需要明白一件事情那就是框架自由度越高，越需要注意每个api调用的方式，不能随便滥用；框架自由不自由这个我无法改变，我只能改变自己的习惯，那就是用每一个api之前思考一下这会给未来的维护带来什么困难；

没有代码质量管理平台

没有代码质量管理平台，你说我写的屎山，我还不承认，你说我代码写的不好，逻辑不清晰，我反问你有没有数据支撑

但是当代码质量成为上线前的一个关键指标时，每个人都不敢懈怠；常见的代码质量管理平台有SonarQube^[4]、DeepScan^[5]，这些工具能够继承到CI中，成为部署的一个关键环节，为代码质量保驾护航；代码的质量成为了一个量化指标，这样的话每个人的代码质量都清晰可见

最后

其实看到屎山代码，每一个人都应该感到庆幸，这说明有很多事情要做了，有很多基建可以开展起来；推动团队制定代码规约、开发eslint插件检查代码、为框架提供API约束或者部署一个代码质量管理平台，这一顿操作起来绩效想差都差不了；

参考资料