引言

在這片有著基建基因的土壤上聊這個簡直令人膽顫心驚，但安全。

本文老少皆宜，本著愛與和平的宗旨，不傳達任何焦慮，主要分享自身搞基建的一些案例和體會，希望能給打算做基建或正在基建建設中的伙伴們一些參考，若能幫助到你們，我也會祝你們好運！

基建是什么

內容

基建是什么，字面意思：基礎設施建設。嗯？好像等于沒說。可能很抽象，在我們的研發世界里可以是通用技術的建設，或者再具體一點，比如一個方法被調用兩次，你抽離出這個方法，沉淀下來，那這個方法就可以是通用技術。以此切入，放到場景中就衍生出了很多具體基建，本人是個前端研發，像我們就會做很多類如：前端工程化 / 數據可視化 / 多端生態 / 組件庫 / 自動化構建部署 / 性能分析 / 埋點系統 /...

上面好似很牛的樣子，可基建本不是什么高大上的詞兒，只是一句話很長，概括一下就變成兩個字兒了。

哇?? 基建好簡單誒！

有你受的。

特性

• 比業務研發更緊貼業務我們知道一般業務研發都能知道自己維護的這條線的業務模式，但公司其他業務線未必知道，而往往你的基建建設可能要支撐多條業務線，這就使得你要緊隨著公司發展的腳步，不然面試官問你 xx 業務線做什么，你就只能說：這個業務我們基建不管的。
• 訴求方比產品更難纏一般簡單的模式就是產品和研發分別生產需求和消費需求，這兩個角色平時可能看似溝通順暢、和諧相處，但也會因牛頭不對馬嘴而草草了事。

產品：你知道做什么嗎？研發：emm 我明白。我通過 xx 技術、xx 手段，最后出來的會是這樣的產品：嗯嗯好的 你能做好就行

畢竟專業上還是有區別，交流上難免有誤解和盲區。

但基建對應的訴求方很多也都是研發，你會發現，你說的她真的聽得懂，一個問題能問出八個問題來。

• 職能邊界更泛往往做基建，還承擔著技術支撐的職責，如果出現了問題不知道找哪個業務團隊，那就找基建團隊。經常聽到一句話：不是他們的，那就是你的。哦！我真的會謝

你準備好做基建了嗎

下面會分享一些案例和體會，大家酌情參考。

你做得好以終為始嗎？

以終為始，道理咱都懂，說起來簡單，嗯，說起來簡單。

做基建一般研發周期長，不像做一個業務功能，周期可能在幾天、幾周，他可能要做幾個月，規劃甚至要規劃到半年、一年的周期，我們常說研發要走在業務前面，不能業務來了，發現實現不了，而做基建要走在研發前面，比如為可預見的場景提前做好可行性探索和支撐，就是這個道理。

另一方面，很容易被業務牽著走，撿了芝麻丟了西瓜。之前我們做一個面向公司全量前端應用密集部署的系統，前期先支持 PC 應用，大部分應用都順利支持了，但有個別特例應用比較難啃，當時我們為了支持這幾個特例，調整了部分實現。正當我們覺得有階段性成果了，可現實很骨感，下一階段支持移動端應用發現不對勁，移動端流量比 PC 端流量多兩個數量級，這需要很高效的擴縮容能力。而當時的調整對擴縮容方面有很大的阻礙，這一度使得我們沒法推向移動端應用，而密集部署主要的核心也是針對移動端應用，畢竟移動端資源占比多得多。

點到為止，本想做個飛機，結果做成了拖拉機，倒也能帶人。痛！真的太痛了！

你格局夠大嗎？

最近在做無相，一個表單搭建平臺，面向公司幾乎所有的業務線，這要求我們維護者要對所有業務線負責，而不能局限于某個業務線，如果只看到局部，很容易就造成在胡同里走死的情況。所以格局打開，不要在細節上死摳，而忘了全局的模樣。目前每個月都有各種業務方的訴求得到支持，這時常提醒我們要保持好格局，不拘小節，畢竟哪個業務方爸爸都得罪不起，更不用說一堆業務方了。

你有全棧意識嗎？

你們有過這樣的經歷嗎？打開 Axure 設計流程，需要個圖片，然后打開 PS 制作圖片，再用 VSCode 進行編碼，偶爾還得充當客服答疑解惑?；ㄒ话闶莻€偏技術類產品，但未必會像業務產品一樣有足夠的產品、設計等資源。是的，這就是基建的家庭地位，啥條件啊，搞個基建這也要那也要，那怎么辦，想要出成果那就自己搞咯。所以你要有全棧意識，做好啥都要干的準備。

對了，我司的基建是有對應的產品和交互的。

你能兩只腳走路嗎？

很多基建是以平臺的方式呈現的，比如前端構建平臺、運維保障平臺等等。一般這類平臺都會涉及到兩方面：底層架構（平臺能力的實現）、平臺產品（暴露給用戶側的平臺功能）。這兩方面一定要同時進行，否則會給你帶來很多意想不到的問題。之前做的一個項目，精力都側重在了底層架構，能力具備齊全，但產品功能很簡單，只是最核心的功能。結果平臺一推出后，直接把客服系統整崩了，當然客服就是我自己，想看個數據頁面看不到，我得調用接口幫他們查；流程報錯終止了，怎么重新開發，也得手動調用接口觸發等等。

