摘要：自動(dòng)化接入和升級(jí)方案通過(guò)命令行工具提供一鍵接入升級(jí)能力，同時(shí)集成到團(tuán)隊(duì)腳手架中，大大降低了工程接入和維護(hù)的成本。原始代碼經(jīng)過(guò)解析器的解析，在管道中逐一經(jīng)過(guò)所有規(guī)則的檢查，最終檢測(cè)出所有不符合規(guī)范的代碼，并輸出為報(bào)告。

代碼規(guī)范是軟件開(kāi)發(fā)領(lǐng)域經(jīng)久不衰的話(huà)題，幾乎所有工程師在開(kāi)發(fā)過(guò)程中都會(huì)遇到，并或多或少會(huì)思考過(guò)這一問(wèn)題。隨著前端應(yīng)用的大型化和復(fù)雜化，越來(lái)越多的前端工程師和團(tuán)隊(duì)開(kāi)始重視 JavaScript代碼規(guī)范。得益于前端開(kāi)源社區(qū)的繁盛，當(dāng)下已經(jīng)有幾種較為成熟的 JavaScript 代碼規(guī)范檢查工具，包括 JSLint、JSHint、ESLint、FECS 等等。本文主要介紹目前較為通用的方案——ESLint，它是一款插件化的 JavaScript 代碼靜態(tài)檢查工具，其核心是通過(guò)對(duì)代碼解析得到的 AST（Abstract Syntax Tree，抽象語(yǔ)法樹(shù)）進(jìn)行模式匹配，定位不符合約定規(guī)范的代碼。

ESLint 的使用并不復(fù)雜。依照 ESLint 的文檔安裝相關(guān)依賴(lài)，可以根據(jù)個(gè)人/團(tuán)隊(duì)的代碼風(fēng)格進(jìn)行配置，即可通過(guò)命令行工具或借助編輯器集成的 ESLint 功能對(duì)工程代碼進(jìn)行靜態(tài)檢查，發(fā)現(xiàn)和修復(fù)不符合規(guī)范的代碼。如果想降低配置成本，也可以直接使用開(kāi)源配置方案，例如eslint-config-airbnb或eslint-config-standard。

對(duì)于獨(dú)立開(kāi)發(fā)者，或者執(zhí)行力較強(qiáng)、技術(shù)場(chǎng)景較為單一的小型團(tuán)隊(duì)而言，直接使用 ESLint 及其生態(tài)提供的一些標(biāo)準(zhǔn)方案，可以用較低成本來(lái)實(shí)現(xiàn) JavaScript 代碼規(guī)范的落地。如果再搭配一些輔助工具（例如 husky 和 lint-staged），整個(gè)流程會(huì)更加順暢。但對(duì)于數(shù)十人的大型前端團(tuán)隊(duì)來(lái)說(shuō)，面向數(shù)百個(gè)前端工程，規(guī)?；貞?yīng)用統(tǒng)一的 JavaScript 代碼規(guī)范，問(wèn)題就會(huì)變得較為復(fù)雜。如果直接利用現(xiàn)有的開(kāi)源配置方案，可能會(huì)使工作事倍功半。

規(guī)?；瘧?yīng)用統(tǒng)一的 ESLint 代碼規(guī)范，會(huì)涌現(xiàn)各類(lèi)問(wèn)題，根源在于大型團(tuán)隊(duì)和小團(tuán)隊(duì)（或獨(dú)立開(kāi)發(fā)者）的差異性：

技術(shù)層面上：

技術(shù)場(chǎng)景更加廣泛：對(duì)于大型團(tuán)隊(duì)，其開(kāi)發(fā)場(chǎng)景一般不會(huì)局限在傳統(tǒng) Web 領(lǐng)域內(nèi)，往往還會(huì)涉及 Node.js、React Native、小程序、桌面應(yīng)用（例如 Electron）等更廣泛的技術(shù)場(chǎng)景。

技術(shù)選型更加分散：團(tuán)隊(duì)內(nèi)工程技術(shù)選型往往并不統(tǒng)一，如 React/Vue、JavaScript/TypeScript 等。

