在阿里，我們不得不承認一個事實：前端的確有價值，但放在全局來看，前端產(chǎn)生的價值并非核心價值。 在阿里，雖然前端的工作已 經(jīng)不可或缺，但對大公司而言，不可或缺的崗位多了去呢，不可或缺不代表有核心價值，我就不說了。

- 玉伯 2013 年 阿里前端的困局與突圍

ceilling

<small>image from Abbey Arches Architecture - Free photo on Pixabay</small>

和 G 總論道

前幾天和某大廠前端負責人 G 聊職業(yè)生涯發(fā)展，聊著聊著就談到了前端和后端職業(yè)天花板。 我表達了自己觀點：后端職業(yè)天花板更高，這是由職能細分決定。

后端（服務端）概念比較寬泛，常見分類可以有應用開發(fā)工程師、中間件工程師、甚至可以包含運維、數(shù)據(jù)工程師、算法工程師。 本文我只將后端工程師限定在應用開發(fā)工程師以及衍生的框架、庫開發(fā)工程師。 前端這邊由于引入大前端概念，概念也比較廣，包含：Web 前端、移動端（iOS + Android 客戶端）、桌面端（PC 端）。 我們也限定在這幾個方向的應用開發(fā)。

有些同學可能不服氣，現(xiàn)在基于 Node.js 也能寫后端應用，并且已經(jīng)有越來越多成熟產(chǎn)品。 單頁應用推動了 React / React Native / Vue 等技術發(fā)展，這類前端框架也需要基于 MVC / MVVM 設計模式管理復雜數(shù)據(jù)流。 在端場景，Hybrid 應用愈發(fā)成熟，并且在一些特定領域比如 AI，iOS 也引入 Core ML 技術。 這樣天花板還不夠高么？

是的，盡管前端近年發(fā)展迅猛，探索出多種新技術，從更廣泛端技術來看，Android / iOS 也迎來爆炸式發(fā)展， 幾乎隱隱有勢頭蓋過后端趨勢。 隨著業(yè)務復雜度提升， Web Frontend / Android / iOS 開發(fā)困難度愈發(fā)提升；隨著科技普惠云計算發(fā)展， 技術門檻會進一步降低，當前前端工程師會有更寬闊空間。 但是仍然認為后端是更難掌握，職業(yè)天花板更高。

聽我一一道來。

技術復雜度

為了避免爭執(zhí)，我們先來看看如何評估一項技術復雜度，拎出三個衡量技術復雜度維度：

• 業(yè)務復雜度（業(yè)務結(jié)構復雜度、業(yè)務類型復雜度、邏輯復雜度、流程復雜度、顆粒度 x 關聯(lián)業(yè)務復雜度、外部系統(tǒng)合作復雜度）
  • 量化指標：模型數(shù)量、模型屬性數(shù)量、業(yè)務流程長度、業(yè)務條件分支數(shù)量、外部合作系統(tǒng)數(shù)量
• 數(shù)據(jù)量復雜度（流量級別、業(yè)務數(shù)據(jù)量級、數(shù)據(jù)增長速度）
  • 量化指標：模型實例數(shù)量、服務用戶數(shù)量 x 用戶使用頻率、增長率
• 服務時效性（對外提供服務 SLA）
  • 量化指標：狀態(tài)數(shù)量、面向個體服務時間、面向群體服務時間、在線要求可用率

由于服務時效性是一個動態(tài)概念，先基于業(yè)務復雜度和數(shù)據(jù)量復雜度畫個簡圖：

    ^
  D |    +-------------+     +-------------+
  a |    |             |     |             |
  t |    |    Big      |     |  Complex    |
  a |    |             |     |             |
    |    +-------------+     +-------------+
  s |                                 
  i |                                 
  z |    +-------------+     +-------------+
  e |    |             |     |             |
    |    |    Simple   |     | Diversified |
    |    |             |     |             |
    |    +-------------+     +-------------+
    |
    +----------------------------------------> 
                                    Business Logic

• 前端位于左下（可能會涉及到 Diversified（多樣性），但即便如此，客戶端 Client 無數(shù)據(jù)持久化，復雜度有限）
• 后端位于右上（基礎設施工程師支持 Big，應用開發(fā)工程師支撐 Deversified（多樣性））
• 數(shù)據(jù)處于右上（基礎設施工程師支持 Big，數(shù)據(jù)開發(fā)工程師支撐 Deversified（多樣性））

后端難

為什么后端更難挑戰(zhàn)更大，有以下原因：

