前端小團隊如何搞基礎設施建設？

前言

我爲何會思考這個問題？這得從一篇演講稿提及：

上文最初大概是在2020年四、5月份的時候看到的（當時仍是在語雀上，不過如今連接已經失效，好在知乎上面還找獲得），做者在上述演講稿中詳盡地介紹了其團隊在一年多的時間內如何從零到一構建了龐大的前端基礎設施體系，以及這些基礎設施到底起到了多大的做用；整篇演講稿看完真是使人恍然大悟，原來前端能夠如此高效以及成體系，看完後我真是對該團隊擁有的前端基礎設施垂涎三尺，而後臆想了一下在如此高效的前端體系中工做應該是一件很幸福的事情。

不過，考慮到文中這種龐大的、成熟的前端基礎設施是創建在龐大的前端團隊以及超多的前端業務場景的積累下建設而成的，那麼小團隊怎麼辦？

因而很天然地我就想到了這個問題，也在一直試圖尋找這個問題的答案；在通過2020年內大半年的在團隊內部的基建實踐（比較初級）後，我想也許是時候回答和整理這個問題的思路了。

小團隊的現實問題

考慮到現實，畢竟大多數前端團隊不像大廠那樣有豐富的團隊人員配置，大多數仍是很小的團隊，小團隊在實施基建時就不可避免的遇到很現實的阻力：

• 最大的阻力應該就是受限於團隊規模小，沒法投入較多精力處理做用於直接業務之外的事情
• 其次應該是團隊內部對於基建的必要性和積極性認識不夠（夠用就行的思想）

小團隊基建的必要性

綜合上面的現實問題，是否就能夠認爲前端基建就是大廠/大團隊的專屬權利和義務呢？畢竟看起來有點沒法下手和吃力不討好的樣子；

在我看來，所謂的基建就是一切能夠提高編碼效率、團隊協做效率及業務魯棒性的工具和方法的集合；只要是項目還在迭代、擴展，就不可避免地遇到新的問題以及效率瓶頸，更不用說不少項目內的業務痛點；目前不少的項目內問題解決路徑就是：直到問題出現纔會去解決問題（甚至是到問題嚴重的時候纔會去解決問題）；

這就是基建最核心的價值：幫助業務更好的活在將來。1

我很認同上面這句話，基建不只能夠幫助提高當下的效率，還能夠避免一些問題的出現，以便業務更好地可持續發展；

小團隊應該建設哪些基礎設施？

考慮到基建的必要性和小團隊的現實問題，我給出的答案是：

• 優先級：優先發展投入產出比大的地方
• 範圍：着眼於自身業務沉澱及業務需求
• 自動化程度：量力而行，不要一開始就追求大團隊所擁有的成體系的自動化前端基建，推薦「局部研發鏈路的自動化」

在設計工具的相關交流中，咱們還發現了有的團隊開始把交互相關的功能也作了進去，例如將頁面跳轉，後端處理流程邏輯等進行了可視化編輯，自動生成相應的接口和流程代碼。這種探索能夠歸納成：「局部研發鏈路的自動化」。它是一個初期提效頗有用的方法。在對外交流中咱們發現了兩點有用的建議：

一是任何團隊均可以而且也都應該作，沒必要以爲本身團隊研發實力不夠，等大公司推出相應方案。局部自動化的關鍵其實對本身的業務和人員分工的一種總結和思考。在技術上，當本身的業務相對肯定時，經過一些簡單的方法就能實現。而大公司要考慮的大而全，不必定適合。在人員組織上，幾乎全部的自動化方案都有必定的分工要求，這也是因組織而異的。局部的自動化是以後總體架構變革的關鍵前提。2

投入產出比較大的地方

• 規範文檔：我的以爲規範文檔應當是整個基建中的靈魂，由於規範文檔能夠看作是整個團隊的共識，在沒有共識的狀況下開展基建難免會遇到不少不理解的地方；並且制訂相應的規範能夠先參考業界經常使用的，而後再具體討論內部的細節，花費的時間不須要太多，可是帶來的收益絕對是極大的（有效地提高團隊協做共識和效率）；
• 業務（通用）組件：前端項目隨着業務擴展，就會天然地抽象出能夠被複用的業務組件，這也是一種業務沉澱；不過我的以爲組件的產出流程應該歸入基建中，加以規範和流程化，不然容易形成組件複用率不高、擴展性不強，耦合度太高等問題；
• 工具函數：實際上跟業務組件相似，只是組件在前端項目內偏向於視圖層，而工具函數就是邏輯層，一樣地工具函數的產出流程也應當規範化；
• 代碼檢測：這個其實是配合代碼規範文檔進行的一種輔助手段，由於口說無憑，規範畢竟不是一種實體性質的東西，實際編碼過程當中可能出現不遵照和遺忘代碼規範的狀況，若是缺少一種強制手段來檢測規範的執行，那麼代碼相關的規範約束力就會大打折扣；事實上，現在社區已經存在各類相應成熟的代碼檢測工具，只須要根據內部約定的規範作一些修改配置就夠了；
• 腳手架：當公司業務項目之間出現高度的類似時，則能夠利用腳手架將以前沉澱的項目配置規範化，完成項目建立流程的規範化，能夠知足項目快速建立的目的，且項目初始化工做顯著減小還能夠複用已經沉澱的一些項目配置；

基建實踐

說了這麼多，那麼如何在項目中實施前端基建呢？這裏以我在內部的某個項目實踐爲例：

• 項目背景：APP配套使用的業務後臺；前期工做是從老項目中遷移（重構），後期加入各類新增模塊；
• 項目特色：模塊繁多，某些模塊功能類似度很高，表單複雜度較大；

上圖就是我在項目中大概作的一些基建相關實踐的概況；

公共組件產出流程

渲染模型/DSL

其餘

• 解決多分支並行開發公共文件維護的幾種方案 | snowdream

基建的效果

• 團隊協做效率提高，規範性明顯加強
• 經過前期組件/公共的積累和沉澱，後續開發速度明顯提高（搭積木式開發）
• 代碼複用率明顯提升，減小複製粘貼次數

後話

嘗試基建能夠收穫不少

在項目中積極實踐/推動基建後我才發現，原來嘗試基建能夠收穫到不少東西：

• 對前端項目總體會有更深、更本質的認識，可以找出更多的業務及編碼痛點
• 能夠拓展提效的更多思路，接觸到更多高效的編碼體系及工具
• 能夠增強全局觀念，認識到各類架構、解決方案的具體適用場景，而後嘗試提出更適用於具體業務場景下的架構及解決方案

簡言之，積極嘗試基建不只能夠對當下項目提效，還能提高自我解決問題的能力；在這不到一年的實踐中腦海裏已經閃出了各類各樣的解決方案，有的是已經應用了，更多的則是還在探索和檢驗中，總之收穫了不少靈感：

• 
  

基建沒有終點

我我的以爲只要是項目還在發展/迭代，基建就沒有終點；這一點從大廠的實踐來看也是同樣的，大廠們正齊步從可視化搭建（半自動化）邁向智能化搭建（全自動化）的探索之路；