工程數(shù)量的增加和工程方案離散化導(dǎo)致 ESLint 方案的復(fù)雜度提升：這樣會(huì)進(jìn)一步增加工程接入成本、升級(jí)成本和方案維護(hù)成本。

在團(tuán)隊(duì)層面，隨著人員的增加和組織結(jié)構(gòu)的復(fù)雜化：

人員風(fēng)格差異性更大、溝通協(xié)調(diào)成本更高。

方案宣導(dǎo)更難觸達(dá)，難以保證規(guī)范執(zhí)行的落實(shí)。

執(zhí)行狀況和效果難以統(tǒng)計(jì)和分析。

因?yàn)榇嬖谥T多差異，我們?cè)谠O(shè)計(jì)具體方案時(shí)，需要考慮和解決更多問(wèn)題，以保證規(guī)范的落實(shí)。針對(duì)上述分析，我們梳理了以下需要解決的問(wèn)題：

如何制定統(tǒng)一的代碼規(guī)范和對(duì)應(yīng)的 ESLint 配置？

場(chǎng)景支撐：如何實(shí)現(xiàn)對(duì)場(chǎng)景差異的支持？如何保證不同場(chǎng)景間一致部分（例如 JavaScript 基礎(chǔ)語(yǔ)法）的規(guī)范一致性？

技術(shù)選型支撐：如何在支撐不同技術(shù)選型的前提下，保證基礎(chǔ)規(guī)則（例如縮進(jìn)）的一致性？

可維護(hù)性：具體到規(guī)則配置上，能否提升可復(fù)用性？在方案升級(jí)迭代時(shí)成本是否可控？

如何保證代碼規(guī)范的執(zhí)行？

人員的增加和組織結(jié)構(gòu)的復(fù)雜化，會(huì)導(dǎo)致基于管理的執(zhí)行把控失效，這種情況應(yīng)該如何保證代碼規(guī)范的執(zhí)行質(zhì)量？

如何降低應(yīng)用成本？

在工程數(shù)量增加、工程方案離散化的情況，降低方案的接入、升級(jí)和執(zhí)行成本能節(jié)約大量的人力，同時(shí)也有利于方案落地推進(jìn)。

如何及時(shí)了解規(guī)范應(yīng)用狀況和效果？

為了能在團(tuán)隊(duì)內(nèi)實(shí)現(xiàn) JavaScript 代碼規(guī)范的統(tǒng)一，在分析和思考團(tuán)隊(duì)規(guī)?；瘧?yīng)用存在的問(wèn)題后，我們?cè)O(shè)計(jì)了一套完整的技術(shù)解決方案。該方案包括多場(chǎng)景統(tǒng)一的 ESLint 規(guī)則配置、代碼集成交付檢查、自動(dòng)化接入工具、執(zhí)行狀況監(jiān)測(cè)分析等四個(gè)模塊。通過(guò)各個(gè)模塊協(xié)調(diào)配合，共同解決上文提出的問(wèn)題，在降低維護(hù)成本、提升執(zhí)行效率的同時(shí)，也保障了代碼規(guī)范的統(tǒng)一。

整體方案的設(shè)計(jì)如下圖所示：

多場(chǎng)景統(tǒng)一的 JavaScript 規(guī)范：該模塊是整個(gè)方案的核心，借助 ESLint 的特性，通過(guò)分層分類(lèi)的結(jié)構(gòu)設(shè)計(jì)，在保證基礎(chǔ)規(guī)則一致性的同時(shí)，實(shí)現(xiàn)了對(duì)不同場(chǎng)景、技術(shù)選型的支撐。

代碼集成交付檢查：該模塊是方案落地執(zhí)行的保障，將代碼靜態(tài)檢查集成到持續(xù)交付工作流中。具體設(shè)計(jì)實(shí)現(xiàn)上，在保證交付質(zhì)量的同時(shí)，也通過(guò)定制集成檢查工具降低了開(kāi)發(fā)者的應(yīng)用執(zhí)行成本。

自動(dòng)化接入和升級(jí)方案：通過(guò)命令行工具提供“一鍵”接入/升級(jí)能力，同時(shí)集成到團(tuán)隊(duì)腳手架中，大大降低了工程接入和維護(hù)的成本。

