為什么要有前端架構師

任何一種崗位的誕生, 都源于問題規(guī)模的膨脹

前端工程師的誕生, 就源于 web 開發(fā)這個問題規(guī)模的膨脹, 早期的網(wǎng)絡程序員, 和現(xiàn)在的全棧工程師具有類似的屬性, 唯一的區(qū)別是處理問題的規(guī)模相差極大, 在使用 jsp, asp 編寫網(wǎng)頁的年代, web 開發(fā)在頁面端需要處理的問題規(guī)模極小, 不考慮 UI, 交互等用戶體驗的場景下, 僅僅是數(shù)據(jù)的呈現(xiàn)載體, 通過簡單的模板綁定數(shù)據(jù), 服務端渲染既可解決問題, 而且彼時, 數(shù)據(jù)庫也僅僅是數(shù)據(jù)庫, 高并發(fā), 集群, 大數(shù)據(jù), 云計算, 也僅僅是概念, 并未像現(xiàn)在這般大規(guī)模應用.

為了解決日益膨脹的 web 開發(fā)中"端"的問題, 前端工程師就誕生了, 在這個逐步發(fā)展的過程中, 前后端的職責也日益清晰, 不再混沌. 然而互聯(lián)網(wǎng)發(fā)展速度之快, 超乎人們的想象, 前端開發(fā)問題的膨脹速度同樣驚人, 堆砌的業(yè)務邏輯和復雜多元的技術棧體系以及不統(tǒng)一的工程體系加上 js 靈活的語言特性, 促使前端開發(fā)這個問題的規(guī)模以驚人的速度膨脹, 以至于前端工程師調侃自己是 "重做工程師". 于是順理成章的, 前端架構師就誕生了.

在前端開發(fā)的早期, 架構是一種非常隱晦的概念, 原因在于前端開發(fā)的問題規(guī)模較小, 在 JQuery 大行其道的年代, 基于 JQuery 的插件式架構, 基本是所有前端應用的默認模式, 即便加上 Backbone 帶來的 MVC, 背后的架構也是趨同的. 而此時, 前端還不直接處理業(yè)務, 大多是實現(xiàn)一些視覺和交互上的效果, 通過上網(wǎng)扣 JQuery 插件就能很好的解決問題. 然而這種狀況隨著前后端分離的興起, 很快被打破, 從 angular1.0 到 React, 從 browserify 到 npm, 從 requireJS 到 es6Module, 前端的發(fā)展突然加速, 令人目不暇接, 技術更替的周期越來越短. 在這種環(huán)境下, 前端工程師無心梳理應用中的架構, 埋沒在技術更替和業(yè)務迭代之中, 而背后的架構模式, 在不同的技術體系組合中也開始四分五裂. 管生不管養(yǎng)的業(yè)務代碼成了摧毀應用架構的最后一根稻草.

" 這代碼不重構, 根本改不動! "
" 這代碼就像一坨屎, 誰寫的? "
" 臥槽, 根本理不清這業(yè)務邏輯. "

一時間, 重構 && 重做成了解決問題的銀彈, 然而真的是如此么? 且不說重構帶來的技術風險, 使用新技術重構老代碼實際上是借助一些庫背后所隱藏的架構模式來解決現(xiàn)有架構上的混亂, 然而就跟蓋房子和裝修一樣, 即便房子的戶型做得再好, 硬件設計的再妙, 住進去的人一樣能把你好好的房子搞的一團糟, 在技術上你即便用了 React 或者 Vue 全家桶, 我敢說迭代個七八次, 代碼一樣能亂的你爹媽都分不清.

如果作為 TL, 你對以上這些深有同感, 那你可能就需要給你的團隊配一名前端架構師,
如果作為資深工程師, 你對以上這些深有同感, 或許你該考慮轉職成一個名前端架構師.
所以為什么要有前端架構師? 因為問題太多, hold 不住啊!

前端架構師的職責

沒有文檔的代碼 = 放棄治療

