背景
代码质量在项目开发中是一个很重要的地方，更好的质量的代码，能够产生更少的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的开发还在不断的迭代之中，大家拭目以待。
