前端架構師的職責
沒有文檔的代碼 = 放棄治療
作為前端架構師, 首先要解決的問題就是讓日益膨脹的代碼可控,因此你需要 梳理代碼, 建立架構, 組織文檔, 管理架構的更新和維護, 評審技術方案對架構的影響, 核心模塊的方案設計, 重點項目的方案設計, CodeReview 等.
架構師和資深開發在工作職責上有着明確的界限, 在一個沒有架構師的團隊, 每一個資深開發或多或少都承擔了一部分架構的工作, 但都是破碎的, 不成體系而且不統一, 從某種意義上講, 這種隱晦的架構還不如沒有架構. 所以確立一名架構師, 從管理上也是將混亂統一的唯一途徑, 在團隊還小的時候, TL 可能會默認承擔架構師的角色, 但團隊規模增長到一定程度, TL會變得力不從心起來, 將工作分給專業的人, 永遠都是工程上自然而然的結果.
相比實際的 coding, 用一段代碼解決某個問題, 實現某個需求, 架構要復雜和燒腦的多, 本質上工程的問題, 只能用架構解, 而沒法用代碼解, 所以沒有架構, 談不上工程化. 因此架構師的第一要務, 是梳理代碼確立架構
把前端架構立起來
在立起來之前, 我們首先要明確, 樹立前端架構的作用, 當你擔負起架構師的職責, 你可能首先面對的就是代碼, 各種老代碼, 我們着手去樹立前端架構, 本質上就是要將代碼隔離在各自的區域之內, 為接下來的工作打下基礎.
因此第一步, 我們先要找出所有屬於你團隊的代碼, 大到 git 倉庫, 小到某段邏輯, 事無巨細, 我們把這個工作可以稱為 "技術資產盤點".
等盤點清楚了技術資產, 就是第二步, 編寫資產白皮書, 以文件為單位把所有的技術資產說清楚, 每個文件都是干嘛的, 資產白皮書非常重要, 這個將是你日后架構維護工作的核心.
第三步, 手上有料, 事情就好辦了, 文件已經說明了解決的問題, 按照問題域和技術域, 對文件進行歸類, 最后得到的就是現狀, 99%的情況下, 現狀都應該讓你沮喪, 因為看起來就是一坨 shit. 但是這就是你要面對的 "shit 架構".
接下來考驗架構設計能力的時候到了, 把 "shit 架構" 畫成你心中的架構, 兩者之間的路線圖, 結合現狀, 結合業務, 結合團隊, 做出遷移的方案, 這些都做完, 你就成功的把前端架構給立起來了, 這個過程中你可能不需要寫多少代碼, 你要完成的都將是新架構中的核心功能的代碼.
前端架構就是你的孩子, 你要保護他
如今你眼前的架構看起來應該不錯了, 作為架構師你的職責就是保護他, 在你沒有想到什么金鍾罩之類的秘籍之前, 你只能用你的肉體了, 自己設計技術方案, 或者參與技術方案的評審, 在 CodeReview 中找出任何可能污染架構的代碼, 總之你的核心工作是, 確保代碼和架構設計之間的聯系的真實性, 這部分工作往往體現在你如何高效的維護文檔和 CodeReview, 這里有個小提示, 你的架構設計的越棒, 這部分工作就越輕松, 如果這部分工作讓你疲憊不堪, 那你可能需要重新審視你的架構設計了. 另一部分來自於外部, 畢竟 CodeReview 是最后的保障手段, 但真正的防御應該是在設計之初, 任何對架構的修改, 在設計階段就應該被你的火眼金睛察覺到那些不好的味道, 然后通過修改, 隔離等各種方式防止對架構的破壞和污染.
總之, 保護好你的架構, 無論他有多爛, 總比沒有強, 等你的架構變得健壯而靈活, 帶給團隊的收益將遠超你的想象.
作者：柳郎中
鏈接：https://www.jianshu.com/p/42775438004d
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。