代碼質量檢測平台架構設計

01-29

「前言」

你是否清楚的了解自己的項目有多少個文件夾、多少個文件、多少行代碼、多少個函數、多少個字元數？

你是否在項目中引入過代碼質量檢測相關的工具？

你是否在不同項目的切換中飽受indent=2還是indent=4的困擾？

你是否懷疑過自己的代碼存在性能問題和內存泄露？

趕快和我一起來學習如何搭建一套持續集成的代碼質量檢測平台，為日常項目開發「保駕護航」吧~

背景

我們團隊有多條業務線，每條業務線都有很多子業務項目，每個業務項目使用的技術棧都各不相同，每天有很多業務迭代需求，每次提交的merge request都需要相關同事完成code review之後才可以 merge 代碼，這更是增加大量的人力成本。
不同業務框架使用不同的技術棧，不同技術棧引入不同的coding style，這更是導致開發者在開發過程中無法適從,無統一的標準，導致編程風格混亂。
有些開發者由於迭代需求多或者臨時bug修復等原因直接跳過代碼質量檢查，上線後由於粗心大意產生一些低級bug導致線上故障。
簡單的code review只能解決代碼風格問題，而很難發現重複度、複雜度，case通過率等方面的問題。

預期

對於在日常開發中遇到的這些問題，我們期望能有這樣一套系統，它能夠幫助我們解決以下問題：

可視：我們希望這個系統能夠方便、直觀的查看到代碼存在的問題；
統一規範：不同的項目運用統一的代碼檢測規則，方便團隊進行多項目管理，降低開發者上手成本；
規範且定量：建立一套對檢測結果通用的評分標準，方便我們定量的了解項目代碼健康度；
多維度全方位：提供多維度代碼檢測工具；
優化建議：代碼質量檢查後提供相關優化建議；

項目功能點實現

持續集成：通過code Merge Request持續觸發檢測；
配置中心化：統一的配置管理，包括檢測任務，檢測需要用到的規則；
多維度：開始我們加入 code lint 和代碼重複率檢查；
可視化：web頁面查看項目的檢測評分與各子項詳細檢測結果；
評價體系：建立符合實際需求的評價標準體系；

整體架構

整體架構圖

項目主要通過提交 Merge Request 觸發 git hook，該請求發送merge相關數據至中間層 Node Server，Node 層將請求透傳到 Jenkins Server, Jenkins Server 啟動Job並執行相關檢測腳本，任務完成callback通知 Node Server 和 git 倉庫完成相關『解鎖』步驟。

使用的技術棧

而在該項目中，我們使用的技術棧包括：

Nuxt + koa + WebSocket
Apollo + GraphQL
Jenkins + Plugin
Shell + Python

這篇文章定位是項目整體介紹，故而不涉及具體實現細節，後續我們會有系列文章和大家一起分享功能實現中遇到的問題。

Jenkins Server架構

Jenkins Server架構圖

Jenkins Server根據收到的請求調起對應Job, 在對應Job執行完成後觸發回調，通知開發者、Node Server中間層任務已經結束。

Jenkins是一個比較成熟，普遍用於持續集成框架，它通過安裝插件便可支持各種任務模式。

在該這個項目中，我們自己開發 plugin 完成參數統一化和回調觸發。

腳本框架

原始結果產出

我們將jenkins需要執行的腳本放在一個代碼倉庫中管理，而jenkins job只負責拉取腳本代碼，並執行入口文件。

import osnimport sysnngitRemote = ssh://git@***********.com/litmus.gitnn# 拉取代碼倉庫，切換cwd為腳本目錄nif os.path.isdir(litmus):n os.chdir(litmus)n os.system(git fetch origin && git reset --hard origin/master)nelse:n os.system(git clone %s --depth=1 % gitRemote)n os.chdir(litmus)n# 安裝依賴，執行入口文件nos.system(npm install)nsys.path.append(entry)nimport webnnresult = web.main(None, None)n

我們的腳本執行結果都是以文件的形式產出，而這套文件產出結果將會成為我們提供web頁面展示的原始數據輸入。

Node Web端架構

Node Web端架構實現

2016 年 10 月 25 日，zeit.co 背後的團隊對外發布了 Next.js，一個 React 的服務端渲染應用框架。幾小時後，與 Next.js 異曲同工，一個基於 Vue.js 的服務端渲染應用框架應運而生，我們稱之為：Nuxt.js。

Web端頁面展示

我們通過該web框架展示目標項目執行結果。

總結

本文主要講解「代碼質量檢測平台」項目從需求收集、提取、架構設計以及最終的實現。

這套架構體系對我們的開發者提出了較高的要求，在業務項目接入中，我們遇到了很多困難：

如何制定統一規則
如何本地化腳本任務
如何將graphql集成到nuxt中
如何控制單個項目對jenkins任務的重複觸發
如何解決腳本+web導致的linux文件打開數上線問題
如何在多端同步jenkins任務狀態

想要更多的了解我們是如何解決這些難題的，請點贊，並關注我們吧。

我們會有系列文章來和大家一起分享我們與「代碼質量檢測平台」的故事。

作者簡介： J文，15年加入「美團點評」，目前就職於 點評點餐終端團隊，我們期待您與我們一起打造未來的「智能餐廳」。