執(zhí)行狀況監(jiān)測(cè)分析：通過(guò)對(duì)工具運(yùn)行和代碼集成交付檢查過(guò)程進(jìn)行埋點(diǎn)、檢查結(jié)果收集和分析，了解方案的應(yīng)用狀態(tài)和效果。

上文中提出的問(wèn)題，通過(guò)各模塊的協(xié)調(diào)配合能夠得到有效地解決，但具體到各個(gè)模塊的實(shí)現(xiàn)，仍然需要進(jìn)一步深入思考，以設(shè)計(jì)出更加合理的實(shí)現(xiàn)方案。本章將對(duì)方案的四個(gè)核心模塊進(jìn)行詳細(xì)介紹。

這一模塊主要借助 ESLint 的基礎(chǔ)特性，采用分層分類(lèi)的結(jié)構(gòu)設(shè)計(jì)，提供多場(chǎng)景、多技術(shù)方案的通用配置方案，并使方案具備易維護(hù)、易擴(kuò)展的特性。

在進(jìn)行 ESLint 配置方案設(shè)計(jì)前，我們先看一下 ESLint 的一些特點(diǎn)。

1.插件化

下圖簡(jiǎn)單地描述了 ESLint 的工作過(guò)程：

ESLint 的能力更像一個(gè)引擎，通過(guò)提供的基礎(chǔ)檢測(cè)能力和模式約束，推動(dòng)代碼檢測(cè)流程的運(yùn)轉(zhuǎn)。原始代碼經(jīng)過(guò)解析器的解析，在管道中逐一經(jīng)過(guò)所有規(guī)則的檢查，最終檢測(cè)出所有不符合規(guī)范的代碼，并輸出為報(bào)告。借助插件化的設(shè)計(jì)，不但可以對(duì)所有的規(guī)則進(jìn)行獨(dú)立的控制，還可以定制和引入新的規(guī)則。ESLint 本身并未和解析器強(qiáng)綁定，我們可以使用不同的解析器進(jìn)行原始代碼解析，例如可以使用 babel-eslint 支持更新版本、不同階段的 ES 語(yǔ)法，支持 JSX 等特殊語(yǔ)法，甚至可以借助 @typescript-eslint/parser 支持 TypeScript 語(yǔ)言的檢查。

2.配置能力全面、可層疊、可共享

ESLint 提供了全面、靈活的配置能力，可以對(duì)解析器、規(guī)則、環(huán)境、全局變量等進(jìn)行配置；可以快速引入另一份配置，和當(dāng)前配置層疊組合為新的配置；還可以將配置好的規(guī)則集發(fā)布為 npm 包，在工程內(nèi)快速應(yīng)用。

3.社區(qū)生態(tài)較為成熟

開(kāi)源社區(qū)中基于 ESLint 的項(xiàng)目非常多，既有針對(duì)各種場(chǎng)景、框架的插件，也有各種 ESLint 規(guī)則配置方案，基本可以涵蓋前端開(kāi)發(fā)的所有場(chǎng)景。

基于 ESLint 的插件化、可層疊配置特性，以及面向各種場(chǎng)景、框架的開(kāi)源方案，我們?cè)O(shè)計(jì)了如下圖所示的 ESLint 配置架構(gòu)：

該配置架構(gòu)采用了分層、分類(lèi)的結(jié)構(gòu)，其中：

基礎(chǔ)層：制定統(tǒng)一的基礎(chǔ)語(yǔ)法和格式規(guī)范，提供通用的代碼風(fēng)格和語(yǔ)法規(guī)則配置，例如縮進(jìn)、尾逗號(hào)等等。

框架支撐層（可選）：提供對(duì)通用的一些技術(shù)場(chǎng)景、框架的支持，包括 Node.js、React、Vue、React Native等；這一層借助開(kāi)源社區(qū)的各種插件進(jìn)行配置，并對(duì)各種框架的規(guī)則都進(jìn)行了一定的調(diào)整。

TypeScript 層（可選）：這一層借助?typescript-eslint，提供對(duì) TypeScript 的支持。

