我们是这样衡量代码质量的

越高级别的程序员往往越看重代码质量。

本篇文章主要聊一下在团队开发过程中，如何做到代码质量的管控与提升。首先需要有一套规范，定义什么是好的代码，再通过一些工具，帮助我们在实践规范的过程中，更好地遵循规范。

TLDR: 直接看第 4 点， Iceworks Doctor 解决方案。

为何需要提高代码质量？

好的代码一定是整洁的，并且能够帮助阅读的人快速理解和定位。好的代码可以加快应用的开发迭代速度，不必花过多的时间来修复 bug 和完善代码。好的代码不但能够使得新的项目成员更容易加入项目，同时方便项目组成员快速做好 Back up。好的代码便于促进团队间交流合作提升开发效率。

有编码经验的人对代码都有一定的“鉴赏力”，能够凭感觉给出代码好坏的主观评价。但是这种凭感觉的方式太过个性随意，所谓仁者见仁智者见智，很难达成共识，那有没有一种公认的标准来鉴定代码质量呢？

代码质量评价标准

答案是有的。这里简单分享当下较常用的评价标准，其中包括：编码规范、可读性、可维护性、重复度及可测试性。

编码规范 主要包含是否遵守了最佳实践和团队编码规范，是否包含可能出问题的代码，以及可能存在安全的漏洞。编码规范有助于提高团队内协助的效率以及代码的可维护性。

可读性 Code Review 是一个很好的测验代码可读性的手段。如果你的同事可以轻松地读懂你写的代码，那说明你的代码可读性很好；反之则说明你的代码可读性有待提高了。遵守编码规范也能让我们写出可读性更好的代码。

可维护性 代码的可维护性是由很多因素协同作用的结果。代码的可读性好、简洁、可扩展性好，就会使得代码易维护；更细化地讲，如果代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则等等，那就可能意味着代码易维护。除此之外，代码的易维护性还跟项目代码量的多少、业务的复杂程度、利用到的技术的复杂程度、文档是否全面等诸多因素有关。

重复度 遵守 Don’t Repeat Yourself 原则，尽量减少重复代码的编写，复用已有的代码。对项目定期进行代码重复度检测是一个很有意义的事，可以帮助开发人员发现冗余代码，进行代码抽象和重构。重复的代码一旦出错，意味着加倍的工作量和持续的不可控。如果代码中有大量的重复代码，就要考虑将重复的代码提取出来，封装成公共的方法或者组件。

可测试性 代码可测试性的好坏，同样可以反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。

除此之外还有很多代码质量评价标准。我们需要一些取舍，选取部分大家有共识的规则定义团队好的代码标准。

代码质量建设怎么开始

当团队有了统一的代码质量评价标准后，便需要严格的执行代码编写规范。

工欲善其事，必先利其器

我们可以通过 SonarQube 等静态代码检测工具来进行代码质量建设。但在代码完成发布后如果线上没有问题的话，相信很少有人会主动优化代码，即使有扫描结果也很难推动代码质量的提升。

所以这里很需要平台、工具或者工作流上的配合。否则在具体写代码的过程中，很容易由于开发人员的不重视，导致整个 Code Base 变得越来越差。所以提高团队对代码规范的认同及严格执行是代码质量建设的关键。

当然我们也可以在代码提交的时候，利用钩子来控制允许提交或者拒绝提交，比如 git 的 pre-commit 和 commit-msg。但是这些都是比较滞后的方式，我们能不能更提前发现问题让开发在功能开发过程中就把发现的问题改掉？

Iceworks Doctor

为实现 JavaScript 代码规范的统一，并提升和改善团队代码质量，我们当前发布了 Iceworks Doctor 0.1.0 版本。该方案目前包括多场景统一的 ESLint 规则配置、多维度的代码衡量标准、执行分析扫描代码及代码修复等模块。通过各个模块协调配合，评估质量评分并修复规范问题，在降低维护成本、提升执行效率的同时保障代码规范的统一。