前言
为什么开发都喜欢重构代码，而不是在原有的代码上做持续迭代呢？我想，糟糕的代码质量，是你拒绝在源代码上继续修改的重要理由，甚至没有之一。因此，统一团队代码风格，提高团队代码质量，是很有必要的一件事。下面是我在团队代码质量管理上的一些经验分享。
约定代码风格
一个团队一定要有统一的代码风格，并且一以贯之，使开发人员在跨模块甚至跨应用开发时，可以无痛切换。这里推荐腾讯团队的代码规范，从命名到HTML、CSS、Javascript的书写规范，一应俱全，并辅以代码说明，浅显易懂。也可以根据自身团队的情况做一些调整，不一定全盘复用。不足之处就是两年多没有任何更新了，一些ES6\7\8的规范有所欠缺。
另外，如果你的项目是基于vuejs开发的，你可能还要遵循一个vue的开发规范，使用官网的风格指南即可。
启用ESLint
约定了代码风格，如何保证执行呢？靠肉眼一行一行去看肯定是不行的，那么大名鼎鼎的ESLint你肯定是听过的。ESLint是需要配置的，具体怎么配置可以去官网自己查，这里推荐使用standard风格，当然你可以选择airbnb或者完全手动配置，根据自身团队情况来就好。
当第一次接触ESLint时，大部分人都是痛苦的，写一段代码满屏飘红，很多人适应不了就把它关了。其实只要你适应它几天，就能写出完全符合ESLint要求的代码了，而且还可以配置vscode的ESLint插件，配置保存时自动格式化，哪怕写错也能帮你自动改正，减少适应的痛苦。
它的优点就是统一团队代码风格，矫正代码书写规范，配合编辑器的保存自动格式化，效果更佳。
除了ESLint，还有CSSLint、HTMLHint，顾名思义，分别是统一CSS和HTML风格的，也可以一起用起来。
使用githook校验提交的代码
即便是启用了ESLint，还是有人将不符合规范的代码push到了仓库中，这种问题又要怎样去规避呢？
利用git的hook函数，在commit之前去执行eslint或其他命令，校验提交的代码是否符合规范。如果不符合规范，就会输出报错信息，阻止这一次的提交。
一般前端项目可以使用husky插件配置githook，然后使用lint-staged限制只对暂存区的代码做扫描，不然会对整个git仓库做扫描，一来耗时，二来可能会扫出大量问题，必须全部修复才能提交。
使用QA工具扫描项目
以上主要是对代码风格的规范和约束，如果想对代码做进步一的质量优化，还要借助更高级的QA工具，比如公司的java开发经常使用的findBugs，sonar qube 等。
其中sonar很强大，支持25中开发语言，其中也包括JavaScript、HTML和CSS。但如果要配置在vscode中使用时，需要依赖本地的java环境，配置起来可能会有些麻烦。不过其官网的文档很详细，完全可以当做代码指南来参考。
除了sonar，还有个工具DeepScan，除了能扫描js，还支持vue和react语法，能帮助你发现不符合js框架规范的bug。最棒的是，他有可视化的仪表盘，可以直观的分析代码质量，并且支持团队管理。不过它只能同步github上的项目，目前用下来，还会有偶尔同步失败的问题。我是将gitlab上的项目拷贝一份到github，再用DeepScan同步过来扫描。它有免费版本和收费版本，收费版本可以同步github上的private项目，不过我在试用状态下，是不能正常同步private项目的，不知道是bug还是设定如此。
结对 code review
我们都希望工具能帮我们解决所有问题，但现实往往没有那么美好。纵然上面的工具已经做得很棒了，但它也仅仅是帮我们统一了代码风格，避免了一些琐碎且基础的错误。好的代码一定是没有错误的代码，但没有错误的代码不一定是好代码，上述工具做好了前一半，后一半还是需要人来参与。
结对 code review的优点：
- 每个人的技能树都不尽相同，各自擅长的东西也不一样，多一个人来review，自然会有更大的几率发现问题；
- 不仅能相互发现问题，也能相互学习对方好的设计思想和代码习惯，取其精华，去其糟粕。建议每次结对都换一个人，这样收益更多；
- 相对于工具，人可以从更宏观的角度想问题，可以结合需求、使用场景、边界值等因素来分析代码，而不是只看一个点写的好不好。
结语
所有能落实的方案，才有意义，否则便是空谈。在代码质量的提高上，不建议一蹴而就，不然会有很大的推行阻力。因此，我们可以循序渐进，让团队慢慢去适应。比如可以先约定代码风格，在开发新项目或重构项目时，再启用ESLint，等团队适应了，再执行QA工具扫描、结对 code review等。
