關於前端架構師的二三事

爲何要有前端架構師

任何一種崗位的誕生, 都源於問題規模的膨脹

前端工程師的誕生, 就源於 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 是最後的保障手段, 但真正的防護應該是在設計之初, 任何對架構的修改, 在設計階段就應該被你的火眼金睛察覺到那些很差的味道, 而後經過修改, 隔離等各類方式防止對架構的破壞和污染.

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

上掘金炒炒以前寫的冷飯，熱乎熱乎