注册

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

前言

前几天我写了一篇Vue2屎山代码汇总,收到了很多人的关注;这说明代码简洁这仍然是一个程序员的基本素养,大家也都对屎山代码非常关注;但是关注归关注,执行起来却非常困难;我明明知道这段代码的最佳实践,但是我就是不那样写,因为我有很多难言之隐;

没有严格的卡口

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

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

没有代码规约

大厂一般都有代码规约,比如:2021最新阿里代码规范(前端篇)百度代码规范

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

没有思考的时间

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

框架约束太少

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

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

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

没有代码质量管理平台

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

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

最后

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


作者:蚂小蚁
链接:https://juejin.cn/post/7255686239756533818
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

0 个评论

要回复文章请先登录注册