貼近業(yè)務。后端是業(yè)務邏輯忠實實現(xiàn)方和執(zhí)行者，所有業(yè)務鏈路、業(yè)務分支、主流程和旁路都需要在后端有實現(xiàn)。 由于現(xiàn)在用戶體驗方面要求逐步提高，確實有不少業(yè)務鏈路和檢查動作在前端呈現(xiàn)出來。 但這種鏈路即便有呈現(xiàn)，后端還是要進行建模、檢查校驗。 反觀前端阿喀琉斯之踵，運行在端（瀏覽器 / 手機端），對用戶透明，會面臨安全問題。 從而導致數(shù)據(jù)無法持久化（即便持久化也是為了性能，這些數(shù)據(jù)不可信）。

可用性要求高?？捎眯泽w現(xiàn)在兩個方面，實時可用性（也就是我們常說的 SLA）與面向未來設計（或者說向前兼容）。 前者要求系統(tǒng)是可以持續(xù)提供服務，這就帶來了高可用、可擴容要求。這對整體系統(tǒng)設計帶來了巨大挑戰(zhàn)。 單點算力可用性增強的模式已經(jīng)被證明不可行，分布式是被證明的可行道路。 后者對設計者提出了更高要求，系統(tǒng)需要兼容過去，還要給未來變化留下口子，當變化來臨時候才可以低成本實現(xiàn)。 反觀端上技術，本地無狀態(tài)，無持久化數(shù)據(jù)，因此既沒有實時可用性要求，也沒有面向未來設計要求。

抽象程度高。抽象是為了解決業(yè)務復雜性和易變性，將具體業(yè)務以合理可擴展方式設計好。 這也是貼近業(yè)務的直接體現(xiàn)。 為了解決復雜業(yè)務下面抽象程度高問題，工程界提出了許多方法論。 設計層面有 DDD 領域驅(qū)動設計、微服務設計等；工程實施層面有各種設計模式、SOLID 開發(fā)模式、重構方法論等。 端上技術更多著眼在 UI 層面方法論：Reactive、Flux 數(shù)據(jù)流、動態(tài)熱更新等。

上下游空間大。后端處于研發(fā)鏈路中間，前承端，后啟運維數(shù)據(jù)算法，橫接運營產(chǎn)品項管。 從我周圍樣本觀察，當項目缺乏負責人時候，往往會從后端開發(fā)工程師挑選資深一員作為項目 Owner。 從人數(shù)上來看，后端往往也占據(jù)開發(fā)大的大多數(shù)。 由于上下游空間大，后端工程師職業(yè)天花板也會更開闊。轉(zhuǎn) DevOps / SRE / 算法 / 數(shù)據(jù)的后端開發(fā)工程師比比皆是。 這種轉(zhuǎn)換非常自然，也提高了后端工程師的天花板。

貼近運行系統(tǒng)。當后端工程師部署他的項目，推動上線后，他往往需要對這個應用的運行環(huán)境有更多了解。 對于后端應用來說，生命周期可能是開發(fā)一兩周，運行一兩年。這種模式下面倒逼后端對 Linux 服務器環(huán)境有更多了解。 否則在生產(chǎn)環(huán)境運行時候，缺乏相關技能和工具掌握遇到問題就會束手無策。需要了解的還不僅僅是 Linux 部署環(huán)境， 還有相關的基礎設施： RPC 系統(tǒng)、Queuing 隊列系統(tǒng)、緩存系統(tǒng)、容器化環(huán)境等等基礎設施。

給前端的建議

我看到有不少前端工程師們已經(jīng)開始嘗試突破天花板，進行「升維攻擊」。我將其總結(jié)為這么三條：

• 向后走：從直接實現(xiàn)業(yè)務升級往后端方向推進，從加速整體研發(fā)效率
• 服務上下游：形成前端中臺，比如無痕數(shù)據(jù)打點系統(tǒng)，飛冰、AntDesign（包括集團內(nèi)部 BigFish / Basement）
• 服務前端：從服務業(yè)務變?yōu)榉掌渌岸斯こ處煟峁┣岸丝蚣?、Hybrid 框架、工具鏈、CICD 系統(tǒng)服務

PS：前端還有一類發(fā)力方向 - 復雜 UI 產(chǎn)品，比如 Web Editor，Google Doc、Office Online。 隨著大前端發(fā)展，這方面的空間已經(jīng)大大擴充，Web / App 前端已經(jīng)可以基于 Flutter / Electronic 等技術做 PC 端應用。 但這類應用數(shù)量較少，開發(fā)技能點和常見應用開發(fā)差異較大，不作為常規(guī)路線討論。

我給前端同學的建議：

• 不要被手頭事情限制住，也不要被 Title 限制住，開闊自己的技術視野，和上下游多合作，去理解上游業(yè)務和下游技術點。 這個建議對后端工程師同樣合適。
• 往下深扎技術，往上學習架構知識。IE 優(yōu)化技巧會過期，但是瀏覽器渲染流程和算法不會過期； HTTP1.1 到 HTTP 2.0 過程中，協(xié)議會變化，但是定義問題，解決問題思路不會過期； iOS / Android 之上語言會轉(zhuǎn)變，但是基礎資源管理、IO 模式、TCP 協(xié)議不會過期

