大家好，我是玄鐵 ，現(xiàn)已工作8年，現(xiàn)在在一線互聯(lián)網(wǎng)公司擔(dān)任前端架構(gòu)師，負(fù)責(zé)系統(tǒng)架構(gòu)、性能優(yōu)化，規(guī)范、工程化建設(shè)，前端組內(nèi)的技術(shù)分享、人才培養(yǎng)等工作，
技能：熟練HTML5/CSS/ES6/Nodejs/Webpack等web主流技術(shù)等。
熟練掌握React或Vue框架，熟悉框架相關(guān)技術(shù)生態(tài)等。
熟練配置項(xiàng)目腳手架，熟悉grunt, gulp, webpack, parcel等工具。
你想不到我都應(yīng)該了解一點(diǎn)。
前端架構(gòu)師的由來：
前端工程師的誕生, 就源于 web 開發(fā)這個問題規(guī)模的膨脹, 早期的網(wǎng)絡(luò)程序員, 和現(xiàn)在的全棧工程師具有類似的屬性, 唯一的區(qū)別是處理問題的規(guī)模相差極大, 在使用 jsp, asp 編寫網(wǎng)頁的年代, web 開發(fā)在頁面端需要處理的問題規(guī)模極小, 不考慮 UI, 交互等用戶體驗(yàn)的場景下, 僅僅是數(shù)據(jù)的呈現(xiàn)載體, 通過簡單的模板綁定數(shù)據(jù), 服務(wù)端渲染既可解決問題, 而且彼時, 數(shù)據(jù)庫也僅僅是數(shù)據(jù)庫, 高并發(fā), 集群, 大數(shù)據(jù), 云計算, 也僅僅是概念, 并未像現(xiàn)在這般大規(guī)模應(yīng)用.
為了解決日益膨脹的 web 開發(fā)中"端"的問題, 前端工程師就誕生了, 在這個逐步發(fā)展的過程中, 前后端的職責(zé)也日益清晰, 不再混沌. 然而互聯(lián)網(wǎng)發(fā)展速度之快, 超乎人們的想象, 前端開發(fā)問題的膨脹速度同樣驚人, 堆砌的業(yè)務(wù)邏輯和復(fù)雜多元的技術(shù)棧體系以及不統(tǒng)一的工程體系加上 js 靈活的語言特性, 促使前端開發(fā)這個問題的規(guī)模以驚人的速度膨脹, 以至于前端工程師調(diào)侃自己是 “重做工程師”. 于是順理成章的, 前端架構(gòu)師就誕生了
在前端開發(fā)的早期, 架構(gòu)是一種非常隱晦的概念, 原因在于前端開發(fā)的問題規(guī)模較小, 在 JQuery 大行其道的年代, 基于 JQuery 的插件式架構(gòu), 基本是所有前端應(yīng)用的默認(rèn)模式, 即便加上 Backbone 帶來的 MVC, 背后的架構(gòu)也是趨同的. 而此時, 前端還不直接處理業(yè)務(wù), 大多是實(shí)現(xiàn)一些視覺和交互上的效果, 通過上網(wǎng)扣 JQuery 插件就能很好的解決問題. 然而這種狀況隨著前后端分離的興起, 很快被打破, 從 angular1.0 到 React, 從 browserify 到 npm, 從 requireJS 到 es6Module, 前端的發(fā)展突然加速, 令人目不暇接, 技術(shù)更替的周期越來越短. 在這種環(huán)境下, 前端工程師無心梳理應(yīng)用中的架構(gòu), 埋沒在技術(shù)更替和業(yè)務(wù)迭代之中, 而背后的架構(gòu)模式, 在不同的技術(shù)體系組合中也開始四分五裂. 管生不管養(yǎng)的業(yè)務(wù)代碼成了摧毀應(yīng)用架構(gòu)的最后一根稻草.
" 這代碼不重構(gòu), 根本改不動! "
" 這代碼就像一坨屎, 誰寫的? "
" 臥槽, 根本理不清這業(yè)務(wù)邏輯. "
一時間, 重構(gòu) && 重做成了解決問題的銀彈, 然而真的是如此么? 且不說重構(gòu)帶來的技術(shù)風(fēng)險, 使用新技術(shù)重構(gòu)老代碼實(shí)際上是借助一些庫背后所隱藏的架構(gòu)模式來解決現(xiàn)有架構(gòu)上的混亂, 然而就跟蓋房子和裝修一樣, 即便房子的戶型做得再好, 硬件設(shè)計的再妙, 住進(jìn)去的人一樣能把你好好的房子搞的一團(tuán)糟, 在技術(shù)上你即便用了 React 或者 Vue 全家桶, 我敢說迭代個七八次, 代碼一樣能亂的你爹媽都分不清.
如果作為 TL, 你對以上這些深有同感, 那你可能就需要給你的團(tuán)隊(duì)配一名前端架構(gòu)師,
如果作為資深工程師, 你對以上這些深有同感, 或許你該考慮轉(zhuǎn)職成一個名前端架構(gòu)師.
所以為什么要有前端架構(gòu)師? 因?yàn)閱栴}太多, **hold **不住啊!
前端架構(gòu)師的職責(zé)
沒有文檔的代碼 = 放棄治療
作為前端架構(gòu)師, 首先要解決的問題就是讓日益膨脹的代碼可控,因此你需要 梳理代碼, 建立架構(gòu), 組織文檔, 管理架構(gòu)的更新和維護(hù), 評審技術(shù)方案對架構(gòu)的影響, 核心模塊的方案設(shè)計, 重點(diǎn)項(xiàng)目的方案設(shè)計, CodeReview 等.
架構(gòu)師和資深開發(fā)在工作職責(zé)上有著明確的界限, 在一個沒有架構(gòu)師的團(tuán)隊(duì), 每一個資深開發(fā)或多或少都承擔(dān)了一部分架構(gòu)的工作, 但都是破碎的, 不成體系而且不統(tǒng)一, 從某種意義上講, 這種隱晦的架構(gòu)還不如沒有架構(gòu). 所以確立一名架構(gòu)師, 從管理上也是將混亂統(tǒng)一的唯一途徑, 在團(tuán)隊(duì)還小的時候, TL 可能會默認(rèn)承擔(dān)架構(gòu)師的角色, 但團(tuán)隊(duì)規(guī)模增長到一定程度, TL會變得力不從心起來, 將工作分給專業(yè)的人, 永遠(yuǎn)都是工程上自然而然的結(jié)果.
相比實(shí)際的 coding, 用一段代碼解決某個問題, 實(shí)現(xiàn)某個需求, 架構(gòu)要復(fù)雜和燒腦的多, 本質(zhì)上工程的問題, 只能用架構(gòu)解, 而沒法用代碼解, 所以沒有架構(gòu), 談不上工程化. 因此架構(gòu)師的第一要務(wù), 是梳理代碼確立架構(gòu)
把前端架構(gòu)立起來
在立起來之前, 我們首先要明確, 樹立前端架構(gòu)的作用, 當(dāng)你擔(dān)負(fù)起架構(gòu)師的職責(zé), 你可能首先面對的就是代碼, 各種老代碼, 我們著手去樹立前端架構(gòu), 本質(zhì)上就是要將代碼隔離在各自的區(qū)域之內(nèi), 為接下來的工作打下基礎(chǔ).
因此第一步, 我們先要找出所有屬于你團(tuán)隊(duì)的代碼, 大到 git 倉庫, 小到某段邏輯, 事無巨細(xì), 我們把這個工作可以稱為 “技術(shù)資產(chǎn)盤點(diǎn)”.
等盤點(diǎn)清楚了技術(shù)資產(chǎn), 就是第二步, 編寫資產(chǎn)白皮書, 以文件為單位把所有的技術(shù)資產(chǎn)說清楚, 每個文件都是干嘛的, 資產(chǎn)白皮書非常重要, 這個將是你日后架構(gòu)維護(hù)工作的核心.
第三步, 手上有料, 事情就好辦了, 文件已經(jīng)說明了解決的問題, 按照問題域和技術(shù)域, 對文件進(jìn)行歸類, 最后得到的就是現(xiàn)狀, 99%的情況下, 現(xiàn)狀都應(yīng)該讓你沮喪, 因?yàn)榭雌饋砭褪且慧?shit. 但是這就是你要面對的 “shit 架構(gòu)”.
接下來考驗(yàn)架構(gòu)設(shè)計能力的時候到了, 把 “shit 架構(gòu)” 畫成你心中的架構(gòu), 兩者之間的路線圖, 結(jié)合現(xiàn)狀, 結(jié)合業(yè)務(wù), 結(jié)合團(tuán)隊(duì), 做出遷移的方案, 這些都做完, 你就成功的把前端架構(gòu)給立起來了, 這個過程中你可能不需要寫多少代碼, 你要完成的都將是新架構(gòu)中的核心功能的代碼.
前端架構(gòu)就是你的孩子, 你要保護(hù)他
如今你眼前的架構(gòu)看起來應(yīng)該不錯了, 作為架構(gòu)師你的職責(zé)就是保護(hù)他, 在你沒有想到什么金鐘罩之類的秘籍之前, 你只能用你的肉體了, 自己設(shè)計技術(shù)方案, 或者參與技術(shù)方案的評審, 在 CodeReview 中找出任何可能污染架構(gòu)的代碼, 總之你的核心工作是, 確保代碼和架構(gòu)設(shè)計之間的聯(lián)系的真實(shí)性, 這部分工作往往體現(xiàn)在你如何高效的維護(hù)文檔和 CodeReview, 這里有個小提示, 你的架構(gòu)設(shè)計的越棒, 這部分工作就越輕松, 如果這部分工作讓你疲憊不堪, 那你可能需要重新審視你的架構(gòu)設(shè)計了. 另一部分來自于外部, 畢竟 CodeReview 是最后的保障手段, 但真正的防御應(yīng)該是在設(shè)計之初, 任何對架構(gòu)的修改, 在設(shè)計階段就應(yīng)該被你的火眼金睛察覺到那些不好的味道, 然后通過修改, 隔離等各種方式防止對架構(gòu)的破壞和污染.
總之, 保護(hù)好你的架構(gòu), 無論他有多爛, 總比沒有強(qiáng), 等你的架構(gòu)變得健壯而靈活, 帶給團(tuán)隊(duì)的收益將遠(yuǎn)超你的想象.
在其位，謀其政，站在架構(gòu)師的職位上，架構(gòu)師要本著對團(tuán)隊(duì)支持、對系統(tǒng)負(fù)責(zé)，對領(lǐng)導(dǎo)和業(yè)務(wù)相關(guān)方充分溝通與建議的基本準(zhǔn)備，充分利用自身的經(jīng)驗(yàn)與閱歷，幫助團(tuán)隊(duì)規(guī)避各類或深或淺的系統(tǒng)之坑陷，保證業(yè)務(wù)線的正常運(yùn)轉(zhuǎn)，同時保持系統(tǒng)具備一定的靈活性、穩(wěn)定性和可持續(xù)開發(fā)性。 盡人事，知天命，有所為，有所不為，架構(gòu)師其實(shí)是技術(shù)、業(yè)務(wù)、管理和資源等各類因素之間進(jìn)行妥協(xié)、溝通和協(xié)調(diào)的角色，混很容易，做好很難。
前端圖譜：
今天開始正式入戶建設(shè)簡書了，希望能給大家分享知識項(xiàng)目經(jīng)驗(yàn)。
座右銘：沒有什么做不了，只有自己想不到的。
歡迎大家關(guān)注我！
下一個分享：一名前端Web架構(gòu)師的成長之路 大家聊聊！
