Litmus代码质量平台实践总结

背景

代码质量在项目开发中是一个很重要的地方，更好的质量的代码，可以产生更少的bug，也能使开发人员更不容易犯错，产品的质量获得提高。那么怎么定义代码质量，怎么测量以及如何展示就成为咱们内部平台Litmus的主要探索领域。

以前的文章有屡次提到咱们团队内部的Litmus平台，它是一个自动化代码审查反馈的系统，可以给开发者提供当前代码的各类维度的分析结果，帮助开发人员更好的解决潜在的bug和更好的管理组织代码文件。

目前，咱们的系统已经不断迭代和运行了近4个月，获得了不错的效果，也筹备和设计了后续的开源计划。同时也从平常使用中优化了自身不少方面，咱们决定在这里完整的介绍一下咱们的Litmus代码质量检查平台，关于它是如何构建和架构的，以及在构建这个平台中所产生的对代码质量问题的思考和总结。

什么是代码质量

代码质量是一个很抽象的概念，可是它贯穿于整个程序开发中，而且大部分的bug和delay，以及开发中的体验，都来自于代码质量的偏低。咱们一直在探索如何将这个抽象的概念具体的定义出来。随着业务的增长，随着团队的发展，项目代码会愈来愈多，变得愈来愈难维护，这些变化并非一天造成的，而是每次提交每次合并带来的一点点的复杂和混乱，由于没有监控和人力问题，致使项目愈来愈臃肿和繁杂。咱们但愿对这个过程进行插手，探索和改进整个流程。

首先咱们对现有的工具进行了一番调查，好比sonar等一些学院派的检查工具，这些工具在使用上就很是困难，数据也略复杂和专业，用在业务中将会是一个overkill，因而咱们决定本身创建一套质量管理平台。

最早进入咱们计划的就是Lint工具提供的语法和风格检查，也是最容易看到直观的结果的检查。因而咱们统一了团队的ESLint和TSLint规则，最开始集成在开发流程中，因为众多历史项目和成员的开发习惯，这一步骤常常会被避免掉，因而咱们决定将Lint检查放在服务端统一运行做为一个最后的确认，若是有Lint错误将不容许合并代码。其次咱们发现代码的重复度和代码的复杂度也是一个重要的指标，具体的指标下文有介绍。

同时咱们认为，代码质量检测应该是一个自动运行的东西，程序员不该该从工做流上有所改变，它应该自动分析咱们的代码提交，给出结果反馈，程序员再进行相应的修改，整个过程须要流畅和迅速，同时结果的展现应该尽量的简单，去掉专业化的描述，让学习成本降到最低，直接看到问题便可。带着这些想法，咱们尝试构建了Litmus平台。

基础介绍

利用内部仓库系统的钩子，在每次项目提交PR和Merge后触法钩子，发送请求到咱们的服务器。服务器便会依照以前对每一个项目设置好的配置信息，进行检查，检查完毕后，检查结果将会经过内部im工具发送给PR提交者，他即可以经过页面看到检查结果并有可能对代码进行相应的调整。

目前检测主要有3个维度，分别是语法规则，复制粘贴率和代码复杂度：

• 语法规则也就是ESLint，TSLint等lint工具的检测，经过对错误和警告数量的计算获得一个代码结果的分数。
• 复制粘贴率表明代码中间的类似部分，在代码中出现大面积的类似代码，就是一个质量很差的地方，可能出现修改了一处另外一处没有被修改致使出现问题的状况。经过重复的多少计算出一个合理的分数来表明结果。
• 代码复杂度是一个较为复杂的概念，具体的介绍比较多，关于介绍能够参考咱们以前的详细的文章

系统部分截图以下（敏感数据被遮盖）：

总体架构

最初的架构能够在这个文章中找到，那时候的技术栈很杂，同时扩展性也不高，维护起来会很麻烦。咱们不断的对litmus进行修改，目前的架构能够用这个图来展现：

整个Litmus被分红3个部分，一个是处理请求的Server，这个是核心；一个是包含着各类检查器的Core，是一个纯算法库；一个是存储数据的MongoDB。整个Ltimus使用JavaScript编写。下面分别来介绍下每一个组成部分

Litmus Server

Server能够说是整个系统的核心部分，它负责提供web界面，处理界面请求，同时还会接受仓库系统触发的钩子请求，分别从数据库中拿到数据来展现和运行检查器。Server的启动须要两份配置文件，一个是对server自己的端口，数据库地址之类的基本信息（Litmus Config）；另外一个是对每个须要检查的项目的具体配置信息文件（Project Config）。

当仓库的钩子被触发，仓库将会发起一个请求（在仓库配置），请求咱们的Server，接收到请求后，将会知道一个任务须要检查了，就会将任务推动检查队列（Working Queue），检查队列是一个可以同时运行多个任务的任务队列，每次运行任务，经过开启一个进程，运行Litmus Core检查器算法程序。检查结果将会经过事件发送被监听，而后写入数据库。

Litmus Core

Core是检查器的算法库，它是一个纯粹的接收数据，计算，而后产生结果的库，不能感知到外部的任何结构，全部的检查器位于此。须要注意的是，因为要使用ESLint等Lint工具，咱们须要将团队的规则作成sharable config的形式，打包成一个npm包，全局安装这个包和其peerDependencies在Server运行的主机上，才能使检查器访问到正确的规则文件。从实际来讲，大部分团队的ESLint规则也都是一套全团队适用，这样才能风格统一。

MongoDB

数据库用来存放全部的检查结果，经过在配置文件中给出数据库的地址让Server可以操做它。为了更快速的检索咱们创建了一些索引。

Litmus部署

最先期，Litmus为团队内部使用的项目，没有考虑到向外扩展来设计系统的结构。可是随着不断的扩张，咱们但愿可以将系统的运维工做分发给各个团队的使用者，而不是一个集中化的管理在咱们团队，这样咱们承担的运维任务就要少不少，同时机器的资源也获得了保证，因而就须要其他的团队可以方便简洁的搭建整个系统。

为了简化自身部署，同时可以给其余团队测试试用版本，咱们参考Ghost CLI开发了安装的CLI程序，可以一行命令安装好所须要的各类组件和代码。固然，配置文件的内容仍是须要使用者本身来填写。

实践效果分析

咱们在不断的迭代中，也在同时的关注litmus总体使用状况，对此咱们选择了上线以后到2017年末，几个较为活跃的项目进行统计分析，将分数作成图表，在这里展现部分统计图：

能够看到团队对质量平台的重视程度，而且编写代码的确受到了Lint工具的反馈，重视起代码质量。对于这些数据和咱们的详细使用状况分析，以及对现有系统的改进计划，将会在下一篇文章中详细介绍。

将来的计划

在通过了实际使用后，发现有些指标的做用并无咱们指望的那样优秀，表现略平庸，因而咱们决定在检测维度上和展现方式上进行一些改进升级。目前的维度尚未足够全面，须要有更多的指标加入才能更好的发挥代码审查的做用。一些新的维度正在被筹备和设计的同时，也将会一改之前使用列表的方式展现数据的方式，采用结构图的方式结合不一样的颜色来可视化结果。这些都是咱们在使用过程当中的探索，目的也是打造一个完善的代码质量评测流程，可以为团队带来实际更大的改进。

关于你们关注的开源计划，咱们但愿可以将内部团队的使用体验打造至极致后，通过公司内部多团队的测试体验不断的优化自身，再向外部开源一整套解决方案。具体的开源形式尚未肯定下来，不过这都是被提上日程的事情，关于Litmus的开发还在不断的迭代之中，你们拭目以待。