這兩方面相輔相成，不能埋頭專搞底層，也要不斷的迭代產品功能，接受用戶的反饋，再反饋推動底層的設計。

你能漸進式推進嗎？

漸進式開發大家應該都知道，漸進式推進也同樣的道理，不要想著所有業務方能很順利的接受一個新事物，除非你真的為所有業務方都帶來了很大收益?，F實更多的是先推少部分業務方、先小幅度升級，循序漸進的推進，再收集反饋來優化下次的推進，這樣可以形成正向循環。

另外，基建是需要持續驗證的，每個階段要有里程碑來驗證可行性，不可能等你開發兩個月，出來個東西發現跑不了，那么你也跑不了了。

你對邊界夠敏感嗎？

有一個明顯的感受是做基建后平時一起協作的伙伴變多了，那是因為基建可能依賴于多方資源，因而對應的邊界也會多很多，比如以下一個搭建的架構圖，大的分層這么多層，更不用說再細分的了。

圖片

可想而知，實現一個功能可能就需要多方協助，哪一層應該做什么，是否嚴格按照分工來，就變得格外重要。前不久做一個表單性能優化的事兒，一開始圍繞著渲染層進行方案設計，淺淺評估了一倆個月工作量。后面在全局架構下 review 后，發現一部分內容應該交由物料庫去做，結果一評估，渲染層和物料層各一周就可以搞定。

你的基建真的好用嗎？

是騾子是馬拉出來遛遛。架構很牛？平臺很好用？自我感覺良好沒用，還得主動拿出來讓大家檢驗。比如分享你的平臺給業務團隊，聽聽他們的聲音，他們說好自然最好，說你哪方面不行，也得認，這對你其實很重要。我很喜歡老羅，尤其是他在新品發布會上演示出現 bug 的時候，真是又驚又喜，但他從不否認問題，罵手下就行了。

定期開展架構 review，這個很有必要，看看基于以前背景下的設計是否在當下的背景依然跑的很溜，不然發現設計不適用了也是很正常的，只是要持續調整罷了。

對，只是要持續調整罷了。

你有數據嗎？

對于公司而言，肯定是要計算每個團隊的成本和營收的，而基建團隊的營收不像業務團隊有業務數據可以比較直接的推算出來，它可能需要間接計算。比如你說降本提效，到底給多少業務團隊提效了，提效了多少人力都要統計出來，這就是最直接的價值體現?；ㄗ龅亩嗯?，你沒數據，可能就等于白做。

另外，通過分析業務的數據，除了能證明自身的價值外，還可以幫助業務去糾正一些問題，比如觀測業務的一些使用狀態，產出業務維度的晴雨表。

比起口碑，老板可能更相信數據。

你確定能 hold 住問題嗎？

問題當然是解決不完了，但是問題解決不了那就是另一回事了。這取決于你方向的把控，前進步伐的控制，向來這種情況是求穩不求快，要控制在自己團隊能 cover 范疇內。比如你前期的技術棧選擇要基于團隊的技術棧，不可盲目求新，不然到時候可能一發不可收拾，問題來了四處求人，依賴的外部資源有問題，可能還得依賴于外部的進度。

當然，也許你技術很牛，這方面做的不錯，但不得不提的是還有一方面問題是答疑問題，可想而知，這方面問題會隨著業務的深入接入越來越多，這就需要你有更強的軟性技能。另外也要有意識通過各類工具來優化答疑鏈路，減輕響應成本。

你有足夠技術熱情嗎？

因為業務項目要更穩定，所以一般技術選型會更可控，并且技術層面的調整不應該很頻繁。而基建會相較更自由一點，且要走在業務開發前面，需要調研很多技術，對比多種技術方案，為下一個瓶頸期提前做準備，這也是為后續業務破局奠定技術基礎。

不過，探索新技術可不是喜新厭舊，可不是舊的要廢棄，要而是要了解各種技術的優劣，便于落在場景中選擇最合適的方案。

總結

基建不是為了做而做，他也是要能解決真實問題的，脫離業務的基建都是耍流氓。從未覺得做基建比做業務的??，基建的家庭地位都是墊底的。

如果你沒做基建，請友善對待你身邊的基建伙伴吧！

如果你要準備做基建，就沖吧，你注定有這一劫！

如果你正在做基建，那一起共勉！

如果說了這么多，你們還沒有醒悟的話，不妨來我司看看，有很多基建已經活了好幾年了，現在依然還堅強著。

• 魯班系統：一個基于業務組件快速生成頁面的搭建系統。
• 門神系統：一個主要用于對接公司內部系統，為內部系統建立起一套完善的權限管理機制。
• 云長系統：一套云端構建工具，提供了前端項目構建、合規檢測、發布等功能，并統一了工程協作流程，使得前端同學在應用開發過程中得心應手。
• 百策系統：一個可以對頁面進行性能檢測并提供優化指引的系統，可以展示一段時間的性能走勢，提供檢測接口服務。
• 渾儀系統：用戶行為采集及分析，助力用戶建立高效的數據指標體系
• 無相表單系統：一個可以快速生成表單的搭建系統。
• 插件體系：主要解決開發中的場景里面涉及到的各種問題的輔助幫助。