作為前端架構師, 首先要解決的問題就是讓日益膨脹的代碼可控,因此你需要 梳理代碼, 建立架構, 組織文檔, 管理架構的更新和維護, 評審技術方案對架構的影響, 核心模塊的方案設計, 重點項目的方案設計, CodeReview 等.

架構師和資深開發(fā)在工作職責上有著明確的界限, 在一個沒有架構師的團隊, 每一個資深開發(fā)或多或少都承擔了一部分架構的工作, 但都是破碎的, 不成體系而且不統(tǒng)一, 從某種意義上講, 這種隱晦的架構還不如沒有架構. 所以確立一名架構師, 從管理上也是將混亂統(tǒng)一的唯一途徑, 在團隊還小的時候, TL 可能會默認承擔架構師的角色, 但團隊規(guī)模增長到一定程度, TL會變得力不從心起來, 將工作分給專業(yè)的人, 永遠都是工程上自然而然的結果.

相比實際的 coding, 用一段代碼解決某個問題, 實現(xiàn)某個需求, 架構要復雜和燒腦的多, 本質上工程的問題, 只能用架構解, 而沒法用代碼解, 所以沒有架構, 談不上工程化. 因此架構師的第一要務, 是梳理代碼確立架構

把前端架構立起來

在立起來之前, 我們首先要明確, 樹立前端架構的作用, 當你擔負起架構師的職責, 你可能首先面對的就是代碼, 各種老代碼, 我們著手去樹立前端架構, 本質上就是要將代碼隔離在各自的區(qū)域之內, 為接下來的工作打下基礎.

因此第一步, 我們先要找出所有屬于你團隊的代碼, 大到 git 倉庫, 小到某段邏輯, 事無巨細, 我們把這個工作可以稱為 "技術資產盤點".
等盤點清楚了技術資產, 就是第二步, 編寫資產白皮書, 以文件為單位把所有的技術資產說清楚, 每個文件都是干嘛的, 資產白皮書非常重要, 這個將是你日后架構維護工作的核心.
第三步, 手上有料, 事情就好辦了, 文件已經(jīng)說明了解決的問題, 按照問題域和技術域, 對文件進行歸類, 最后得到的就是現(xiàn)狀, 99%的情況下, 現(xiàn)狀都應該讓你沮喪, 因為看起來就是一坨 shit. 但是這就是你要面對的 "shit 架構".

接下來考驗架構設計能力的時候到了, 把 "shit 架構" 畫成你心中的架構, 兩者之間的路線圖, 結合現(xiàn)狀, 結合業(yè)務, 結合團隊, 做出遷移的方案, 這些都做完, 你就成功的把前端架構給立起來了, 這個過程中你可能不需要寫多少代碼, 你要完成的都將是新架構中的核心功能的代碼.

前端架構就是你的孩子, 你要保護他

如今你眼前的架構看起來應該不錯了, 作為架構師你的職責就是保護他, 在你沒有想到什么金鐘罩之類的秘籍之前, 你只能用你的肉體了, 自己設計技術方案, 或者參與技術方案的評審, 在 CodeReview 中找出任何可能污染架構的代碼, 總之你的核心工作是, 確保代碼和架構設計之間的聯(lián)系的真實性, 這部分工作往往體現(xiàn)在你如何高效的維護文檔和 CodeReview, 這里有個小提示, 你的架構設計的越棒, 這部分工作就越輕松, 如果這部分工作讓你疲憊不堪, 那你可能需要重新審視你的架構設計了. 另一部分來自于外部, 畢竟 CodeReview 是最后的保障手段, 但真正的防御應該是在設計之初, 任何對架構的修改, 在設計階段就應該被你的火眼金睛察覺到那些不好的味道, 然后通過修改, 隔離等各種方式防止對架構的破壞和污染.

總之, 保護好你的架構, 無論他有多爛, 總比沒有強, 等你的架構變得健壯而靈活, 帶給團隊的收益將遠超你的想象.

某野生前端架構師
寫于2017年夏末