阅读 1373

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的开发还在不断的迭代之中,大家拭目以待。


关注下面的标签,发现更多相似文章
评论