適配層（可選）：提供對(duì)特殊場(chǎng)景的定制化支持，例如 MRN（美團(tuán)內(nèi)部的 React Native 定制化方案）、配合 prettier 使用、或者某些團(tuán)隊(duì)的特殊規(guī)則訴求。

具體的實(shí)際項(xiàng)目中，可以靈活的選擇各層級(jí)、各類(lèi)型的搭配，獲得和項(xiàng)目匹配的 ESLint 規(guī)則集。例如，對(duì)于使用 TypeScript 語(yǔ)言的 React 項(xiàng)目，可以將基礎(chǔ)層、框架層的 React 分支、以及 TypeScript 支撐層的 React 分支層疊到一起，最終形成適用于該項(xiàng)目的 ESLint 配置。如果項(xiàng)目不再使用 TypeScript 語(yǔ)言，只需要將?ts-react?這一層去掉即可。

最終，形成了如下所示的 ESLint 配置集：

考慮到維護(hù)、升級(jí)和應(yīng)用成本，我們最終選擇將所有配置放到一個(gè) npm 包中，而不是每種類(lèi)型分別設(shè)置。仍以使用 TypeScript 語(yǔ)言的 React 項(xiàng)目為例，只需在工程中進(jìn)行如下配置：

// 需要安裝 typescript、eslint-plugin-react、@typescript-eslint 等插件
module.exports = {
  root: true,
  extends: [
    // 因?yàn)榛A(chǔ)層是必備的，所以框架層默認(rèn)引入了對(duì)應(yīng)的基礎(chǔ)層，不需再多帶帶引入 eslintrc.base.js
    "eslint-config-xxx/eslintrc.react.js",
    "eslint-config-xxx/eslintrc.typescript-react.js"
  ]
}

這種通過(guò)分層、分類(lèi)的結(jié)構(gòu)設(shè)計(jì)，還有利于后期的維護(hù)：

對(duì)基礎(chǔ)層的修改，只需修改一處即會(huì)全局生效。

對(duì)非基礎(chǔ)層某一部分的調(diào)整不會(huì)產(chǎn)生關(guān)聯(lián)性的影響。

如需擴(kuò)展對(duì)某一類(lèi)型的支持，只需關(guān)注這一類(lèi)型的特殊規(guī)則配置。

眾所周知，TypeScript 類(lèi)型的項(xiàng)目使用 TSLint 進(jìn)行代碼檢查，也是一種簡(jiǎn)單、便捷的方案。但在本方案中我們依舊選擇了：eslint?+?@typescript-eslint/parser?+?@typescript-eslint/eslint-plugin?的組合方案。主要有以下幾點(diǎn)原因：

ESLint 的規(guī)則配置更加詳細(xì)全面，覆蓋更加廣泛。

采用了分層分類(lèi)的架構(gòu)，能夠保證即使框架或語(yǔ)言不同，也能在基本語(yǔ)法、風(fēng)格層面保持規(guī)則的一致性，這樣有利于團(tuán)隊(duì)內(nèi)不同技術(shù)選型項(xiàng)目的風(fēng)格統(tǒng)一。

@typescript-eslint 方案持續(xù)迭代，問(wèn)題響應(yīng)非常迅速，對(duì) TSLint 相關(guān)的規(guī)則基本提供了對(duì)等的實(shí)現(xiàn)。

根據(jù)最新消息，TypeScript在?2019 路線(xiàn)圖?中明確表明后續(xù)對(duì) Lint 工具的支持和建設(shè)會(huì)以對(duì) ESLint 進(jìn)行適配的方式為主。

基于團(tuán)隊(duì)對(duì)工程化基礎(chǔ)設(shè)施的建設(shè)，將代碼規(guī)范靜態(tài)檢查與開(kāi)發(fā)工作流集成，保證代碼規(guī)范的落實(shí)。

通常而言，工程接入 ESLint 后，可以在開(kāi)發(fā)的同時(shí)借助編輯器集成的 ESLint 檢查提示能力（例如 VSCode 的 ESLint 插件），實(shí)時(shí)發(fā)現(xiàn)和修改不符合規(guī)范的語(yǔ)法錯(cuò)誤和風(fēng)格問(wèn)題。但這仍不能避免因一些主觀(guān)因素或疏漏造成的規(guī)范執(zhí)行不到位，所以我們考慮在開(kāi)發(fā)工作流的特定節(jié)點(diǎn)自動(dòng)執(zhí)行代碼靜態(tài)檢查，阻斷不合規(guī)范代碼的提交或交付。

