前端架構碎碎念

前言

最近看了一些關於前端架構相關的書籍和博客，以爲有點自我膨脹了，居然想對着前端架構這一說法指指點點。從跨入這個行業開始，就以爲架構師就是位於技術金字塔的頂端的那撥人，是引導行業或團隊技術走向的那撥人。然而從行業上對前端架構的定義和必備的技能來看，以爲前端架構就是一個僞概念，又或是拔高本身身份的幌子。

類比於建房子，考慮到人文因素，會有中西風格；考慮到地理位置，會有南北之分；考慮到簡易方便，還會有組合式集裝箱房屋。設計師會運用本身專業知識並集合各類因素，設計出符合當前環境的房屋。而架構師也是如此，他們須要從業務、技術等角度構造出合理的組織架構。前端技術不斷髮展演進，從模塊化的摸索，到 MV* 的實踐，再到當今組件化的盛行。這些技術人不斷折騰，不斷改進前端架構，使之更符合這個時代。在市場的篩選下，最終也留下了最適合當前的前端技術方案。不過，大部分前端架構師並不具有這種能力，充其量就是經驗豐富的包工頭，某種前端技術方案的踐行者。

設計師怎麼練成的，咱們不知道。可是類比包工頭，咱們仍是知道前端 Leader 應該作什麼。

開工前的前期準備

這裏的前期準備，指的是從零啓動一個項目，咱們須要作的準備工做。而最能體現整個項目的技術含量的活估計有大半在這裏了。做爲一個包工頭，不是說我能把磚砌得有多好，而是足夠了解現有的資源和工做流，並搭建好基礎設施，爲往後項目高效推動起個好頭。

在很早之前，數據和視圖耦合，那時候沒有前端的什麼事，最多做爲頁面仔爲後端提供模板，或者說畫幾個展現用的靜態頁面。以後 ajax 的興起，讓數據和視圖的關係開始鬆綁，前端在數據的賦能下，迎來了一次大發展。人要與數據交互，必然要經過某個媒介，而前端在獲取部分數據的權限後，又反過來促進了人與數據的互動關係。即便後面的 Node，我也認爲是前端爲爭取操做數據權限而作的努力。畢竟，這個年代數據纔是王道。

視圖怎麼獲取數據？視圖怎麼展現數據？視圖怎麼更好得獲取數據？視圖怎麼更好得展現數據？（...沒想那麼多...）

架構設計

從早期的服務端直出到如今的服務端渲染，視圖的渲染兜兜轉轉貌似又回到的起點。但此非彼，不可同日而語。ajax 被 Google 使用後，隨之而來的是先後端的分離。前端應用也是跟隨時代而呈現不一樣的架構設計，好比多頁面應用、單頁面應用、同構渲染、微前端等。它們的出現是爲了解決某些問題而給出的技術方案，因此說即便過期，卻依然有其價值。

多頁面應用，相對來講，比較簡單。簡單的多頁面應用，好比靜態頁面，這裏可能壓根沒 JS 的事。複雜點的多頁面應用，可能要引入模板引擎，路由等。要是以爲原生操做 DOM 不方便，可使用 jQuery。多頁面應該在項目啓動的時候，會加載須要的資源，因爲瀏覽器緩存策略，第二次加載相同的資源時，可能就不須要重複請求了。在結合一點 MV* 模式，快和單頁面應用沒什麼區別了。只是如今流行的單頁面不須要直接操做 DOM ，而是交給框架底層處理了。

以上的應用說來講去可能都是同一個應用，在某些場景，就須要聚合多個前端應用，有路由分發的方案，有 iframe 做爲容器的方案等。

前端規範

「書同文，車同軌」

既然是包工頭，天然不大多是一個光桿司令。制定規範，不只可使成員代碼風格趨於統一，同時也可使新手養成良好的編碼習慣。對於前端來講，HTML、CSS、JS 分別表明告終構層、表現層和行爲層。在代碼層次上，它們都有本身的一套標準，能夠結合各自 lint工具 + Prettier 輕鬆規範代碼。從組件規範角度，還包括 UI 組件規範、模塊化規範、項目組件化設計方案等。

編輯器最好也可以統一下，若是可以摸索出可以提升效率的一系列使用方法，同步給全組成員就更好了。

自動化構建

都 9102 年，自動化構建已成爲現代前端工程不可或缺的一個環節。自動化構建能夠作不少事，好比文件編譯，資源合併，壓縮優化等。構建工具不少，但所作的事基本上是差很少的，讀取入口配置文件 ➡ 生成模塊依賴圖 ➡ 加載模塊 ➡ 模塊文件編譯處理 ➡️ 模塊文件合併 ➡️ 文件資源優化 ➡ 輸出最終資源。

不管是生產環境仍是開發環境，都須要構建工具的參與。生產環境側重於性能，好比文件壓縮優化，去除無用代碼註釋等。測試環境側重於開發體驗，好比模塊熱替換，生成 sourcemap 等。像以前的代碼規範，也能夠藉助構建工具自動化格式化代碼，或提示錯誤。

項目代碼示例

