我為什麼會思考這個問題？這得從一篇演講稿說起：
前端搞基建|堂主 - 如何推動前端團隊的基礎設施建設 - 知乎
上文最初大概是在2020年4、5月份的時候看到的（當時還是在語雀上，不過現在鏈結已經失效，好在知乎上面還找得到），作者在上述演講稿中詳盡地介紹了其團隊在一年多的時間內如何從零到一構建了龐大的前端基礎設施體系，以及這些基礎設施到底起到了多大的作用；整篇演講稿看完真是令人恍然大悟，原來前端可以如此高效以及成體系，看完後我真是對該團隊擁有的前端基礎設施垂涎三尺，然後臆想了一下在如此高效的前端體系中工作應該是一件很幸福的事情。
不過，考慮到文中這種龐大的、成熟的前端基礎設施是建立在龐大的前端團隊以及超多的前端業務場景的積累下建設而成的，那麼小團隊怎麼辦？
於是很自然地我就想到了這個問題，也在一直試圖尋找這個問題的答案；在經過2020年內大半年的在團隊內部的基建實踐（比較初級）後，我想也許是時候回答和整理這個問題的思路了。
考慮到現實，畢竟大多數前端團隊不像大廠那樣有豐富的團隊人員配置，大多數還是很小的團隊，小團隊在實施基建時就不可避免的遇到很現實的阻力：
綜合上面的現實問題，是否就可以認為前端基建就是大廠/大團隊的專屬權利和義務呢？畢竟看起來有點無法下手和吃力不討好的樣子；
在我看來，所謂的基建就是一切可以提公升編碼效率、團隊協作效率及業務魯棒性的工具和方法的集合；只要是專案還在迭代、擴充套件，就不可避免地遇到新的問題以及效率瓶頸，更不用說很多專案內的業務痛點；目前很多的專案內問題解決路徑就是：直到問題出現才會去解決問題（甚至是到問題嚴重的時候才會去解決問題）；
這就是基建最核心的價值：幫助業務更好的活在未來。[1]我很認同上面這句話，基建不僅可以幫助提公升當下的效率，還可以避免一些問題的出現，以便業務更好地可持續發展；
考慮到基建的必要性和小團隊的現實問題，我給出的答案是：
在設計工具的相關交流中，我們還發現了有的團隊開始把互動相關的功能也做了進去，例如將頁面跳轉，後端處理流程邏輯等進行了視覺化編輯，自動生成相應的介面和流程**。這種探索可以概括成：「區域性研發鏈路的自動化」。它是乙個初期提效很有用的方法。在對外交流中我們發現了兩點有用的建議：
一是任何團隊都可以並且也都應該做，不必覺得自己團隊研發實力不夠，等大公司推出相應方案。區域性自動化的關鍵其實對自己的業務和人員分工的一種總結和思考。在技術上，當自己的業務相對確定時，通過一些簡單的方法就能實現。而大公司要考慮的大而全，不一定適合。在人員組織上，幾乎所有的自動化方案都有一定的分工要求，這也是因組織而異的。區域性的自動化是之後整體架構變革的關鍵前提。[2]說了這麼多，那麼如何在專案中實施前端基建呢？這裡以我在內部的某個專案實踐為例：
專案特點：模組繁多，某些模組功能相似度很高，表單複雜度較大；
上圖就是我在專案中大概做的一些基建相關實踐的概況；
在專案中積極實踐/推進基建後我才發現，原來嘗試基建可以收穫到很多東西：
簡言之，積極嘗試基建不僅可以對當下專案提效，還能提公升自我解決問題的能力；在這不到一年的實踐中腦海裡已經閃出了各種各樣的解決方案，有的是已經應用了，更多的則是還在探索和檢驗中，總之收穫了很多靈感：
我個人覺得只要是專案還在發展/迭代，基建就沒有終點；這一點從大廠的實踐來看也是一樣的，大廠們正齊步從視覺化搭建（半自動化）邁向智慧型化搭建（全自動化）的探索之路；
前端搞基建|堂主 - 如何推動前端團隊的基礎設施建設 - 知乎
↩︎長夜未央——企業級研發提效的下一階段 - 知乎
↩︎
也談前端基礎設施建設
克軍昨天的分享不錯 前端基礎架構的實踐和思考 從 2009 年起，也一直在想這些事。受剋軍啟發，梳理成一張圖 幾點說明 將 架構 換成了 設施 對應的英文是 infrastructure.感覺用 設施 更能精準表達原意。克軍的大分類是設施的形態 是乙個工具，還是乙份規範，或是乙個系統。這樣分類不錯，...
前端基礎設施搭建
為了方便前端小白能夠從零基礎的適應專案，跟著我一步一步來搭建專案，更快的入門，不會因為某個點卡住。也方便後期部落格前端專案，如果環境出現問題，或者需要注意的地方也會同步更新。安裝後，在cmd中輸入node vnpm v出現版本號說明配置成功 大約2分鐘 vue cli是vue腳手架工具，方便打包，部...
阿里雲如何設定基礎設施DDoS防護？
ddos高防例項的流量黑白名單用於封禁或者放行來自指定源ip的四層訪問流量。根據業務需要為ddos高防例項單獨配置流量黑名單 白名單，例如新增 移除ip。流量黑名單中也包含ddos高防智慧型防禦演算法標記的惡意ip。同時，流量黑白名單支援匯出到本地。本文分享流量黑白名單的具體操作方法。更多參閱官方文...