京東掃描平臺EOS—JS掃描落地與實踐

"程式是寫給人讀的，只是偶爾讓計算機執行一下。—— Donald Knuth"

引言

隨著前端應用的大型化和複雜化，越來越多的前端工程師和團隊開始重視 JavaScript 程式碼規範。得益於前端開源社群的繁盛，當下已經有幾種較為成熟的 JavaScript 程式碼規範檢查工具，包括 JSLint、JSHint、ESLint、FECS 等等。EOS-JS，它是一款外掛化的JavaScript 程式碼靜態檢查工具，具備全套的熱修復、增量更新方案，集各類程式碼規範檢查工具優勢於一體，其核心是透過對程式碼解析得到的 AST（Abstract Syntax Tree，抽象語法樹）進行模式匹配，定位不符合約定規範的程式碼、給出修改意見並支援一鍵修復，在降低維護成本、提升執行效率的同時，也保障了程式碼規範的統一。

為實現規範編碼、提高編碼質量，目前較為通用的是直接使用開源生態中提供的一些標準方案，可以用較低成本來實現 JavaScript 程式碼規範的落地。如果再搭配一些輔助工具（例如 husky 和 lint-staged），整個流程會更加順暢。但是對於大型企業開發團隊而言，數十人甚至上千人面對數萬個工程，規模化地應用統一的 JavaScript 程式碼規範，並且有效落地執行，問題就會變得較為複雜。

痛點分析

     設計初期，我們收集了大量前端開發人員的編碼痛點，可以歸納為以下幾點：

人員角度

     公司部門團隊較多，從上往下宣傳，執行難度較大

     團隊（人員）風格差異大的，不是每個團隊都自願去梳理適用的規則集

     沒有資料統計和有效的監管方案，人員執行狀況及編碼最佳化成效沒辦法衡量

技術角度

技術選型分散， React、Vue、JavaScript、TypeScript 等

開發工具可選性多，Vscode、WebStorm等

工程量大，每個工程都按照開源方案進行配置，複雜度提升，管理混亂

解決方案

針對上文中提出的問題，我們設計了一套完整的技術解決檔案，基於EOS-JS提供了外掛端和平臺端兩種掃描方法，使用者  可結合實際情況自由選擇。

EOS-JS是一個掃描引擎，透過基礎檢測能力和模式約束，推動程式碼檢測流程的運轉。原始程式碼經過解析器的解析，在管道中逐一經過所有規則的檢查，最終檢測出所有不符合規範的程式碼，並輸出為報告。

整體設計方案分為以下幾點：

定位問題與自動修復：該模組是整體方案的基石，透過解析程式碼得到AST，進行模式匹配，定位不符合約定規範的程式碼，並針對通用規範問題編碼提供自動修復能力。

多場景通用規範（核心）：透過分層分類的結構設計，在保證基礎規則一致性的同時，實現了對不同場景、技術選型的支撐。

自動化接入升級：透過JD外掛中心實現兩端（Plugin/Server）“一鍵”接入，自動升級，極大降低了工程接入和維護的成本。

多端程式碼檢測：該模組是方案落地執行的保障，將程式碼檢查與本地實時編碼及CI持續整合工作流程相結合。在保證程式碼整合質量的同時，也透過定製整合檢查/修復工具降低了開發者的應用執行成本。

資料統計視覺化：透過對工具執行和程式碼整合檢查過程進行埋點、檢查結果收集和分析，瞭解方案的應用狀態和效果。

     整體方案設計圖如下所示：

具體實現

整體方案已確認，但具體到各個模組的實現，仍然需要進一步深入思考，以設計出更加合理的實現方案。本章將對方   案的幾大核心模組進行詳細介紹。

01 定位問題、自動修復

程式碼解析，獲取問題資料來源是開發掃描引擎，統計編碼問題的前提。

AST編譯簡介

AST：簡單理解,就是把我們寫的程式碼按照一定的規則轉換成一種樹形結構。在javascript世界中，可以認為抽象語法樹(AST)是最底層， 再往下，就是關於轉換和編譯的“黑魔法”領域了。我們常見的前端開發外掛javascript轉譯、程式碼壓縮、css前處理器、pretiier等都建立在了AST這個巨人的肩膀上。EOS-JS引擎集百家之所長，基於AST抽象 JS 原始碼的共性，分析原始碼，進行模式匹配，檢查問題。

編譯流程主要分為以下四步:

詞法分析scanner

parser生成AST樹

traverse對AST樹遍歷,進行增刪改查

generator將更新後的AST轉化成程式碼

可以很清楚的看出，實現程式碼掃描，可以在parser生成AST樹後，進行模式匹配。例項演示如下：

insert函式解析後，得到如下所示結構體：

提出修改建議、一鍵修復。

實際編碼過程中，我們充分利用AST優勢針對常見編碼規範問題例如：註釋、程式碼替換等提供了一鍵修復能力，提高了開發者編碼效率。繼續以insert函式為例，基於我們前面得到的insert函式體的語法樹分析，實現程式碼替換功能：

02 多場景通用規範

這一模組是整體方案的核心，採用分層分類的結構設計，提供多場景、多技術方案的通用配置方案，解決了使用者最大的痛點，並使方案具備易維護、易擴充套件的特性。

