為什麼要有前端架構師
任何一種崗位的誕生, 都源於問題規模的膨脹
前端工程師的誕生, 就源於 web 開發這個問題規模的膨脹, 早期的網路程式設計師, 和現在的全棧工程師具有類似的屬性, 唯一的區別是處理問題的規模相差極大, 在使用 jsp, asp 編寫網頁的年代, web 開發在頁面端需要處理的問題規模極小, 不考慮 UI, 互動等使用者體驗的場景下, 僅僅是資料的呈現載體, 通過簡單的模板繫結資料, 服務端渲染既可解決問題, 而且彼時, 資料庫也僅僅是資料庫, 高併發, 叢集, 大資料, 雲端計算, 也僅僅是概念, 並未像現在這般大規模應用.
為了解決日益膨脹的 web 開發中"端"的問題, 前端工程師就誕生了, 在這個逐步發展的過程中, 前後端的職責也日益清晰, 不再混沌. 然而網際網路發展速度之快, 超乎人們的想象, 前端開發問題的膨脹速度同樣驚人, 堆砌的業務邏輯和複雜多元的技術棧體系以及不統一的工程體系加上 js 靈活的語言特性, 促使前端開發這個問題的規模以驚人的速度膨脹, 以至於前端工程師調侃自己是 "重做工程師". 於是順理成章的, 前端架構師就誕生了.
在前端開發的早期, 架構是一種非常隱晦的概念, 原因在於前端開發的問題規模較小, 在 JQuery 大行其道的年代, 基於 JQuery 的外掛式架構, 基本是所有前端應用的預設模式, 即便加上 Backbone 帶來的 MVC, 背後的架構也是趨同的. 而此時, 前端還不直接處理業務, 大多是實現一些視覺和互動上的效果, 通過上網扣 JQuery 外掛就能很好的解決問題. 然而這種狀況隨著前後端分離的興起, 很快被打破, 從 angular1.0 到 React, 從 browserify 到 npm, 從 requireJS 到 es6Module, 前端的發展突然加速, 令人目不暇接, 技術更替的週期越來越短. 在這種環境下, 前端工程師無心梳理應用中的架構, 埋沒在技術更替和業務迭代之中, 而背後的架構模式, 在不同的技術體系組合中也開始四分五裂. 管生不管養的業務程式碼成了摧毀應用架構的最後一根稻草.
" 這程式碼不重構, 根本改不動! " " 這程式碼就像一坨屎, 誰寫的? " " 臥槽, 根本理不清這業務邏輯. "
一時間, 重構 && 重做成了解決問題的銀彈, 然而真的是如此麼? 且不說重構帶來的技術風險, 使用新技術重構老程式碼實際上是藉助一些庫背後所隱藏的架構模式來解決現有架構上的混亂, 然而就跟蓋房子和裝修一樣, 即便房子的戶型做得再好, 硬體設計的再妙, 住進去的人一樣能把你好好的房子搞的一團糟, 在技術上你即便用了 React 或者 Vue 全家桶, 我敢說迭代個七八次, 程式碼一樣能亂的你爹媽都分不清.
如果作為 TL, 你對以上這些深有同感, 那你可能就需要給你的團隊配一名前端架構師, 如果作為資深工程師, 你對以上這些深有同感, 或許你該考慮轉職成一個名前端架構師. 所以為什麼要有前端架構師? 因為問題太多, hold 不住啊!
前端架構師的職責
沒有文件的程式碼 = 放棄治療
作為前端架構師, 首先要解決的問題就是讓日益膨脹的程式碼可控,因此你需要 梳理程式碼, 建立架構, 組織文件, 管理架構的更新和維護, 評審技術方案對架構的影響, 核心模組的方案設計, 重點專案的方案設計, CodeReview 等.
架構師和資深開發在工作職責上有著明確的界限, 在一個沒有架構師的團隊, 每一個資深開發或多或少都承擔了一部分架構的工作, 但都是破碎的, 不成體系而且不統一, 從某種意義上講, 這種隱晦的架構還不如沒有架構. 所以確立一名架構師, 從管理上也是將混亂統一的唯一途徑, 在團隊還小的時候, TL 可能會預設承擔架構師的角色, 但團隊規模增長到一定程度, TL會變得力不從心起來, 將工作分給專業的人, 永遠都是工程上自然而然的結果.
相比實際的 coding, 用一段程式碼解決某個問題, 實現某個需求, 架構要複雜和燒腦的多, 本質上工程的問題, 只能用架構解, 而沒法用程式碼解, 所以沒有架構, 談不上工程化. 因此架構師的第一要務, 是梳理程式碼確立架構
把前端架構立起來
在立起來之前, 我們首先要明確, 樹立前端架構的作用, 當你擔負起架構師的職責, 你可能首先面對的就是程式碼, 各種老程式碼, 我們著手去樹立前端架構, 本質上就是要將程式碼隔離在各自的區域之內, 為接下來的工作打下基礎.
因此第一步, 我們先要找出所有屬於你團隊的程式碼, 大到 git 倉庫, 小到某段邏輯, 事無鉅細, 我們把這個工作可以稱為 "技術資產盤點". 等盤點清楚了技術資產, 就是第二步, 編寫資產白皮書, 以檔案為單位把所有的技術資產說清楚, 每個檔案都是幹嘛的, 資產白皮書非常重要, 這個將是你日後架構維護工作的核心. 第三步, 手上有料, 事情就好辦了, 檔案已經說明了解決的問題, 按照問題域和技術域, 對檔案進行歸類, 最後得到的就是現狀, 99%的情況下, 現狀都應該讓你沮喪, 因為看起來就是一坨 shit. 但是這就是你要面對的 "shit 架構".
接下來考驗架構設計能力的時候到了, 把 "shit 架構" 畫成你心中的架構, 兩者之間的路線圖, 結合現狀, 結合業務, 結合團隊, 做出遷移的方案, 這些都做完, 你就成功的把前端架構給立起來了, 這個過程中你可能不需要寫多少程式碼, 你要完成的都將是新架構中的核心功能的程式碼.
前端架構就是你的孩子, 你要保護他
如今你眼前的架構看起來應該不錯了, 作為架構師你的職責就是保護他, 在你沒有想到什麼金鐘罩之類的祕籍之前, 你只能用你的肉體了, 自己設計技術方案, 或者參與技術方案的評審, 在 CodeReview 中找出任何可能汙染架構的程式碼, 總之你的核心工作是, 確保程式碼和架構設計之間的聯絡的真實性, 這部分工作往往體現在你如何高效的維護文件和 CodeReview, 這裡有個小提示, 你的架構設計的越棒, 這部分工作就越輕鬆, 如果這部分工作讓你疲憊不堪, 那你可能需要重新審視你的架構設計了. 另一部分來自於外部, 畢竟 CodeReview 是最後的保障手段, 但真正的防禦應該是在設計之初, 任何對架構的修改, 在設計階段就應該被你的火眼金睛察覺到那些不好的味道, 然後通過修改, 隔離等各種方式防止對架構的破壞和汙染.
總之, 保護好你的架構, 無論他有多爛, 總比沒有強, 等你的架構變得健壯而靈活, 帶給團隊的收益將遠超你的想象.
上掘金炒炒之前寫的冷飯，熱乎熱乎