上一個星期一直忙于救火，但是這個星期的緊張、忙碌以及焦慮，讓我想明白了一些事情，寫了本文，只是一些絮絮叨叨。

[[284232]] 

圖片來自 Pexels

本文將從以下幾個部分展開：

• 小微/外包企業(yè)前端的困境
• 中臺的概念
• 前后端分離再分離
• 極簡的技術棧
• 避免“單點故障”
• 集體利益大于個人利益
• 談談個人的發(fā)展: 跳槽與跳槽路上
• 總結(jié)

小微/外包企業(yè)前端的困境

[[284233]] 

相信待在大廠的頭部程序員只是少數(shù)，大部分前端還是蝸居在小微企業(yè)前端團隊(特指工程能力較弱的團隊，排除大廠和大牛創(chuàng)業(yè)公司)，望著大廠的圍墻。

想象他們光鮮亮麗、充滿激情樣子。同樣是擰螺絲，同樣實踐著前端工程化、同樣用著 Vue、React 全家桶，別人搞的是航母上的鉚釘，你擰的是奧迪雙鉆的螺絲。

大廠談高大上技術、談架構，談場景。小微企業(yè)前端談溫飽，我們或多或少面臨這些困境：

①邊緣化

在這類公司，前端沒什么話語權，他們只是一個簡單頁面實現(xiàn)，簡稱切圖仔。

本質(zhì)上是業(yè)務的性質(zhì)和規(guī)模決定了前端的工作不會占用太大比重，自然也不會受到太多重視, 可取代性也很高。

這類公司往往是傳統(tǒng)行業(yè)，例如硬件、電力。相反依賴于前端行業(yè)，如電商、社交，前端的地位會高很多。

這種環(huán)境下，前端不會關心太多業(yè)務，當然容易被邊緣化，扮演相聲里面的捧哏角色。

②協(xié)助混亂/基礎設施薄弱

小微企業(yè)，因為人員整體水平不高，協(xié)作通常也比較混亂、不規(guī)范。這里指的是一個項目的整體研發(fā)協(xié)作。

對于前端來說，我們的上游可能是后端，后端的代碼質(zhì)量和規(guī)范性對前端影響也會特別大。

例如接口混亂、文檔不規(guī)范、未考慮應用場景、接口不測試等等... 這種工作環(huán)境下，效率會非常低，前端開發(fā)會非常痛苦。

基礎設施弱，前端工程化總感覺束手束腳。

③忙碌

感覺每天都很忙碌，卻像什么事情都沒有做。每天的工作重復一次又一次，原地踏步。

④孤島

像置身孤島，知識和消息是封閉的，個人能力和技術很難有大的突破。公司的格局決定個人的格局。

⑤人員變動

吸引不了優(yōu)秀的人才，而且優(yōu)秀人才也留不住，整體水平較低，很難有技術沉淀和開拓。

⑥理想/企業(yè)文化的認同感

我們只是為了賺錢，別跟我談什么理想。我們感覺自己在被壓榨，是機器，這樣的工作自然不會有什么幸福感。

等等等...

中臺的概念

今年中臺的概念的很火，我沒怎么去關注它，因為我認為它跟我們前端的距離還是比較遠，而且大廠才能搞得起來。

直到在 TWeb Conf 上聽張云龍講了《Headless CMS——小微項目的業(yè)務中臺解決方案》讓我對“中臺”提起了興趣：

https://juejin.im/post/5dd20202e51d453ff47f9c81#heading-2 

不是大廠才能實踐中臺，我發(fā)現(xiàn)我們的應用也存在很多重復的業(yè)務，每新建一個應用，后端都要重復去拷貝和實現(xiàn)這些業(yè)務。對于后端來說，資源非常浪費，對于前端來說也是一個災難。

因為我們發(fā)現(xiàn)，盡管后端的業(yè)務本質(zhì)上是重復的，但是因為人為原因，他們每一次拷貝暴露出來的接口和流程或多或少和之前的應用不一致，每次前端都需要重新適配。

 

張云龍介紹了一個適合小微項目的業(yè)務中臺解決方案，他舉的例子是 `Strapi`[5]：這是一個 Headless CMS。

翻譯為中文就是'無頭'內(nèi)容管理系統(tǒng)，和傳統(tǒng) CMS 的最大區(qū)別是 Headless，即它只暴露接口，沒有固定的界面。

通過它，你可以實現(xiàn)：

• 可視化、快速的業(yè)務模型創(chuàng)建。類似創(chuàng)建數(shù)據(jù)庫模型(數(shù)據(jù)庫無關)，可以靈活地配置各種字段類型(除了原始類型、還支持郵箱、文件上傳)以及模型關系。
• 暴露規(guī)范的接口。支持 Restful 和 GraphQL。內(nèi)置支持排序、分頁、過濾、自動生成文檔。
• 內(nèi)置權限控制系統(tǒng)。角色、JWT 鑒權。
• 輕松集成內(nèi)部系統(tǒng)。可以靈活地與自己的內(nèi)部系統(tǒng)對接。
• 擴展性。插件系統(tǒng)。

