漫談先後端天花板

在阿里，咱們不得不認可一個事實：前端的確有價值，但放在全局來看，前端產生的價值並不是核心價值。 在阿里，雖然前端的工做已 經不可或缺，但對大公司而言，不可或缺的崗位多了去呢，不可或缺不表明有核心價值，我就不說了。

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

image from Abbey Arches Architecture - Free photo on Pixabay

和 G 總論道

前幾天和某大廠前端負責人 G 聊職業生涯發展，聊着聊着就談到了前端和後端職業天花板。 我表達了本身觀點：後端職業天花板更高，這是由職能細分決定。

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

有些同窗可能不服氣，如今基於 Node.js 也能寫後端應用，而且已經有愈來愈多成熟產品。 單頁應用推進了 React / React Native / Vue 等技術發展，這類前端框架也須要基於 MVC / MVVM 設計模式管理複雜數據流。 在端場景，Hybrid 應用愈發成熟，而且在一些特定領域好比 AI，iOS 也引入 Core ML 技術。 這樣天花板還不夠高麼？

是的，儘管前端近年發展迅猛，探索出多種新技術，從更普遍端技術來看，Android / iOS 也迎來爆炸式發展， 幾乎隱隱有勢頭蓋事後端趨勢。 隨着業務複雜度提高， Web Frontend / Android / iOS 開發困難度愈發提高；隨着科技普惠雲計算髮展， 技術門檻會進一步下降，當前前端工程師會有更寬闊空間。 可是仍然認爲後端是更難掌握，職業天花板更高。

聽我一一道來。

技術複雜度

爲了不爭執，咱們先來看看如何評估一項技術複雜度，拎出三個衡量技術複雜度維度：

• 業務複雜度（業務結構複雜度、業務類型複雜度、邏輯複雜度、流程複雜度、顆粒度 x 關聯業務複雜度、外部系統合做複雜度）
  • 量化指標：模型數量、模型屬性數量、業務流程長度、業務條件分支數量、外部合做系統數量
• 數據量複雜度（流量級別、業務數據量級、數據增加速度）
  • 量化指標：模型實例數量、服務用戶數量 x 用戶使用頻率、增加率
• 服務時效性（對外提供服務 SLA）
  • 量化指標：狀態數量、面向個體服務時間、面向羣體服務時間、在線要求可用率

因爲服務時效性是一個動態概念，先基於業務複雜度和數據量複雜度畫個簡圖：

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

• 前端位於左下（可能會涉及到 Diversified（多樣性），但即使如此，客戶端 Client 無數據持久化，複雜度有限）
• 後端位於右上（基礎設施工程師支持 Big，應用開發工程師支撐 Deversified（多樣性））
• 數據處於右上（基礎設施工程師支持 Big，數據開發工程師支撐 Deversified（多樣性））

後端難

爲何後端更難挑戰更大，有如下緣由：

貼近業務。後端是業務邏輯忠實實現方和執行者，全部業務鏈路、業務分支、主流程和旁路都須要在後端有實現。 因爲如今用戶體驗方面要求逐步提升，確實有很多業務鏈路和檢查動做在前端呈現出來。 但這種鏈路即使有呈現，後端仍是要進行建模、檢查校驗。 反觀前端阿喀琉斯之踵，運行在端（瀏覽器 / 手機端），對用戶透明，會面臨安全問題。 從而致使數據沒法持久化（即使持久化也是爲了性能，這些數據不可信）。

可用性要求高。可用性體如今兩個方面，實時可用性（也就是咱們常說的 SLA）與面向將來設計（或者說向前兼容）。 前者要求系統是能夠持續提供服務，這就帶來了高可用、可擴容要求。這對總體系統設計帶來了巨大挑戰。 單點算力可用性加強的模式已經被證實不可行，分佈式是被證實的可行道路。 後者對設計者提出了更高要求，系統須要兼容過去，還要給將來變化留下口子，當變化來臨時候才能夠低成本實現。 反觀端上技術，本地無狀態，無持久化數據，所以既沒有實時可用性要求，也沒有面向將來設計要求。

抽象程度高。抽象是爲了解決業務複雜性和易變性，將具體業務以合理可擴展方式設計好。 這也是貼近業務的直接體現。 爲了解決複雜業務下面抽象程度高問題，工程界提出了許多方法論。 設計層面有 DDD 領域驅動設計、微服務設計等；工程實施層面有各類設計模式、SOLID 開發模式、重構方法論等。 端上技術更多着眼在 UI 層面方法論：Reactive、Flux 數據流、動態熱更新等。

上下游空間大。後端處於研發鏈路中間，前承端，後啓運維數據算法，橫接運營產品項管。 從我周圍樣本觀察，當項目缺少負責人時候，每每會從後端開發工程師挑選資深一員做爲項目 Owner。 從人數上來看，後端每每也佔據開發大的大多數。 因爲上下游空間大，後端工程師職業天花板也會更開闊。轉 DevOps / SRE / 算法 / 數據的後端開發工程師比比皆是。 這種轉換很是天然，也提升了後端工程師的天花板。