螞蟻體驗技術使用另外一種模式規(guī)避了這個問題，將前端概念從「端」擴展到「體驗技術」。 格局一下子擴大，不再限于在用戶瀏覽器運行，關注邊界擴大到用戶使用的方方面面。 他們推出的 語雀 Lark、AntDesign 以及背后支持的 Basement 開發(fā)者技術棧也確實給使用者帶來更好體驗， 加速了開發(fā)者速度，降低了前端工程師開發(fā)門檻，完整詮釋了「體驗技術」意義。 關于「體驗技術部」故事，你可以看 那些年的體驗技術部 - 知乎 了解更多。

后端天花板

后端開發(fā)工程師瓶頸是什么？我認為是業(yè)務理解，而業(yè)務理解抓手是數(shù)據(jù)理解。 最樸素業(yè)務理解是幫助產(chǎn)品經(jīng)理梳理需求，將其所構想產(chǎn)品工程化實現(xiàn)出來。 但以更高要求來對待時候，單純實現(xiàn)就遠遠不夠了，要考慮成本和收益。 比如用戶 Landing 頁面優(yōu)化，投入一周時間進行開發(fā)這是成本，那么期望到收益是什么？ 更高的用戶轉(zhuǎn)化率。后端工程師是否有意識對這些數(shù)據(jù)進行建模、AB 測試、跟蹤結(jié)果，進而幫助產(chǎn)品、運營進行決策？

除了完成功能，數(shù)據(jù)理解還有另外一個層面意義。在數(shù)據(jù)量規(guī)模到達一個量級時候，系統(tǒng)所追求不僅僅是可用、穩(wěn)定， 還需要從沉淀數(shù)據(jù)中挖掘業(yè)務內(nèi)在關系，將數(shù)據(jù)模型展現(xiàn)出來。這個工作內(nèi)容已經(jīng)超越了后端工程師職責， 屬于數(shù)據(jù)工程師（還有一些叫法數(shù)倉管理員）職責。他們工作核心內(nèi)容就是通過對業(yè)務數(shù)據(jù)挖掘，發(fā)現(xiàn)問題、解決問題，給予業(yè)務指導。 手段是建立體系化量化指標，將沉淀數(shù)據(jù)和日常業(yè)務關聯(lián)。

后端是否可能被取代？我認為傳統(tǒng)應用開發(fā)工程師被取代概率高，未來 10 年左右時間可以被取代。 為什么這么說，什么工種可以被取代？越標準化的工種越容易被取代。應用業(yè)務開發(fā)經(jīng)過這些過程：

1. 產(chǎn)品需求構思（產(chǎn)品經(jīng)理拍腦子 / 數(shù)據(jù)決策）
2. 需求分析
3. 需求實現(xiàn)
4. 測試
5. 開發(fā)
6. 上線運行

應用開發(fā)工程師參與了 2 3 4 5 6 部分， 每個部分產(chǎn)出物已經(jīng)逐步呈現(xiàn)出標準化勢態(tài)。比如需求分析文檔+系統(tǒng)設計文檔，已經(jīng)具備標準化雛形（離岸外包也是基于這個來開發(fā)）。 進一步想，如果一門語言描述能力足夠強，需求分析階段即可將實現(xiàn)完成。4、5、6 也可以被自動化設施所取代。 應用開發(fā)工程師在整個工程師生態(tài)里面是手的存在，而非腦存在。手總是可以通過工具增強所替代。 我們設想一種場景，讓業(yè)務方自己寫 SQL，然后根據(jù) SQL 生成標準化的 DAO 模塊、Service 模塊、View 模塊、配套上合適的 UI 界面， 就可以拿出去直接用了。

后端如何才能不被取代呢？ 在復雜度上面施力。復雜度可以往兩個方向發(fā)展，對業(yè)務有更深刻理解成為業(yè)務專家。 支持大數(shù)據(jù)量和提供高可用性，成為基礎設施專家，比如分布式存儲、搜索、算法、芯片、網(wǎng)絡、效能*。

另外一種升維辦法是成為技術團隊技術管理者，融合技術領導者和團隊管理者兩種技能。

總結(jié)

后端天花板更高，但之所以高并非語言等技術因素帶來的，本質(zhì)原因是貼合業(yè)務更近、需要處理數(shù)據(jù)更多、有狀態(tài)并且需要長期提供服務。 前端突破天花板就不是前端，后端突破天花板就不是后端，不要被角色限定自己學習內(nèi)容，不要給自己劃定邊界。

最后提一個問題，現(xiàn)在越來越火的 Serverless，如果后端來建設該如何建設？如果前端來建設該如何建設？

原文鏈接: 漫談前后端天花板 - Log4D

3a1ff193cee606bd1e2ea554a16353ee