前言
這是前端早早聊舉辦的第二屆大會，也是我第一次參加線上前端分享。這次大會讓我開闊了眼界，瞭解了前端在各個公司的不同玩法，加深了對技術管理的認知。如果說寫程式碼是低頭走路，那麼學習不同團隊的基建思路就是仰望星空，讓我們在高速發展的前端的道路上不至於迷失方向。
下面我將從以下五個方面來聊前端基建的話題，希望能夠引起你們更多的思考。
一、基建工作都有哪些內容
基建的內容這個話題其實可大可小，不同的團隊規模有不同理解，不同的公司規模也會有不同的要求。下面我會從基礎到複雜做簡要的說明，其中的每個點說的並不全面，拋磚引玉，歡迎大家在團隊實踐中補充完善。
程式碼層面
- 檔案、資料夾、變數命名規範，大駝峰、小駝峰、下劃線命名發、首位不能出現數字等等
- 檔案拆分的基本要求，比如一個程式碼檔案超過400行，必須要拆分成不同的包，抽離不同的類
- 專案中禁止出現冗餘程式碼，禁止出現無效的變數和無意義的命名
- 禁止同樣功能的包在一個專案中共存，如axios和jquery的ajax共存
- 超過4k的圖片必須用外鍊形式引入
- eslint、tslint、prettier對程式碼規範的約束
- 單元測試、UI測試、全鏈路壓測......
- 新技術調研，新技術分析
- .......程式碼規範其實是一個很大的話題，不同團隊也有不同要求只要大家都能接受的就是適合自己團隊的
發版規範
- git flow的相關規範，commit的規則
- 分支管理和命名規則
- 發版的整個流程設計，流程是否合規，是否能幫助大家規避一些長犯的錯誤
- 發版前是否要做自動化測試
- 測試環境、預生產環境、生產環境的發版和迴歸測試要求，比如：任何一次發版結束都要去對應的環境看頁面是否能開啟，介面是否能跑通。
開發規範
- 新建開發專案的專案倉庫模板/基礎開發框架/技術找是否統一，是否具備視覺化搭建的必要
- 整個專案新建和釋出流程是否完整順滑
- 相應的除錯工具是否高效
- 如果有自研或者第三方元件庫，元件庫是否有統一，有什麼樣的要求
- 編輯器外掛是否統一，大家標準是否一致
工程化和元件化
- 工程程式碼規範，倉庫、程式碼、釋出、文件、測試、開源方面的規範
- 工程構建規範、針對不同技術棧和不同框架的jenkins打包發版一條龍構建、或者自研視覺化的工程釋出規範、gitlab CI/CD
- 內部自研的針對各個平臺的打包指令碼和部署指令碼，實現自動化部署
- 適用於各個平臺的元件化，PC/Mobile/RN/Flutter/小程式等等
- 不同技術棧/React/RN/Vue/小程式的前端基礎框架，小團隊儘量選單一的，大團隊可以百花齊放
- 業務元件和UI元件結合使用，實現快速開發
- 視覺化的元件拖拽實現頁面快速開發，讓非技術人員也具備基本的開發能力
- 元件和框架釋出流程和管理流程
- node端的web框架
- 全棧路由監控
統計監控
- 部署過程監控
- 端行為資料監控
- 資料採集、埋點設計
- 前後端錯誤日誌的抓取應用
- 效能分析,要匹配相應的效能分析工具
- 監控SDK
安全防控
- 程式碼安全監測
- 行為安全監測
- 端異常回溯指派
- 第三方安裝包安全監測
- XSS/CSRF安全攻擊
文件沉澱
- 編碼規範、命名規範、Git規範、流程規範、效能規範、資料規範、埋點規範、安全規範
- 元件規範、工程規範、開源規範、文件規範、
- 業務文件、技術文件、分享沉澱文件、新人文件 視覺化搭建
- 以上所有的功能有些做出來就是視覺化的，有些用指令碼就可以跑，當團隊規模足夠大的時候，是需要做視覺化工具的，讓大家可以更直觀的使用所有的功能
二、基建的意義何在---為了解決什麼問題
不同的團隊規模、不同的團隊水平和不同的業務體量決定了基建在這個團隊中的意義。脫離以上三點實際情況談基建是沒有任何意義的，下面的第三部分會做詳細分析。下面我們拋開上述條件來談談基建的意義。
解決業務問題（也是最核心最基礎的問題）
- 把握當下，解決當下的業務問題，是業務的支撐
- 提高效率，基建可以提高單個人的工作產出和工作效率，可以從程式碼層面解決一些普遍性和常用性的業務問題
- 提高質量，基建可以提高整個團隊的程式碼質量
- 合理架構，架構的抽象性和合理性是影響產出比的重要因素
- 流程制度，優異的流程制度必將帶來正面的、積極的、有實效的業務支撐
- 活在未來，應對未來業務爆發的可能性，
實現團隊練兵
- 技術方案選型和調研能快速提高團隊成員的技術水平擴寬技術視野
- 專案管理可以讓小夥伴們有強烈的自我驅動意識，發揮主觀能動性，提高團隊活力
- 培養產品化思維，一個基建的點可能就是一個完整的專案，負責人從開始到落地整個過程都是自己主導，可以培養產品思維，對整個行業的鏈條會有更加深刻的認知能力
梯隊建設
- 千人一面寫業務程式碼，大家的水平最終會趨同，團隊沒有技術梯隊
- 有人是業務的核心開發者，有人是元件的核心開發者，有人是工程化搭建的核心開發者，分門別類，大家技術棧不同，技術側重點不同。從生物學角度來說，多樣化也是生命力的表現，一個生態，多樣化越明顯，生命力越頑強
影響力建設
- 技術沉澱，技術沉底也是一個團隊的技術底蘊，是實力的象徵
- 技術分享，包括團隊內部的分享和團隊外部的分享
- 產品體驗，沉澱一些優秀的互動，一些優秀的UI視覺，產品體驗更友好
- 開源體驗，讓更多人人瞭解團隊，使用你的技術，增加公司的影響力
三、不同團隊的發展階段以及基建的側重點分析
前面說過脫離實際情況談基建是沒有任何意義的。基建需要從問題出發做事情，跟隨團隊一起成長。下面會從5個方面談團隊發展和基建的側重點之間的關係。
上古時代
這個時期的團隊規模一般都在1-3人左右，，具體數字完全靠自己估計，不要深究合理性。可能公司也是發展的早期，整個技術部或許也就20人以內。業務量來說，可能有一款核心的產品，兩個粗糙的運營工具，三四個輔助的專案支撐業務。我通常會認為這個階段是不需要一步到位做基建的。
首先要做的是程式碼層面的規範，能初步確保程式碼質量過硬就好了，需要leader經常抽出時間做程式碼review，幫助小夥伴們提高程式碼的質量，嚴把質量關。其次可以做一些簡單的程式碼規範文件，專案中融入一些業務說明文件，沒有能力構建視覺化發版工具的可以考慮用指令碼發版，畢竟指令碼發版並不見得有多低階。視覺化和工程化構建不也是建立在指令碼之上麼，這個無可厚非。
反過來說，你花了大量的人力資源，協調了多個部門終於做了視覺化建設和工程建設，但是公司遲遲不做新專案，業務量遲遲不增加，其實有點大材小用了，對業務的提效並不明顯，得不償失。不過，對個人來說這個階段做基建是提升個人能力的關鍵時期，個人能力必將會有大幅度提高，為以後應對公司騰飛打下堅實的基礎。
工具時代
這個時期的團隊一般會在4-8人左右吧，具體數字完全靠自己估計，不要深究合理性。公司業務也會以億為規模計算，公司人數在100-500左右。涉及到的各種toB專案和toC專案會有幾十個。這個階段的團隊應該已經在早期沉澱了一些東西，也算是有家底的團隊了。
這個時候的團隊為了支撐不算海量的業務，會去有意識的嘗試使用不同的工具，助力業務開發。同時，大家也會發現不同技術棧帶來的理解成本和開發成本劇增，是時候要進行技術棧的統一了，團隊裡應該會有一些大牛，積極推進工程化建設，元件建設初具規模，抽象出來的工具庫初步具備體系，開始考慮搭建私有的npm倉庫，開始考慮完善相關的的技術文件，甚至開始考慮做一個專門的網站承載一些文件，幫助團隊成員開發速查，幫助新人儘快瞭解團隊整體技術水平。
同時，開始用gitlab/CL/CD或者jenkins來做自動化建設，解放人力。專案越來越多，線上程式碼異常難以定位，總是花費大量人力維護老專案也力不從心，這時候你會想著去做一些監控的事情，幫助團隊發現程式碼中的問題，提高程式碼的健壯性。leader會有意識的推動各種元件和工具的npm化，方便後期維護，同事也可以極大提高開發效率，保障程式碼質量。
羅馬不是一天建成的，這個時期對團隊轉型來說，對喜歡的人來說充滿了刺激，對不喜歡的人來說可能就是噩夢，在打破慣性思維的道路上，必定會遇到阻力，推進工具時代的發展必定會耗費大量的心力，但是收益也是巨大的。
工程時代
這個時期的團隊一般會在10-30人左右，具體數字全靠自己估計，不要深究合理性。公司業務會以十億規模計算，公司人數可能在500人-1000人左右。涉及的應用應該在上百個左右。當然也不乏提前佈局的leader，在業務量沒達到這個規模的時候就做了工程化的建設。
這個時候的團隊應該會有一些資深大牛，他們對業務有深入的瞭解，能夠左右業務的決策，能夠把控專案的進度，同時避免一些雷區。團隊的技術生態應該是百花齊放的，同時內部以小組為單位實現技術棧的統一。對於一些普適性和高頻的業務邏輯應該可以實現api化，通過調相應的業務元件或者相應的功能性檔案包實現快速開發。作為一線的程式設計師只需要去關注具體的業務邏輯，不需要去關注具體的技術細節。
在海量技術文件的幫助下，即使是新來的員工，也能快速完成開發。運營通過視覺化的開發平臺，可以實現元件的拼裝，從而完成功能開發，通過一鍵發版，進行測試和上線，程式設計師在這裡起到輔助的作用。這個時候的基礎架構應該已經有很多的積累，大多數專案都可以實現拿來即用的程度。箱子裡的工具多了，做什麼都比較順手。前端從造工具進入用工具的階段。
智慧時代
這個時期的前端團隊規模應該在50人以上，具體數字全靠自己估計，不要深究合理性。公司業務會以千億規模計算，公司人說會在1000-100000之間。涉及的應用可能沒有一個人真正的去統計過，因為實在太多了。
這個階段的一些leader或者資深技術可能需要進入深度的商業發現或者商業決策。基礎設定除了上面的拿來即用，更多的是實現智慧化，設計的東西能通過智慧化迅速轉化為程式碼。運營不需要再盯著前端寫程式碼，因為他們通過視覺化介面已經可以自己完成功能的開發和上線。
這個階段的團隊不僅有大量的工具，還有大量的物料，通過智慧化的方法實現無感開發。這些技術實現不僅影響到公司的技術發展，而且影響到整個行業的生態。我們期待這個時代的到來。
四、如何建設基建團隊
有的公司有專門做基建的團隊，比如架構組，運維組之類的部門；有些公司的程式設計師是一邊做基建一邊開發業務程式碼。這是兩種不同的組織形式，沒有好壞之分，只有是否適合的區別，當然其中也會涉及到一些行政干預的力量。不同的公司可以根據不同的情況進行設計。
以上兩種組織形式，歸根到底都是為了解決一個問題：怎樣找到合適的人去做合適的事？
下面來具體展開說如何建設基建團隊。
需要做什麼樣的事
- 具體要做哪些事第一部分已有說明，此處不再展開論述
- 切記要綜合評估人和事是否匹配
- 作為leader最重要的是實現資源和合理配置，發揮出最大作用
- 讓合適的人做適合的事
- leader要借人成事，同事也要借事成人，實現整體的發展提高
需要什麼樣的人
- 所做之事和當前程式設計師的技術實力是匹配的，或者說踮起腳尖可以夠得著的
- 能寫出擴充套件性比較好的程式碼sdk
- 業務開發中善於總結和分享，看的程式碼多，知道哪些程式碼是好程式碼，
- 有一定抽象和歸納總結的能力
- 喜歡折騰，保持折騰的心態。（工作經驗3年以上的，保持這種心態的人會越來越少）
- 能去了解痛點，深入瞭解業務，知道業務需要什麼樣的東西
- 溝通能力強，能把自己做的東西推廣出去
什麼性格的人
- 溝通能力強(溝通能力強不能用內向或者外向來判斷)
- 技術上稍微激進一點，喜歡用新程式碼，喜歡研究新技術
- 有同理心，可以換位思考，能站在使用者的角度思考功能的合理性和便捷性，同時要思考如何讓各個團隊實現雙贏
- 可以積極主動push一件事情推進
- 事必躬親，既要樂於主動了解業務，又能分析出業務中的痛點，通過做事發現問題，杜絕閉門造車
- 奉獻精神，要樂於奉獻自己的時間和精力去做這些難啃的硬骨頭
技術上的支援
- node的相關技能
- sh指令碼的相關技能
- 可以熟練使用各種命令列和工具
- python、c++、go等等的技能
- webpack gulp的技能
- ios或者安卓的技能
- docker技能
- ....以上根據基建的點選擇不同技術棧的同學來做
五、基建工作如何落地
基建工作的落地實施除了需要技術的熱情，同樣離不開公司CTO甚至是大Boss的支援，要多學會用資料說話，通過資料和收益來證明一件事情的必要性和可行性。這是前提，缺乏這個前提你做的事情可能並不會得到各方面的支援。
同時，基建工作的落地和選的人有密不可分的關係。如果在一開始做的時候就沒選好人，那麼基建的效果可能會大打折扣，甚至做出來的東西根本沒人用，以至於後期沒人維護沒人管。
另外要做好資料統計工作，做出的東西在交付使用之前儘量做好使用量統計工作。比如，可以統計一個元件庫在整個前端團隊的引用次數有多少，一個工具的開啟率有多高，節省了多少的人力成本，節省了多少的時間。這些東西如果能有視覺化的介面做支撐，下次再做基建立項的時候，被領導信任的概率就會大大增加。
特別宣告，以上分享內容的思想和觀點並非本人原創，而是根據各位前端大佬的分享內容整理而成，有一部分是根據自己從業幾年的理解加工整理而成，在此感謝各位大佬慷慨相授！