集成靜態(tài)檢查的開(kāi)發(fā)工作流節(jié)點(diǎn)有很多，我們主要參考以下兩種方案：

代碼提交檢查：在代碼 Commit 時(shí)，通過(guò) githook 觸發(fā) ESLint 檢查。其優(yōu)點(diǎn)在于能實(shí)時(shí)響應(yīng)開(kāi)發(fā)者的動(dòng)作，給出反饋，快速定位和修復(fù)問(wèn)題；缺陷在于開(kāi)發(fā)者可以主動(dòng)跳過(guò)檢查。

代碼交付檢查：在代碼交付（借助 CI 系統(tǒng)的交付流程功能）時(shí)，在代碼檢測(cè)平臺(tái)中對(duì)代碼進(jìn)行 ESLint 檢查，檢測(cè)不通過(guò)則阻斷交付。其優(yōu)點(diǎn)在于能夠強(qiáng)制執(zhí)行，可在線(xiàn)追蹤檢測(cè)報(bào)告；缺陷在于離開(kāi)發(fā)者的開(kāi)發(fā)環(huán)境太“遠(yuǎn)”，開(kāi)發(fā)者響應(yīng)處理成本較高。

如果將兩者進(jìn)行結(jié)合，可能會(huì)事半功倍，效果如下圖所示：

常用的代碼提交檢查方法一般是?husky?與?lint-staged 結(jié)合，在代碼 Commit 時(shí)，通過(guò) githook 觸發(fā)對(duì) git 暫存區(qū)文件的檢查。但考慮到團(tuán)隊(duì)現(xiàn)有工程數(shù)量龐大、存在大量行數(shù)較多的文件，雖然?lint-staged?策略能夠降低部分成本，但仍稍顯不足。為此，我們對(duì)該方法進(jìn)行優(yōu)化，定制了本地代碼提交檢查工具?precommit-eslint，其核心特點(diǎn)是：

將增量檢查執(zhí)行到代碼行這一粒度，支持 Warn 和 Error 兩個(gè)檢查級(jí)別。

只需將工具安裝為工程的依賴(lài)，無(wú)需任何配置。

減少了 pre-commit hook 中植入腳本的侵入性。

進(jìn)行了執(zhí)行狀況埋點(diǎn)和采集。

使用效果如下圖所示：

在美團(tuán)，我們使用自主開(kāi)發(fā)的 CI 系統(tǒng)，并在獨(dú)立部署的 Sonar 系統(tǒng)上定制化實(shí)現(xiàn)了相應(yīng)規(guī)則，基本可以滿(mǎn)足訴求，這里就不再贅述。對(duì)于獨(dú)立的團(tuán)隊(duì)，基于 ESLint 提供的工具，可以很容易的實(shí)現(xiàn)使用 Node 快速搭建一個(gè)代碼檢測(cè)服務(wù)或平臺(tái)，大家有興趣不妨一試。

這個(gè)模塊主要通過(guò) CLI 工具提供方案自動(dòng)化接入的能力，降低工程接入和升級(jí)的成本。如果不借助自動(dòng)化工具，在工程中接入上述方案還是有一定的工作量和復(fù)雜度的，大致步驟如下：

安裝 Eslint。

根據(jù)項(xiàng)目類(lèi)型安裝對(duì)應(yīng)的 ESLint 規(guī)則配置 npm 包。

根據(jù)項(xiàng)目類(lèi)型安裝相關(guān)的插件、解析器等。

根據(jù)項(xiàng)目類(lèi)型配置 .eslintrc 文件。

安裝代碼提交檢查工具。

配置 package.json。

測(cè)試及修復(fù)問(wèn)題。

