前端的一些思考和總結(jié)
加入大淘寶到現(xiàn)在也有六年多了，一路走來很開心可以一直做技術。負責過業(yè)務、基礎庫、工具以及架構(gòu)，期望自己不斷成長。想對之前的工作做一些思考和記錄，也想為后續(xù)的工作找一個合適的開始。有蠻多話想說的，這次就先從 “前端架構(gòu)” 這個話題慢慢說起吧。
聊聊架構(gòu)
好的代碼和差的代碼都能運行，但我們會追求好的代碼，獲得更好的維護性和可讀性。同理沒有架構(gòu)的系統(tǒng)也能工作，但如果一個業(yè)務團隊沒有好的架構(gòu)，整個團隊將陷入混亂，最終難以支撐業(yè)務快速變化。
架構(gòu)是為了解決問題，將復雜、模糊的問題，變得清晰、有邏輯。問題的尺度上，可以大到整個公司的系統(tǒng)設計，也可以小到一個模塊如何渲染。問題的時間上，可以是當下的問題，也可以是預期以后會發(fā)生的問題。如何做好結(jié)構(gòu)和如何解決好問題有很多相似之處，比如把復雜問題簡單化，比如找到多種解決方案并在其中找到最合適有效的方案，比如要考慮成本和實現(xiàn)，控制好風險等等。網(wǎng)上也有很多關于架構(gòu)設計的原則和思維等，這里就不在贅述了。
我所追求的架構(gòu)，不僅要清晰有邏輯，還要簡單靈活好擴展；能切實解決問題，也能支撐業(yè)務快速穩(wěn)定發(fā)展，并不斷演進。
聊聊前端架構(gòu)師
所謂架構(gòu)師，通俗的說就是架構(gòu)的設計者或構(gòu)建者。《架構(gòu)師到底是做什么的？》很有意思，其中有一段話是這么說的：
一個架構(gòu)師， 好的架構(gòu)師， 就是反復做四件事：第一，先選一個好的挑戰(zhàn)， 第二， 把簡單的東西想復雜 ；第三， 把復雜的東西做簡單；第四， 最后把復雜的東西講簡單。
做第一件事是為了創(chuàng)造價值， 第二件事是為了控制好風險和準備好未來， 做第三件事請是為了做好產(chǎn)品且控制好成本， 而做第四件事情是為了做好傳承。
架構(gòu)師必須依靠團隊的支持，不同的專注領域衍生出不同的架構(gòu)師，這里主要聊聊前端架構(gòu)師。曾有人說前端架構(gòu)師就是選選框架，搞搞文件目錄就可以了，但伴隨基礎設施的發(fā)展、大前端體系的不斷增大以及用戶體驗的不斷升級，前端架構(gòu)師有了更大的價值和更高的上限。圍繞用戶體驗鏈路，前端架構(gòu)師可以將具有不同關注點的團隊聯(lián)系起來，包括產(chǎn)品、設計、前端、服務端、客戶端、工程、數(shù)據(jù)、運維等團隊，用戶視角也能幫助前端架構(gòu)師發(fā)現(xiàn)更多問題。圍繞大前端技術，前端架構(gòu)師可以主導所有技術體系的設計和實現(xiàn)，甚至會影響組織架構(gòu)的調(diào)整（比如終端工程師的誕生）。
當然前端架構(gòu)師的目標也離不開高性能、高可用、易擴展以及解決系統(tǒng)復雜度。舉個解決首屏加載速度慢問題的例子，我們做了以下事情：
- 了解業(yè)務：全面調(diào)研當前業(yè)務和競品的現(xiàn)狀，充分理解當前渲染鏈路和節(jié)點，確認當前存在的問題
- 尋找方案：預估未來發(fā)展的方向，盡可能多的了解相關解決方案或創(chuàng)新自己的方案，比如：SSR，ER，預渲染，預加載，靜態(tài)化等
- 評估方案：和相關同學討論或開會，評估所有可行的方案及其合適度、復雜度、前瞻性和 ROI。選出至少一個候選方案，比如：SSR
- Demo 開發(fā)：基于現(xiàn)有開發(fā)能力為所有候選方案開發(fā)對應 Demo，提前探路并驗證風險和可行性，幫助產(chǎn)出更合適的方案設計
- 方案設計：梳理清楚 SSR 完整鏈路上相關節(jié)點和合作方，多寫、多畫、多思考、多討論相關架構(gòu)和設計，深入細節(jié)產(chǎn)出 RFC 文檔
- RFC 評審：充分評審設計、實現(xiàn)和產(chǎn)物細節(jié)，可多次評審直至所有成員達成共識。確定相關開發(fā)和團隊分工，保證方案完善可執(zhí)行
- 落到實處：推進項目開發(fā)，多與開發(fā)團隊溝通，并至少參與一部分編碼工作，打通所有相關開發(fā)和運維鏈路，保障產(chǎn)物簡單好用
- 沉淀傳承：沉淀文檔，通過會議、分享或文章幫助其他人理解 SSR 方案和架構(gòu)，用好 SSR。做好答疑，并推動方案實施
- 不斷演進：關注 SSR 的發(fā)展，演進已有鏈路，比如，個性化的 SSR，結(jié)合 ER 的 SSR 等
從開發(fā)、構(gòu)建發(fā)布到全量用戶使用，從數(shù)據(jù)衡量到問題排查，我們交付了一個完整的 SSR 方案，其中處處有前端架構(gòu)師的設計和影響。
前端架構(gòu)師是否和你想象的有所不同？不僅僅要產(chǎn)出架構(gòu)圖，保證架構(gòu)的正確執(zhí)行，深入實現(xiàn)并至少要參與一部分編碼工作，落實一個一個解決方案同時，前端架構(gòu)師也要能閱讀代碼并經(jīng)常與各個開發(fā)團隊交流。可以說整個用戶體驗鏈路都有前端架構(gòu)師的影子，他們了解用戶體驗；不設限，有審美能力，優(yōu)雅；能看到其他人看不到的問題，也能解決一些其他人解決不了的問題；能夠把復雜的系統(tǒng)想得清楚和透徹，也能夠了解各個模塊和環(huán)節(jié)；對未來發(fā)展有自己的思考和判斷，并不斷解決 DX 和 UX 相關問題。
思考和總結(jié)
回顧過去的工作，得益于團隊的信任及大前端的不斷演進，我可以不斷學習思考實踐、權(quán)衡重構(gòu)及與人打交道，令我非常愉悅，受益匪淺。嚴格來說我應該算個前端解決方案架構(gòu)師，在前端架構(gòu)的方向，我也還有很多需要發(fā)展和改善的地方，下面梳理下個人的思考和總結(jié)：我認為一個好的架構(gòu)師，不僅技術要好，還要懂業(yè)務；能從整體設計架構(gòu)，也能在局部實現(xiàn)功能。首先，技術好是成為架構(gòu)師的基礎條件。在平常的開發(fā)中，需要多注意讓你的代碼容易閱讀和擴展，多想想是否有更好的實現(xiàn)方式，多參與代碼審查工作。這樣通過大量的編碼實踐，可以逐步地培養(yǎng)出好的架構(gòu)思維。成為架構(gòu)師后也要多寫代碼，如果不寫代碼，是不能體會出開發(fā)的痛點和設計不好帶來的問題，無法及時地對架構(gòu)中的問題做出調(diào)整，所設計的架構(gòu)可能不實用，甚至甚脫離現(xiàn)實。
架構(gòu)師不同于高級開發(fā)可以只追求技術的深度，還需要有一定的技術廣度。因為技術的選型，通常不能局限于一種技術，需要根據(jù)業(yè)務特點和團隊特點靈活地選擇，是 “T”字形的成長模型：
- 廣度：做技術方案時，要有多種選擇，最好可以熟悉各個鏈路的關系
- 深度：要能解決一些別人搞不定的問題，至少也能指導從某個方向入手排查
其次，要充分理解業(yè)務并時刻關注業(yè)務變化，使架構(gòu)不僅能夠很好地支持業(yè)務特點，并具有一定的前瞻性。架構(gòu)師需要站在推進業(yè)務發(fā)展的角度上合理地改進和優(yōu)化架構(gòu)設計，為業(yè)務的快速發(fā)展做好保障。做“合適”的架構(gòu)非常重要，避免拿著錘子找釘子。
再者，要做一個靠譜并有良好的溝通和協(xié)調(diào)能力的人。架構(gòu)師往往要面臨著跨組、跨團隊甚至跨 BU 的一些技術方案，需要在互相信任的前提下溝通和協(xié)調(diào)各方的訴求和沖突。好的架構(gòu)師也可以讓業(yè)務、技術、團隊一起變得更好。
最后，我想說其實做架構(gòu)設計，并不代表一定要有一個架構(gòu)師的頭銜。每個人都可以參與到架構(gòu)設計中來，只要心中有大局有架構(gòu)思維，能理解當前架構(gòu)設計，不斷更好的優(yōu)化和執(zhí)行，就能寫出好代碼做出好架構(gòu)，提升整體的凝聚力和戰(zhàn)斗力。
要想成為好的架構(gòu)師，沒有什么捷徑可以走。持續(xù)的學習，不停的思考，多問為什么，多想想還能不能更好。愿大家都可以成為一個優(yōu)秀靠譜的程序員、架構(gòu)師。