詳細配置方案如下：

EOS-JS掃描引擎藉助外掛化設計原理，與解析器解綁，我們可以使用不同的解析器進行原始程式碼解析，例如使用不同的解析器處理 ES 語法與TypeScript 語言。最終實現所有的規則可獨立控制，並且具備自定義擴充能力。

動態配置化方案

EOS-JS提供了全面、靈活的配置能力，可以對解析器、規則、環境、全域性變數等進行配置；還可以配置層疊、實現配置共享。具體的使用中，各團隊可以根據部門需求靈活的選擇各層級、各型別的搭配，在程式碼檢測平臺獲得和專案匹配的規則集，如仍不滿足需求，也可以透過自定義規則集，得到自己預期的統一規範工具。

Base層：透過公司內部前端開發團隊制定統一的基礎語法和格式規範，提供通用的程式碼風格和語法規則配置。

框架支撐層：提供對通用的一些技術場景、框架的支援，包括 Node.js、React、Vue、等；這一層藉助多個團隊對各種框架的規則使用建議，整合出適配各種框架的規則集。

TS層：這一層提供對TypeScript 的支援。擴充套件（自定義）層：針對團隊的特殊規則訴求，提供定製化支援，目前已存在的JDSpecification便是為公司內部定製的前端程式碼掃描規範。

這種分層分類、配置解耦的設計結構，存在以下優勢：

• 對Base層級的修改，影響全域性。

• 對非基礎層某一部分的調整不會產生關聯性的影響。

• 如需擴充套件對某一型別的支援，團隊透過自定義，配置完成後，只需關注這一型別的特殊規則配置。

該方案已在公司內部得到廣泛使用，例如：Plus團隊在平臺配置自定義React規範，掃描該團隊的React專案時規則即時生效，這種透過分層、分類的結構設計，節省了使用者使用成本的同時，減少了規則維護成本，規則示例程式碼如下：

03 自動化接入升級

前端開發人員在開源方案的使用中經常遇到規則無效、相容性、解析異常等問題，反覆排查和定位問題會浪費大量的精力。因此在設計接入及升級流程時，我們充分考慮了規則集和工程方案的相容性、使用者使用場景、接入成本，操作體驗等，採用了Plugin和Server可獨立執行，亦可協同工作的設計模式。一鍵接入，自動升級，為使用者帶來良好的使用體驗。工作流程如下圖所示：

我們開發了JDPluginCenter外掛，支援使用者多場景需求，無論什麼開發場景和框架選型，繁瑣的接入流程都只需要使用者安裝JDPluginCenter或是一條命令整合到專案腳手架，便可實現在外掛和平臺兩端的接入流程。

04多端程式碼檢測

為避免因一些主觀因素或疏漏造成的編碼規範執行不到位，我們將程式碼規範靜態檢查與開發工作流整合，保證程式碼規範的有效落實。

本地開發實時檢查：本地編碼過程中，EOS-VSCode外掛有兩種檢查方式可供選擇。實時檢查編碼問題給出修改建議，也可以針對單個檔案、單個資料夾或者整個專案手動觸發，開啟檢查流程，並將結果展示到前臺。其優點在於實時性，可在編碼過程中發現並解決編碼規範及質量問題。

程式碼提交檢查：在程式碼 Commit 時，透過 gitHook 觸發程式碼檢查。其優點在於能實時響應開發者的動作，給出反饋，快速定位和修復問題 程式碼整合檢查：在程式碼整合（藉助 CI 系統的整合流程功能）時，透過程式碼檢測平臺對程式碼進行檢查，檢測不透過則阻斷整合。其優點在於能夠強制執行，可線上追蹤檢測報告。

Server端檢查：程式碼庫原始碼或構建產物在服務端掃描。支援自動化定時掃描和使用者主動觸發掃描兩種方式，其優點在於可以按照不同維度進行資料統計，對上可以有效監管，對下可以高效落實。

資料統計視覺化

資料統計

核心是資訊採集和分析。在本方案中：

• 執行狀況監測：外掛啟動、關閉、使用者資訊、倉庫地址等資訊上報後，可精確分析使用率、掃描成功率、使用者活躍度等。

• 掃描結果分析：外掛端、CI持續整合節點、Server端掃描都會結果上報掃描結果，包括檢查是否透過、blocker和warning資訊的數量、問題程式碼段、問題程式碼行號等。

分析及資料視覺化

該模組包含外掛端視覺化和平臺視覺化兩部分：

• 外掛端：實時檢測，編碼建議即時提醒；手動掃描，結果分析統計後展示到編輯器view，供開發人員直接定位問題程式碼行。

• 平臺端：個人、團隊、工程等各維度進行資料彙總，透過圖形、報表多種型別進行資料展示及郵件通知。某團隊編碼問題變化趨勢：

以上是京東零售技術與資料中心共享技術部在檢查前端編碼規範及編碼質量過程中的一些實踐，歡迎交流。

歡迎點選【 京東科技 】，瞭解開發者社群

更多精彩技術實踐與獨家乾貨解析

歡迎關注【京東科技開發者】公眾號