我经历的那些前端屎山项目

最近看到掘金一篇好文《如何把前端项目写成一座屎山？》， 看的热泪盈眶，回想起了这么多年我遇到过的前端代码屎山

不写注释

这个见到的就太多了，跟个人习惯有关
解法：把写注释写到团队规范中，尤其是那种马上要交接的项目

不使用eslint、prettier等任何格式相关工具

这个经常遇到，你想象一下以下几个场景：
在同一个文件中，你的代码两格缩进，别人的代码四格缩进，某某某的代码，随意缩进……
在某一个3000行的vue文件中，你新写了一个computed，发现死活不生效，后来才在最下面一行，发现了computed早就写过，把你上面的覆盖掉了
解法：eslint、prettier还是要有的，如果嫌麻烦可以把规则设定的少一些，总不能两格四格随意缩进吧

全面拥抱状态管理器

这个是在Gaode公司遇到的，中后台数据可视化项目，某架构大神把所有的数据都放到redux里面，数据量之大，甚至能影响到界面的性能，后来再别人的修改下，减少了N多数据，解决了性能问题。
解法：后来我们定下规则，不需要共享的数据，绝对不放到redux里面。至于之前的数据，慢慢修改

不做模块抽象和复用

最经典的，还是在JD公司，当时的业务是广告投放黄金流程，第一步-设置基本信息，第二步-上传素材，第三步，确定信息上传。
其中第二步的上传素材，可以上传图片、视频、图片+视频三种方式的，当时单文件vue，4000行代码，最大的问题在于上面三种上传方式的dom、js，都是分开处理的，完全没有做复用，可读性比较差，而且修改内容的话，很容易修改漏了。
解法：由于是黄金业务流程，当时无人敢动，我也不敢，在慢慢摸索了N久之后，了解了代码的逻辑，要了一周的工期+测试验收、产品验收的时间，才把这块重构搞定

编写长长长长长的组件

还是在JD公司，当时的业务是广告投放黄金流程，第一步-设置基本信息，这个单vue文件3000多行，没有任何子组件，每次维护代码的上下横跳，简直要吐血。
解法：这个拆分倒是比较简单的，因为广告投放第一步，有一些选择人群、选择时间、地域之类的业务组件，还是比较方便拆分的，当时拆了5、6个子组件+4个业务性的mixin，清晰了很多

冷门库的使用

还是在JD公司，遇到的不只是冷门库，而且废弃的库。
当时的场景：某团队写了一个kpi项目——UI组件库，对标element ui的那种，然后为了表示有人使用，就在自己新启动的业务系统中，使用了这个UI组件库，不幸的是，这个新启动的业务系统，后来到了我的手里。那个UI组件库功能少不说，后来因为人员变动，没人维护了！！！
由于开发的费劲，不得已又引入了element ui，没错，就是两套库，问题照样很多：样式不协调倒还好说，element ui的一些组件（例如dialog），由于样式冲突的冲突，压根没法使用！
解法：长痛不如短痛，要了专门的时间，把那个没人使用的垃圾UI库，直接全部删掉，相关引用的组件使用element ui组件代替

修改 node_modules 中源码

还是在JD公司，当时入职接手的第一个react项目，就是这样，需要修改node_modules中某个配置文件，要不然就跑不起来！！！
解法：应当需要读取本地配置文件。这个本来想解来着，结果后面不久项目废弃了，也就没有再投入时间去解

能力不够写的复杂组件

这个是在Gaode公司，某产品负责人喜欢复杂的表格，于是乎，某前端大哥把rctable的源码拿了过来，二次封装了一个复杂的表格组件。
思路没问题，不过该大哥没有达到平衡，就是自己的能力+表格代码的复杂度+产品源源不断的需求，导致了众多bug，收到很多吐槽。
领导很重视这个问题，于是派团队内技术最NB的哥们来重构这个代码，这哥们最大的NB，不止在技术，而是研究了一下说，咱能不能不做这个复杂的组件？
解法：那哥们的想法还真实现了，不久后面产品负责人进行了调整，新来的产品对那个复杂表格不感冒，把那个复杂表格组件功能阉割一下收尾，把bug清理一下就高挂起来了

滥用setTimeout

这个在LH公司，某同事似乎与nextTick有仇，从来不用，一律使用settimeout代替，项目中众多 setTimeout 到处埋伏
这样就出大问题了：
1、setTimeout 时机控制的有问题，导致了流程有问题
2、setTimeout 导致了代码可读性差，因为 setTimeout 比较多，你无法一眼看出哪个先执行来
3、倒是了js报错，很多是在setTimeout中调用了vue组件的ref，这个时候如果组件销毁了，setTimeout继续执行的话，ref就获取不到，瞬间报错
解法：setTimeout 得慎用，要不然就乱了

使用自己不了解的项目架构

在LH公司，接手了某项目，了解了之后，觉得很多引用的三方包没用，问了相关同事，答曰：这是从之前的项目迁移过来的，不知道干啥用的，项目能正常启动，就没动。
……殊不知，影响了可读性，影响了性能
解法：要对自己的项目架构负责

黑科技、影响全局的魔法功能

你新写了一个功能，明明代码跟api上一页，结果就是不好使，然后你发现了问题，某同事在全局重写了这个功能，比原来的功能多了一些限制
解法：减少对黑科技的使用，影响全局的那些方法，需要告知项目同组的前端研发

git commit注释

这个倒是不算代码屎山了，不过你想象一下，跟你配合的某同事，git commit的内容，一律都是“test”，这个时候，你review他的代码的时候，是不是感觉无从下手？
解法：按git提交规范约束commit

没有任何交接的项目

Duang！一个新git库给你了，除此之外，啥都没有！然后产品过来跟你聊这块的新需求了，很着急，希望明天上线的那种。
解法：项目交接看人品 ——如何交接（接手）一个前端项目

其它的

还有一些听别人说的，或者不是那么严重的问题，比如比用户名+密码存到localstorage中、仍然写var、回调嵌套等es5代码

总结

除了上面吐槽别人的，我之前也写过一些屎代码，比如深层次组件依次传值、往全局window上写属性等，后面与同事交流，也修正了之前的问题。
如上的屎山代码， 大部分不是因为能力不够，而是习惯导致，大家都是先实现功能，然后再去优化。但很多的时候，功能实现完了，就懒得优化了。
总之，需要多思考、多交流，代码并不是你写完了之后就完事了，除了让机器读，还需要让人去读，大家都说好的代码，才是好代码。