"程序是寫給人讀的，只是偶爾讓計算機執行一下。—— 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，供開發人員直接定位問題代碼行。
- 平臺端：個人、團隊、工程等各維度進行數據彙總，通過圖形、報表多種類型進行數據展示及郵件通知。某團隊編碼問題變化趨勢：
以上是京東零售技術與數據中心共享技術部在檢查前端編碼規範及編碼質量過程中的一些實踐，歡迎交流。
歡迎點擊【京東科技】，瞭解開發者社區
更多精彩技術實踐與獨家乾貨解析
歡迎關注【京東科技開發者】公衆號