貼近運行系統。當後端工程師部署他的項目，推進上線後，他每每須要對這個應用的運行環境有更多瞭解。 對於後端應用來講，生命週期多是開發一兩週，運行一兩年。這種模式下面倒逼後端對 Linux 服務器環境有更多瞭解。 不然在生產環境運行時候，缺少相關技能和工具掌握遇到問題就會一籌莫展。須要瞭解的還不只僅是 Linux 部署環境， 還有相關的基礎設施： RPC 系統、Queuing 隊列系統、緩存系統、容器化環境等等基礎設施。

給前端的建議

我看到有很多前端工程師們已經開始嘗試突破天花板，進行「升維攻擊」。我將其總結爲這麼三條：

• 向後走：從直接實現業務升級日後端方向推動，從加速總體研發效率
• 服務上下游：造成前端中臺，好比無痕數據打點系統，飛冰、AntDesign（包括集團內部 BigFish / Basement）
• 服務前端：從服務業務變爲服務其餘前端工程師，提供前端框架、Hybrid 框架、工具鏈、CICD 系統服務

PS：前端還有一類發力方向 - 複雜 UI 產品，好比 Web Editor，Google Doc、Office Online。 隨着大前端發展，這方面的空間已經大大擴充，Web / App 前端已經能夠基於 Flutter / Electronic 等技術作 PC 端應用。 但這類應用數量較少，開發技能點和常見應用開發差別較大，不做爲常規路線討論。

我給前端同窗的建議：

• 不要被手頭事情限制住，也不要被 Title 限制住，開闊本身的技術視野，和上下游多合做，去理解上游業務和下游技術點。 這個建議對後端工程師一樣合適。
• 往下深扎技術，往上學習架構知識。IE 優化技巧會過時，可是瀏覽器渲染流程和算法不會過時； HTTP1.1 到 HTTP 2.0 過程當中，協議會變化，可是定義問題，解決問題思路不會過時； iOS / Android 之上語言會轉變，可是基礎資源管理、IO 模式、TCP 協議不會過時

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

後端天花板

後端開發工程師瓶頸是什麼？我認爲是業務理解，而業務理解抓手是數據理解。 最樸素業務理解是幫助產品經理梳理需求，將其所構想產品工程化實現出來。 但以更高要求來對待時候，單純實現就遠遠不夠了，要考慮成本和收益。 好比用戶 Landing 頁面優化，投入一週時間進行開發這是成本，那麼指望到收益是什麼？ 更高的用戶轉化率。後端工程師是否有意識對這些數據進行建模、AB 測試、跟蹤結果，進而幫助產品、運營進行決策？

除了完成功能，數據理解還有另一個層面意義。在數據量規模到達一個量級時候，系統所追求不只僅是可用、穩定， 還須要從沉澱數據中挖掘業務內在關係，將數據模型展示出來。這個工做內容已經超越了後端工程師職責， 屬於數據工程師（還有一些叫法數倉管理員）職責。他們工做核心內容就是經過對業務數據挖掘，發現問題、解決問題，給予業務指導。 手段是創建體系化量化指標，將沉澱數據和平常業務關聯。

後端是否可能被取代？我認爲傳統應用開發工程師被取代機率高，將來 10 年左右時間能夠被取代。 爲何這麼說，什麼工種能夠被取代？越標準化的工種越容易被取代。應用業務開發通過這些過程：

1. 產品需求構思（產品經理拍腦子 / 數據決策）
2. 需求分析
3. 需求實現
4. 測試
5. 開發
6. 上線運行

應用開發工程師參與了 2 3 4 5 6 部分， 每一個部分產出物已經逐步呈現出標準化勢態。好比需求分析文檔+系統設計文檔，已經具有標準化雛形（離岸外包也是基於這個來開發）。 進一步想，若是一門語言描述能力足夠強，需求分析階段便可將實現完成。四、五、6 也能夠被自動化設施所取代。 應用開發工程師在整個工程師生態裏面是手的存在，而非腦存在。手老是能夠經過工具加強所替代。 咱們設想一種場景，讓業務方本身寫 SQL，而後根據 SQL 生成標準化的 DAO 模塊、Service 模塊、View 模塊、配套上合適的 UI 界面， 就能夠拿出去直接用了。

後端如何才能不被取代呢？ 在複雜度上面施力。複雜度能夠往兩個方向發展，對業務有更深入理解成爲業務專家。 支持大數據量和提供高可用性，成爲基礎設施專家，好比分佈式存儲、搜索、算法、芯片、網絡、效能*。

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

總結

後端天花板更高，但之因此高並不是語言等技術因素帶來的，本質緣由是貼合業務更近、須要處理數據更多、有狀態而且須要長期提供服務。 前端突破天花板就不是前端，後端突破天花板就不是後端，不要被角色限定本身學習內容，不要給本身劃定邊界。

最後提一個問題，如今愈來愈火的 Serverless，若是後端來建設該如何建設？若是前端來建設該如何建設？

---

原文連接: 漫談先後端天花板 - Log4D

歡迎關注個人微信公衆號：窺豹

3a1ff193cee606bd1e2ea554a16353ee