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的開發還在不斷的迭代之中，你們拭目以待。