Headless CMS 是一種適用于小微企業(yè)的業(yè)務'中臺'解決方案。通過 Strapi 我們可以快速搭建簡單的外圍業(yè)務模型，復用通用的服務和插件。

你也可以認為這是一種分層的架構，隔離了核心業(yè)務和外圍業(yè)務。外層相比內(nèi)層更加多變和冗雜，Strapi 中臺層隔離了 UI 和 核心服務，它讓核心服務可以下沉，專注于實現(xiàn)更加通用的服務。

通過 Strapi 可以快速搭建非核心的外圍衍生業(yè)務模式，暴露標準化的接口范式。

一方面可以及時響應前端多變的需求，另一方面提供標準化、一致化的接口范式，也可以降低溝通成本、提高開發(fā)效率。基于此, 前端也可以沉淀自己的可復用的業(yè)務組件。

當然，正如張云龍所說的，Strapi 相比大廠中臺，就是個玩具。但對于小微企業(yè)，迅速開發(fā)原型響應市場、提高研發(fā)效率，卻是一劑良藥。

前后端分離再分離

你會發(fā)現(xiàn)前端開發(fā)的體系化、正規(guī)化，其實伴隨著前后端分離逐步深化：

盤古開天：沒有前后端之分。

模板時代：按照 MVC 架構，后端負責 MC，實現(xiàn)業(yè)務，給前端提供數(shù)據(jù)。前端負責 V，即寫模板。前端后在項目結(jié)構上并沒有分離，但是職責開始了分化。

接口時代：后端提供 HTTP/WS 接口，前端負責請求接口和實現(xiàn)頁面渲染。

CSR(客戶端渲染)技術開始爆發(fā)，Backbone、Angular、React...前端在項目結(jié)構上已經(jīng)從后端脫離。開發(fā)效率進一步提高。

接口就是一個約定，按照約定先行的原則，前后端可以實現(xiàn)并行開發(fā)。但是這個階段后端接口實現(xiàn)還是需要關心頁面的呈現(xiàn)，必須提供能夠滿足 UI 渲染的接口。

BFF 時代：BFF 即 Backends for Frontend。伴隨著陣痛，前后端進一步分離。

主要有兩個原因：終端多樣性，桌面端、iOS、Android、前端、小程序... 不同的客戶端對接口有不同的需求、而且這些需求是多變的。

另外后端業(yè)務也向微服務演化, 于是后端的接口會趨向原子化、功能更加單一、更加通用。

但是這對于前端開發(fā)來說也是比較痛苦的，實現(xiàn)一個頁面需要調(diào)用很多接口、隨之頁面性能也會降低。

分層架構又派上用場，那就多加一層唄，這一層就是 BFF，它讓客戶端開發(fā)者根據(jù)自己的需求在服務端來粘合后端的通用服務。

這會后端再也不用關心 UI 了。BFF 時代，GraphQL 和 NodeJS 備受矚目。

Serverless 時代：BFF 推行需要良好的基礎設施和研發(fā)流程支撐，架構難度也比較高，因此通常只有大廠搞得起來。

Serverless 借助云平臺, 降低了對基礎設施的依賴，以及開發(fā)和維護的難度。所以基于 Serverless 的 BFF 門檻更低。

Serverless 對前端開發(fā)的意義不止于此，強烈推薦 《Serverless 掀起新的前端技術變革》這篇文章：

https://zhuanlan.zhihu.com/p/65914436 

后端不想關心 UI 呈現(xiàn)所需要的數(shù)據(jù)，只想關注于業(yè)務的實現(xiàn)。前端也想擺脫后端的下游依賴，既然大家都覺得不合適，分開是最好的。

回到開頭那句話，前端開發(fā)的體系化、正規(guī)化伴隨著前/后端的分離再分離，反之，正是因為前/后端分離的深化，前端開發(fā)得以正規(guī)化、體系化。

上一節(jié)張云龍介紹的“中臺”的概念，在某種意義上，也是一種前后端分離的深化。

因此，如果你的團隊感受到了陣痛，其實也正好說明公司業(yè)務正處于上升狀態(tài)，如無意外，你們踏上前人走過的路，和后端進一步撕裂。

極簡的技術棧

Keep it Simple，Keep it Stupid。最近對這個原則體會頗深。小微團隊技術選型不應該隨大流、追隨最新最熱的技術，而是應該選擇符合自己的團隊水平和業(yè)務情況的極簡技術棧。

這四個原則非常重要：

• 簡單
• 自動化
• 清晰健全的文檔
• 約束

舉幾個例子，“簡單”，主要是為了減低學習的門檻、降低心智的負擔，接口越簡潔越好：