項目在正是啓動以前，須要驗證程序是否按照本身的預期去執行。驗證可行後，並按照本身定義的一系列規範編寫示例代碼，這樣有助於其餘成員瞭解該項目的規範。同時，對內組織技術培訓，介紹系統的架構和注意事項。

其實，技術驗證的過程不該該放在整個開發流程中。工做之餘，咱們能夠多接觸新的技術和嘗試新的架構設計。在未知的領域，咱們沒法準確評估時間，臨時磨槍可能會致使整個項目的延期。

開工

技術是爲業務服務的，項目啓動了，意味着開始償還業務債了。而前端 Leader 職責也開始發生變化，不只僅從事技術活，還要參與到團隊管理、項目管理等非技術活。項目進入正軌後，人人都成爲了螺絲工，技術上的難題基本上不多再會遇到。可是這並不表明整個開發過程會變得一路順風。

溝通協調

「凡事有交代，件件有着落，事事有迴音」

無論是普通成員，仍是團隊 Leader，都應該具有這樣的作事風格，對本身和別人都有個交代。

前端在整個研發隊伍中，是一個比較尷尬的存在。尤爲在比較重視業務的團隊裏，好事沒撈到，麻煩事卻不斷找上門。好比頁面拋異常，測試夥伴第一個就找前端。產品夥伴不靠譜，頻繁找前端。遇到不靠譜的後端小夥伴，聯調測試時也會跑來質疑前端。最後可能領導跑來找你談話，說大家前端團隊怎麼總是出問題。講真，這話無法接。感受前端就是一個接鍋俠，時間長了，對團隊士氣有很大的影響，這也是前端 Leader 須要解決的問題。

對於產品，需求評審嚴格把關，對於不合理或不緊急的需求，延遲或下降其優先級。對於測試夥伴，對其進行技術培訓，瞭解開發者工具的簡單使用，和常見異常報錯分析科普。對於後端，制定相關約束。以上規範要造成文檔保存，方便後來者。

固然諸如此類的問題會有不少，對於問題要敏感並及時發現，分析致使問題的根源，最後對症下藥逐步解決問題。事情說得很簡單，但事實上，人們習慣於存在問題的現狀而不自知或發現問題卻習慣於有問題的現狀。

提高團隊能力

衆人拾柴火焰高，只有大夥兒力往一處使，才能產生 1 + 1 > 2 的效果。但是編碼並非力氣活，成員的良莠不齊，很大的程度上會拖團隊的後退。好比，一個新手的代碼提交不規範，極可能致使某些人的哀嚎。

代碼審查，是一個提升本身編碼能力的好機會。以前的 Lint 規則能夠很好地校訂代碼風格，而在代碼審查中，就能夠發現邏輯上的問題或知道可讓代碼更出彩的方法。

代碼重構算是一種提高編程能力的方式，不過有不少人對代碼重構有着很大的誤解，也不見得項目中對重構的重視。重構能夠本着小步快走的原則，增長程序的可讀性和可維護性。什麼時候去重構？須要重構的標準的是什麼？若是程序冗長囉嗦看不懂，那就重構它。若是一段程序過度依賴於註釋，那就重構它。若是你想添加新功能，卻無從下手，那就重構它。只要是可讀性差，可維護性差，你都有理由去重構它。

代碼審查還有一個好處就是，能夠幫助咱們熟悉業務。若是項目業務很複雜，至少要保證有兩我的對同一模塊有足夠的瞭解。

新人培訓和技術分享，新人剛接入項目時，有必要對其進行基礎的技術培訓，如業務培訓、技術棧相關知識培訓、調試能力培訓等，這些都要有相關的文檔。這些看着可有可無的培訓，對於新手來講，每每是一大助力。

技術分享，並不期望一次簡單的分享就讓全部的成員學會一項技能，不過這對團隊的技術視野和團隊技術氛圍會有很大幫助。對於技術分享的人，有不一樣的說法，有人主張新人主持分享，這樣能夠加快新人融入團隊，老人也能夠一旁補充說明。而有些人，則認爲讓最擅長的人去作擅長的事。不知道孰好孰壞，不予置評。

我認爲團隊能力還應該包括存續能力，也就是即使成員流動快，新到位的成員也能很快接入項目。這就須要各類文檔記錄，新人培訓文檔，技術架構文檔，業務文檔，技術分享文檔，開發規範文檔，工做交接文檔等。

先後端聯調

後端由本地開發環境部署到測試環境，按正常的節奏來，先後端聯調會很順利。然而，實際開發中，聯調的佔比會很大。主要的緣由有，

1. 先後端溝通效率低，有問題相互質疑。
2. 後端自測力度不夠，考慮不周全。
3. 接口協議變更頻繁。
4. 接口文檔不詳實。 ...

最簡單粗暴的方法就是引入接口管理平臺，引入績效考覈制度。

持續化集成 持續化交付 持續化部署

這一塊就不是前端本身可以決定的事情了，有條件的話能夠本身搭建代碼託管平臺，使用 gitlab ，如今人家提供一條龍服務，能夠嘗試一波。

結語

和代碼打交道不可怕，和人打交道也不可怕，可怕的是這個前端 Leader 有想法。