在這個(gè)過(guò)程中，特別需要注意依賴(lài)的版本問(wèn)題：依賴(lài)之間的版本兼容性，例如?typescript?和?@typescript-eslint/parser?之間的兼容性；依賴(lài)對(duì)規(guī)則的支持性，比如某個(gè)版本的插件中去除了對(duì)某個(gè)規(guī)則的支持，但規(guī)則配置中仍然配置了該規(guī)則，此時(shí)配置就會(huì)失效。對(duì)于 ESLint 不熟悉的開(kāi)發(fā)者而言，在配置的過(guò)程中都會(huì)或多或少遇到兼容性、解析異常、規(guī)則無(wú)效等問(wèn)題，反復(fù)排查和定位問(wèn)題會(huì)浪費(fèi)大量的精力。

因此，在設(shè)計(jì)開(kāi)發(fā)自動(dòng)化接入工具時(shí)，我們綜合考慮了操作步驟、依賴(lài)版本、規(guī)則集和工程方案的兼容性，設(shè)計(jì)了如下的工作流程：

該工具流程簡(jiǎn)單，不管什么開(kāi)發(fā)場(chǎng)景和框架選型，繁瑣的接入流程都可以簡(jiǎn)化為一條命令，需要配合工程方案升級(jí)時(shí)同樣如此。如下圖所示，執(zhí)行該命令后項(xiàng)目就完成了 ESLint 的接入，使用統(tǒng)一的規(guī)則規(guī)范編碼，同是在代碼提交時(shí)自動(dòng)進(jìn)行增量檢查：

統(tǒng)計(jì)分析的主要目的是掌握方案應(yīng)用執(zhí)行狀況和效果，理論上應(yīng)當(dāng)支持工程和大盤(pán)兩個(gè)視角，如下圖所示：

執(zhí)行情況分析其實(shí)并不復(fù)雜，核心是信息采集和分析。在本方案中，信息采集通過(guò) precommit-eslint 工具實(shí)現(xiàn)：在 git commit 觸發(fā)本地代碼檢查后，腳本會(huì)把檢查結(jié)果（包括檢查是否通過(guò)、錯(cuò)誤或警告信息的數(shù)量級(jí)別等）上報(bào)；信息的統(tǒng)計(jì)分析借助日志上報(bào)分析平臺(tái)實(shí)現(xiàn)，美團(tuán)使用的是 CAT 平臺(tái)（如果團(tuán)隊(duì)或公司沒(méi)有專(zhuān)門(mén)的平臺(tái)，可以在上文提到的代碼檢測(cè)服務(wù)平臺(tái)中實(shí)現(xiàn)這部分功能）。為了便于數(shù)據(jù)的聚合分析，我們將一次代碼提交檢查中出現(xiàn)的問(wèn)題數(shù)量進(jìn)行了分級(jí)：

檢查通過(guò)：檢查無(wú)代碼規(guī)范錯(cuò)誤。

錯(cuò)誤 1 級(jí)：檢查出代碼規(guī)范錯(cuò)誤數(shù)量小于 10 個(gè)。

錯(cuò)誤 2 級(jí)：檢查出代碼規(guī)范錯(cuò)誤數(shù)量在 10 - 100 個(gè)之間。

錯(cuò)誤 3 級(jí)：檢查出代碼規(guī)范錯(cuò)誤數(shù)量在 100 - 1000 個(gè)之間。

錯(cuò)誤 4 級(jí)：檢查出代碼規(guī)范錯(cuò)誤數(shù)量大于 1000 個(gè)。

比如下圖中，201903 第一周的代碼提交檢查結(jié)果統(tǒng)計(jì)（綜合采樣率 0.2），很明顯，所有檢查失敗的提交中，錯(cuò)誤數(shù)量在 10 個(gè)以?xún)?nèi)的占比最大，修復(fù)成本不高。

1.提交檢查異常分布（僅篩選檢查未通過(guò)信息）

2.提交檢查警告信息分析

除此之外，還可以對(duì)單一工程，在更細(xì)的時(shí)間粒度上去觀(guān)察提交檢查的執(zhí)行情況。

