歷時大半年，Github團隊成功減少30kb依賴體積
你沒看錯， Github 前端團隊花費大半年時間，成功將專案依賴包體積減少30kb。
減少的部分是啥呢？ jQuery。
技術還是技術債
多年以來， Github 逐漸發展為一家擁有數百名工程師的公司。
作為一家大公司，一部分人被劃分出來從事性能優化工作。
但是，狼多肉少，哪有那麼多可優化點呢？
找新的性能優點難，找你老代碼的麻煩還不容易？
於是，團隊將目光盯向了「技術債」。
魯迅曾說過，前人用過的技術，如果阻礙後人重複造輪子，就成技術債了。
那麼該挑哪個債來還呢？ jQuery真是不二人選。 原因如下：
- 廣泛依賴，這一改起來工作量絕對有了
jQuery代表老一代web開發方式。 一下替換個新潮的，這對比，明顯！jQuery好說也有30kb，蒼蠅雖小也是肉
說干就幹，讓我們先評估下工作量。
工作量max max max
新人這時候犯嘀咕：「這工作量，我估保守點，逐步替換，一周開發，一周測試，2周上線？ ”
組長啪的一下拍桌子：「那得是996的小作坊才這麼干！ 我們大公司做事得專業，這事兒得「穩步反覆運算，增量解耦」"。
首選：我們得建立指標跟蹤，統計每行代碼中 jQuery 的調用次數。
實時監控，確保指標穩步下降。
其次，要有專人開發一個 lint （見eslint-plugin-jquery ），全團隊普及，避免大家繼續使用 jQuery 方法。
新人問：「那有人添加 eslint-disable 繞過規則怎麼辦？ ”
組長微微一笑，"小夥子，上道了啊。 ”
還得開發一個 Github 機器人，每當有人提交的新代碼中包含 eslint-disable 規則，機器人會通知團隊成員，這樣我們能儘快介入 review 代碼。
最後， jQuery 作為一個模組化的庫，為了保證「穩步移除」，我們需要維護一個自定義 jQuery 版本。
每當確定一個模組不再使用，就從自定義版本中移除他，並提供一個更小體積的版本。
比如：當完全用 fetch 替換 $.ajax 后，就能將 AJAX 模組剔除。
"這一通操作下來，沒有半年工作量，我看不行。" 組長輕靠椅背，輕輕搖了搖頭，說道。
昇華主題
你以為這就完啦？ naive～
前面做的，只能說穩步推進工作。 接下來說的，才是 KPI 的重中之重。
jQuery被移除，專案必然出現很多原生 JS 。
重複代碼多了得抽象、得封裝是吧？
"您是說上框架！ Vue還是 Angular ？ "新人搶答道。
"小啦！ 格局小啦！ "組長長嘆一口氣。
"當然是擁抱標準。 Vue的模版語法也是根據Web Components 標準演化來的。 ”
"我們要引！ 領！ 時！ 代！ ”
從現在開始，所有可復用的功能元件都封裝為 Web Components 。
比如「複製貼上」功能，要封裝為 clipboard-copy ：
<clipboard-copy for="blob-path" class="btn btn-sm BtnGroup-item">
点击复制
</clipboard-copy>
<div id="blob-path">src/index.js</div>
遵照 HTML 標準習慣，點擊 clipboard-copy 元件後會將 for 屬性指向的 id 選擇器對應內容複製到剪貼板。
並且開啟 Shadow DOM ，使元件對外封閉，不會影響其他元件。
你問相容性？ 小啦！ 格局又小啦！
我們這樣的企業就是要推動瀏覽器廠商進步的。
最終產出了有1.4k
star的Web Components元件庫github-elements
後記
經過大半年的努力， Github 團隊成功將 jQuery 從項目依賴中根除，減少 30kb 依賴體積。
如果你審查 Github 頁面代碼，會時不時看到 Web Component ，比如：
大公司的工作方法論，你學廢了嗎？