• 約定>配置。
• 顯式>隱式。
• 聲明式>命令式。
• 接口協(xié)議：JSONRPC>Restful。
• 構建工具：Parcel>Webpack，除此之外還有 Vue-cli，create-react-app。
• 框架：隨便舉個例子 Vue>React。Vue 入門會相對簡單，React 太靈活、社區(qū)百花齊放、盡管我很愛它，但是它沒辦法阻止別人干蠢事。
• 狀態(tài)管理：Mobx>Redux>Rxjs。
• 當然，具體場景具體分析

“自動化”，能夠自動化解決的事情，就不要靠文檔規(guī)范、靠口頭溝通：

• ESlint、Styleint、HTMLlint、Markdownlint... *Lint。有各種各樣的 lint 工具和社區(qū)推薦規(guī)范，自動檢測各個環(huán)節(jié)是否符合規(guī)范。
• Prettier 代碼格式化。只有一種代碼樣式，別 BB。

“文檔”，重要性不言而喻。有事先看文檔，再問別人。

“約束”，在事情失去控制時，我能體會到那種絕望。這時候你會希望當初有更多的約束，盡量讓代碼保持在可控范圍之內(nèi)。

例如 Typescript，各種 *Lint。如果沒有約束機制，規(guī)范永遠只是規(guī)范。

避免“單點故障”

小微前端團隊，人員資源非常有限，往往每個人負責不同的項目，這就可能出現(xiàn)“單點故障”。假如這時候項目的負責人請假或者離職，就會讓人措手不及。

一方面項目交接過程會拉長，另一方面其他成員上下文切換的成本也很高。我們尤其害怕接手的項目是一個爛攤子。

解決單點故障的唯一辦法是讓更多的成員交叉參與不同的項目，項目的責任在于團隊而不在于個人。

另外可以配合例如代碼 Review 這些手段，多種途徑讓團隊成員可以熟悉項目的代碼。

代碼規(guī)范和共享代碼在這里也可以起到很大的作用。如果知識可以在多個項目中復用和共享，那么項目上下文切換的成本就相對比較低。

集體利益大于個人利益

不管是大公司還是小公司，集體的利益永遠是大于個人利益的。

上周做了兩個錯誤的決策，一個是批了一個緊急項目負責人請假，二是項目未完整測試上線就帶隊去參加 Tweb Conf。

這兩個決策導致很大的風險，也挨上級領導批評了，還好最后都搞定了。

反省以下幾點欠缺：

• 集體利益大于個人利益。這是我們從小被灌輸?shù)乃枷耄谝粋€集體中，你的行為和決策是需要對集體負責的。
• 對項目缺乏整體的把控，沒有充分的風險評估。盡管前端只是一個完整項目的一環(huán)，作為前端團隊 Leader，還是需要從整體上了解項目的進度。

你要知道項目的開始時間、截止時間、提測時間、開發(fā)/測試進度、當前資源情況等。通過這些信息來進行制定資源的分配計劃和風險預估。

• 推動協(xié)作效率的改進。作為團隊 Leader，就不能只單純關注技術和代碼。我們需要去關注團隊之間的協(xié)作通道，提高團隊層面的協(xié)作效率，為團隊成員掃除溝通方面的障礙。

就像我經(jīng)常跟我們的團隊伙伴說：問題不可怕，可怕的是不知道問題在哪里，你要想進步、就要多反思、多問為什么。

談談個人的發(fā)展：跳槽與跳槽路上

大公司有什么?如下圖：

 

小公司有什么，可能什么都沒有，百廢待興... 空間可能很大，天花板也可能很低。

大部分情況下，它可能只是你的一個跳板。你要么在跳槽，要么在跳槽路上，或者你已經(jīng)麻木了，迷茫不知進退。

不管怎么樣，小微企業(yè)的前端需要多考慮自己的個人發(fā)展。包括我自己也在不停地思考，不甘平庸，努力尋找可以花一輩子去奮斗的事業(yè)，而不只是工作。

對于個人發(fā)展, 我有以下幾點建議：

• 確定自己想要深入挖掘方向。很多所謂的大牛大多都是某一具體領域的專家。前端目前也有很多細分領域。
• 跳出自己的舒適區(qū)，去嘗試新的東西。
• 勇氣。人有多大膽，地有多大產(chǎn)。沒有勇氣會錯過很多東西。
• 參與社區(qū)，樹立個人品牌。
• Stay hungry，Stay foolish。
• 基礎很重要。別著急學花里胡哨的東西，別著急跟著別人去看源碼。
• 嘗試去理解業(yè)務，理解商業(yè)和世界運作的規(guī)律，提升格局和軟技能。

總結(jié)

小微企業(yè)的圍墻不能靠一個人就能推倒，業(yè)務的擴張和升級才是真正的動力。

如果你覺得你公司有上升的動力和勢態(tài)，而且你認同公司的價值觀，不妨一起努力推動公司的進步。反之，要認真考慮自身的發(fā)展。

不說了，各自珍重，努力奮斗!