效果質(zhì)量主要分析工程質(zhì)量的變化：一方面可以通過(guò)代碼檢查執(zhí)行通過(guò)率變化趨勢(shì)、檢查結(jié)果分布去看持續(xù)的生產(chǎn)流程中，代碼質(zhì)量是否有所提升；另一方面，由于代碼檢查采用增量模式，需要對(duì)工程代碼進(jìn)行整體分析，得到工程整體的不規(guī)范代碼占比及變化趨勢(shì)，從而從工程維度分析判斷質(zhì)量效果（涉及到權(quán)限相關(guān)問(wèn)題，目前團(tuán)隊(duì)中未采用工程分析的方法）。具體的分析會(huì)在方案應(yīng)用效果中一并進(jìn)行介紹。

除了上述整體方案外，為保證開(kāi)發(fā)者使用更方便，我們還進(jìn)行了一些配套工作：

持續(xù)維護(hù)升級(jí)：以每月一版的方式持續(xù)迭代升級(jí)，解決應(yīng)用中的問(wèn)題、規(guī)則爭(zhēng)議，以及支持新的規(guī)則或方案。

工程化集成：整套方案可以無(wú)縫接入到各個(gè)團(tuán)隊(duì)的腳手架工具中，自動(dòng)成為團(tuán)隊(duì)的默認(rèn)方案，在工程初始化階段即可完成接入。

官網(wǎng)建設(shè)：提供詳細(xì)的使用文檔，包括規(guī)則信息、接入方法，并且對(duì)每個(gè)版本提供規(guī)則、環(huán)境依賴(lài)、changeLog 等詳細(xì)說(shuō)明。

常見(jiàn)使用問(wèn)題：更新維護(hù)FAQ，幫助后續(xù)接入者快速查找并解決問(wèn)題。

目前，該套方案已經(jīng)接入美團(tuán)外賣(mài)、餐飲平臺(tái)、閃購(gòu)、榛果、金融等多個(gè)團(tuán)隊(duì)，基于埋點(diǎn)統(tǒng)計(jì)分析，我們（基于2019年2月份最后一周統(tǒng)計(jì)數(shù)據(jù)分析，綜合采樣率0.2）得到了如下數(shù)據(jù)：

截止到2019年2月底，該方案已接入超過(guò) 200 個(gè)前端工程。

集成檢查（增量）每天執(zhí)行接近 1000 次。

集成檢查（增量）平均每天檢查出錯(cuò)誤約 20000-25000 處。

集成檢查代碼質(zhì)量：平均通過(guò)率為 75.562%，錯(cuò)誤 1 級(jí)的比率為 15.644%，在所有未通過(guò)檢查中占比 64.015%。

同時(shí)，我們持續(xù)統(tǒng)計(jì)上述數(shù)據(jù)的變化趨勢(shì)，跟蹤代碼質(zhì)量提升效果，以2018年12月到2019年3月的數(shù)據(jù)為例（截止2019年3月第一周，以周為時(shí)間統(tǒng)計(jì)尺度）：

從圖中可以看出，最近三個(gè)月檢查通過(guò)率整體呈上升趨勢(shì)，但 2019 年 1 月的第 2 周和第 3 周集成檢查通過(guò)率有明顯下降。分析項(xiàng)目信息發(fā)現(xiàn)，在 2019 年 1 月的第 2 周有一批新項(xiàng)目接入，代碼檢查規(guī)范檢查出幾十個(gè)錯(cuò)誤。但整體來(lái)看，目前集成檢查通過(guò)率基本穩(wěn)定在 75% - 80%，從變化趨勢(shì)看仍有上升空間。

方案實(shí)施之后，我們做了一個(gè)用戶(hù)調(diào)研，發(fā)現(xiàn)整體方案的運(yùn)營(yíng)正在發(fā)揮著正向的作用。一方面，在一定程度上提升了多人協(xié)作的效率，無(wú)論是共同維護(hù)一個(gè)工程還是在多個(gè)工程間切換，避免了代碼風(fēng)格不一致帶來(lái)的可讀性成本和格式化風(fēng)險(xiǎn)；另一方面，會(huì)幫助大家發(fā)現(xiàn)和避免一些簡(jiǎn)單的語(yǔ)法錯(cuò)誤。

該方案已經(jīng)穩(wěn)定應(yīng)用，除了現(xiàn)有功能，我們還在思考是否可以更進(jìn)一步的優(yōu)化，提供更豐富的能力。由此規(guī)劃了一些仍未落地的方向：

