在阿里程帕，我們不得不承認一個事實：前端的確有價值住练，但放在全局來看，前端產(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è)務結構復雜度、業(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ù)不可信）眷射。

可用性要求高。可用性體現(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)開始嘗試突破天花板亿遂，進行「升維攻擊」浓若。我將其總結為這么三條：

• 向后走：從直接實現(xiàn)業(yè)務升級往后端方向推進，從加速整體研發(fā)效率
• 服務上下游：形成前端中臺蛇数，比如無痕數(shù)據(jù)打點系統(tǒng)七嫌，飛冰、AntDesign（包括集團內(nèi)部 BigFish / Basement）
• 服務前端：從服務業(yè)務變?yōu)榉掌渌岸斯こ處煱峁┣岸丝蚣堋ybrid 框架英妓、工具鏈挽放、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 測試眷昆、跟蹤結果，進而幫助產(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)絡、效能*粟耻。

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

總結

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

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

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

3a1ff193cee606bd1e2ea554a16353ee