本文轉載自【微信公眾號：前端人，ID:FrontendPeople】經微信公眾號授權轉載，如需轉載與原文作者聯繫
前言
前陣子 winter 應邀來我司做分享, 有幸混了個圓桌嘉賓參與交流, 其中 winter 談到關於前端架構解決的問題域
從他在淘寶的經歷, 他理解當時他所做的前端架構主要解決的是大數量頁面生成的問題, 當時感觸不深.
在今天之前, 我對前端架構的理解一直是廣義的, 即架構本身要解決的就是複雜性, 將複雜的東西簡化, 以便更好的維護, 前端也脫離不開這個範疇, 但是今天因為要寫轉正
ppt
在構思腦圖的時候, 我突然意識到前端架構其實是有更明確地含義, 並且在這些年, 我們這些在不同領域從事前端架構工作的架構師都有自己的一些理解, 但此刻我突然發現了其中的共性, 這種發現讓我忍不住上來擼篇文章和大家做個分享
正文
多年以前, 我從不理解架構師, 到從事前端架構, 到自己產生了一些理解, 期間也寫了不少關於架構, 關於前端架構的文章, 但總感覺還是過於抽象
包括我和團隊的同學交流, 總覺得缺點什麼, 這種抽象和實際的架構工作之間還少了一層, 直到聽了 winter 的分享, 結合這些年的經驗, 我突然意識到, 前端架構是有具體的抽象問題域的, 而不是簡單的
用降低前端技術的複雜性來解釋, 在回答這個問題之前, 我想先說下客戶端軟體架構師 和 服務端架構師.
客戶端軟體架構師
考過軟考的應該知道軟考有個級別叫系統分析師, 或者有的也叫軟體架構師, 軟考對此的定義是能夠主持參與系統分析, 軟體架構等工作, winter 在分享的時候提到了客戶端軟體架構師, 在這裡是相同的含義
winter 指出客戶端軟體架構師的架構工作主要是為了控制解決客戶端軟體設計上的複雜性
一個客戶端系統, 尤其是類似 OA, ERP 開發周期從 6 到 12個月甚至更長, 這樣複雜的長期的軟體工程, 需要有專門的技術人員負責統籌把控代碼的質量, 而客戶端軟體架構師的工作就是圍繞這個展開的
因此客戶端軟體架構師解決的主要是軟體本身的複雜性.
服務端架構師
隨著 BS 的發展, 網際網路和大數據時代的來臨, 現在某些系統 1天產生的數據可能是過去傳統軟體 1年產生的數據, 這種極大量數據的操作帶來的問題變得日益嚴峻, 為此服務端架構師孕育而生, 服務端架構師始終圍繞如何降低因為數據操作量增長帶來的系統複雜性而努力
由此發展出來的高並發, 分布式, 微服務, 雲原生等等都是服務端架構師們為此努力的結果, 包括一些關於資料庫方面的學術性的成果, 例如最著名的 "CAP 定律"
重頭戲 → 前端架構師
架構師圍繞降低複雜性展開工作, 這一點我在之前的文章講得其實很多了, 而在這裡, winter 關於前端架構圍繞提升淘寶頁面的生產效率這件事的分享讓我有了一個更清晰更直接的認知
前端架構師們自始至終都在圍繞降低一件事的複雜性而努力.
那就是降低差異性需求增長帶來的複雜性這件事
為什麼這麼說?
我們不妨回想下, 在過去很長的時間內, 前端一直試圖通過可視化拖拽的方式來生成代碼, 現在我們稱其為
no-code
, 但是這種麼做的原因是什麼?
我們為什麼要試圖去做這樣一個系統, 從我的角度看, 可追溯的
系統最早可能就是那些建站工具類似於
XX CMS
這種, 由於服務端的數據操作天然和用戶是隔離的, 服務端工程師不需要為了解決用戶各種各樣的需求而去修改數據操作的基本代碼, 因此在沒有網際網路和大數據的年代, 軟體工程師中並沒有衍生出服務端架構師這樣的角色.
基於這樣的一種職業衍生路徑, 前端架構師的最早誕生可能就來自於對前端代碼的可視化開發需求, 就像 winter 說的, 當淘寶需要成千上百的運營頁面開發的時候, 大量的重複性工作根本無法依靠人力來完成, 為此小部分優秀的前端工程師開始演變成前端架構師, 他們從最初的研發工作轉變成為了降低這一問題的複雜性而努力思考的職業
但在這一時期, 前端架構師這個職業依然很模糊, 大家也不知道前端架構師是幹什麼的, 既沒有系統性的理論知識, 也沒有可複製的架構模式, 我們依然靠經驗來推動一些前端架構工作, 但隨著中後臺系統的發展, 需求帶來的複雜性, 從運營頁面擴展到了內部系統, 為此在阿里誕生了飛冰等一系列以物料為基礎構建中後臺的系統, 我理解這是前端架構的第二次發展
經過兩次發展的前端架構開始有了一些被沉澱下來的理論, 可複製的模式, 越來越多的可視化構建系統, 基於物料的前端搭建系統開始冒頭, 但在這一時期, 前端架構依然是模糊的, 同時前端架構師開始進入大家的視野, 越來越多的團隊開始招募前端架構師這樣的角色
但事實上大部分前端團隊招募前端架構師往往不是為了解決架構問題, 更多是為了解決團隊管理問題, 你仔細看那些招聘你會發現其實招聘的只是個更懂技術的前端 Leader 而已.
並且在這一時期, 因為部分 SPA 的複雜性加上混合開發模式的發展, 加上 Nodejs 帶來的全棧的概念, 進一步加重了前端架構領域的混亂, 我們越來越搞不清楚前端架構師到底要做什麼, 這種混亂也給這個職業發展本身帶來了極大的問題, 因為我們不知道要學習什麼, 因為我們不知道自己到底要解決什麼問題, 似乎前端所有的複雜性都需要架構師去解決.
也正是如此, 我才對前端架構師的理解傾向於廣義的架構師理解, 即一切技術的複雜性都是前端架構師要考慮的問題. 但現在看來這其實也是一個誤區.
讓我們剝開迷霧, 抓住核心.
前端架構師的核心工作是降低需求增長帶來的技術實現的複雜性
這句話可能有點繞口, 但展開來講並不複雜
因為運營頁面需求的增長, 我們打造運營頁面搭建系統來降低技術實現的複雜性
因為我們要在不同端實現相同的需求的增長, 我們開發各種通過 DSL 實現一次編寫多端生成的系統來降低實現需求的複雜性
因為內部系統重構的需求的增長, 我們基於 Next.js 這樣方案去打造中後臺搭建系統, 降低實現這一類需求的複雜性
像字節這種因為大量 App 生產的需求, 內部肯定搞了 App 工廠系統這樣的東西來降低這一類需求實現的複雜性
就像服務端實現微服務分布式有不同的技術選型, 前端也一樣, 打造相同的 no-code 系統你可以選不同的技術棧來實現
一個有經驗的服務端架構師可以快速搭建一套分布式系統來降低數據操作量增長的複雜性.
那麼一個有經驗的前端架構師就應該可以快速搞出上述這一套套東西來降低這類需求實現的複雜性.
因此, 一家公司如果沒有數據操作量上的增長, 比如流量, 大數據, 那他就不需要一個服務端架構師, 同理, 如果一家公司的前端需求增長依然是人力可控的範圍, 那他也不需要一個前端架構師. 最多需要一個前端 Leader.
後話
過去我只發現了成為架構師的思維轉變路徑, 和抽象的一些方法, 但現在我明確的知道如何去培養一名前端架構師.
大量的差異化的需求就是一個前端架構師成長的基石. 過去我們之所以沒有像服務端那樣誕生大量的前端架構師, 原因是在消費網際網路時代, 只有少數公司才會有大量的運營頁面的需求, 才有錢去搞內部系統翻新這種事情, 搞中後臺.
對前端架構師的需求遠遠少於對前端Leader 的需求, 為此很長一段時間, 前端專家這個角色在架構和管理之間遊走, 非常容易迷失自己.
但是顯然隨著產業網際網路的快速發展, 越來越多做企業服務的公司會需要前端架構師
因為企業的需求是高度定製化, 差異化, 幾乎不可能標準化的, 而前端架構師也不會需要一套拿來即用的類似飛冰這樣的系統, 而是應該會像服務端架構師一樣, 發展出更多框架和工具用來打造專屬於自己業務的類似飛冰這樣的系統
就像可視化搭建在很多公司都如火如荼的打造著, 可以說未來不會出現所謂大一統的前端可視化搭建系統, 而是會出現各種新的框架用來打造這種系統, 類似 SpringCloud, 我相信這也是前端開源社區的又一次巨大進步.