擴(kuò)展支持 HTML 和 CSS 的代碼風(fēng)格檢查：雖然近幾年前端框架、組件庫(kù)的建設(shè)一定程度上減少了業(yè)務(wù)開(kāi)發(fā)中（尤其是中后臺(tái)業(yè)務(wù)）對(duì) HTML 和 CSS 的需求，但是規(guī)范 HTML 和 CSS 的代碼風(fēng)格仍是必要的。基于此，可以用同樣的思路將 HTML 和 CSS 的代碼靜態(tài)檢查方案集成到當(dāng)前的方案中，不再局限于 JavaScript（或 TypeScript）。

進(jìn)一步的封裝：目前整體方案會(huì)將所有依賴(lài)和配置暴露在工程內(nèi)，如果將其完全封裝在一個(gè)工具內(nèi)會(huì)更便于應(yīng)用，但難點(diǎn)在于兼顧靈活性、對(duì)編輯器的支持等問(wèn)題。

增加工程維度的代碼質(zhì)量趨勢(shì)分析：目前代碼檢查策略是增量檢查，可以對(duì)接入的工程定期全量檢查，基于時(shí)間線(xiàn)分析工程的代碼質(zhì)量變化趨勢(shì)。

進(jìn)一步深入分析檢查結(jié)果和統(tǒng)計(jì)數(shù)據(jù)，發(fā)現(xiàn)一些潛在問(wèn)題，為推動(dòng)開(kāi)發(fā)質(zhì)量提升提供輔助，如：

統(tǒng)計(jì)開(kāi)發(fā)者在工程中關(guān)閉或調(diào)整的規(guī)則，分析占比較高的規(guī)則被關(guān)閉的原因，進(jìn)而調(diào)整規(guī)則或推動(dòng)規(guī)則的執(zhí)行。

統(tǒng)計(jì)分布檢查出錯(cuò)誤的規(guī)則分布，梳理出最常出問(wèn)題的代碼規(guī)則，發(fā)布對(duì)應(yīng)的最佳實(shí)踐或手冊(cè)。

以上是美團(tuán)外賣(mài)團(tuán)隊(duì)在 ESLint 方案規(guī)?；瘧?yīng)用過(guò)程中的一些實(shí)踐，歡迎大家提出建議，一起溝通交流。

宋鵬，美團(tuán)外賣(mài)事業(yè)部終端研發(fā)工程師。

美團(tuán)外賣(mài)事業(yè)部終端團(tuán)隊(duì)，負(fù)責(zé)的多個(gè)終端和平臺(tái)直接連接億萬(wàn)用戶(hù)、數(shù)百萬(wàn)商家和幾萬(wàn)名運(yùn)營(yíng)與銷(xiāo)售，目標(biāo)是在保障業(yè)務(wù)高穩(wěn)定、高可用的同時(shí)，持續(xù)提升用戶(hù)體驗(yàn)和研發(fā)效率。

在用戶(hù)方向上，構(gòu)建了全鏈路的高可用體系，客戶(hù)端、Web前端和小程序等多終端的可用性在99%左右；跨多端高復(fù)用的局部動(dòng)態(tài)化框架在首頁(yè)、廣告、營(yíng)銷(xiāo)等核心路徑的落地，提升了30%的研發(fā)效率；

在商家方向上，從提高進(jìn)程優(yōu)先級(jí)、VoIP Push拉活、doze等方面進(jìn)行?；疃ㄖ?，并提供了Shark、短鏈和Push等多條觸達(dá)通道，訂單到達(dá)率提升至98%以上；

在運(yùn)營(yíng)方向上，通過(guò)標(biāo)準(zhǔn)化研發(fā)流程、建設(shè)組件庫(kù)和Node服務(wù)以及前端應(yīng)用的管理與頁(yè)面配置等提升10%的研發(fā)效率。

團(tuán)隊(duì)有多個(gè)崗位正在招聘，歡迎加入我們，聯(lián)系郵箱 [email protected] ，注明 “外賣(mài)終端團(tuán)隊(duì)”。