给老项目加入eslint的建议
本文属于原创文章,转载请注明–来自桃源小盼的博客
前言
通常关于eslint的文章是介绍如何使用。这里会假定一个前提,这是一个新项目。今天我们聊聊老项的一些使用建议。
尽快确定一种风格
很多团队会陷入一种争论,到底选择哪种风格,通常有airbnb
、standard
等。也有一些团队会认为这几种风格都不是我想要的,要自己定制。
此时,我们忽略一个问题,我们做这件事最重要的目的是什么?
有两个目的,一是自动检查错误;二是统一团队代码风格,增强维护性。
不论哪种风格,都会检查错误,那么统一风格才是主要的目标,而不是选择哪种风格。
所以不论是民主投票,还是leader做决定,或者其他办法。都请尽快确定风格,并且有了prettier
后,写代码的过程中工具会帮你自动改正的。
不用追求完美
当我们在一个老项目中加入eslint后,会发现报错信息多到爆炸,我相信程序员中有很多强迫症,想立刻修复这些错误。
但我请你先停下来,思考一个问题,你能确保自己的修改,不会导致任何问题吗?
答案是不能。
同时还有几个事情需要考虑:
- 有一些错误或警告,需要读懂原来的代码,并进行修复
- 古老的项目,有太多的文件需要修复
- 有一些修复需要完整的测试
上面这三件事情会耗费团队很多精力,并且有些团队有很多古老的项目。工作量太庞大了,如果我们把大量的精力浪费在这里,不是最好的选择。
过去的代码,虽然它丑陋,但大都经过了充分地测试,是可以正常运行的代码。我们的主要目标是约束未来的代码。
我的办法
因为我个人有代码洁癖,所以做了一些更精细的操作。
- 有一些规则,像缩进都改成两个空格,这类的规则全都使用工具来解决掉。
- 给所有文件增加
eslint-disable
注释,并规范团队,在未来如果修改这个文件,需要删除注释并修复。
因为我们团队采用了vue,所以写了一个批量添加注释的脚本工具。
1 |
|
结语
推荐望闻问切这种古老的中医方法,多看项目代码,找熟悉的人咨询,将具体的策略和团队一起探讨。
希望大家根据自己的项目情况,做出更好的决策。