if 我是前端Leader，怎麼走出小微前端團隊的圍牆?

上一個星期一直忙於救火，週末又趕去參加了 Tweb Conf(首次參加這類活動)，因此什麼輸出。可是這個星期的緊張、忙碌以及焦慮，讓我想明白了一些事情，寫了本文，沒什麼乾貨，只是一些絮絮不休。

上週對我來講還有一個重要的里程碑是掘金等級到達 LV5。目標已經達成了，這是一種釋然，我再也不想爲了獲取更多點贊、更多閱讀量去寫文章，再也不去取一些譁衆取寵的標題，再也不須要去證實什麼。我發現我打開掘金的頻率驟然下降了，之前一天可能 checkout 幾十次。

新的一年，但願可以沉下心來，深刻鑽研本身的方向，投放更多精力到參與開源上面。

大綱

• 小微/外包企業前端的困境
• 中臺的概念
• 先後端分離再分離
• 極簡的技術棧
• 避免'單點故障'
• 集體利益大於我的利益
• 談談我的的發展: 跳槽與跳槽路上
• 總結
• 擴展

小微/外包企業前端的困境

相信待在大廠的頭部程序員只是少數，大部分前端仍是蝸居在小微企業前端團隊(🔴注意：特指工程能力較弱的團隊，排除大廠和大牛創業公司)，望着大廠的圍牆。想象他們光鮮亮麗、充滿激情樣子。一樣是擰螺絲，一樣實踐着前端工程化、一樣用着Vue、React 全家桶，別人是搞的是航母上的鉚釘，你擰的是奧迪雙鑽的螺絲。

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

邊緣化

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

本質上是業務的性質和規模決定了前端的工做不會佔用太大比重，天然也不會受到太多重視, 可取代性也很高。這類公司每每是傳統行業，例如硬件、電力。相反依賴於端行業，如電商、社交，前端的地位會高不少。

這種環境下，前端不會關心太多業務，固然容易被邊緣化，扮演相聲裏面的捧哏角色。

協助混亂/基礎設施薄弱

小微企業，由於人員總體水平不高，協做一般也比較混亂、不規範。這裏指的是一個項目的總體研發協做。

對於前端來講，咱們的上游多是後端，後端的代碼質量和規範性對前端影響也會特別大。 例如接口混亂、文檔不規範、未考慮應用場景、接口不測試等等... 這種工做環境下，效率會很是低，前端開發會很是痛苦。

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

忙碌

感受天天都很忙碌，卻像什麼事情都沒有作。天天的工做重複一次又一次，原地踏步。

孤島

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

人員變更

吸引不了優秀的人才，並且優秀人才也留不住，總體水平較低，很難有技術沉澱和開拓。

理想/企業文化的認同感

咱們只是爲了賺錢，別跟我談什麼理想。咱們感受本身在被壓榨，是機器，這樣的工做天然不會有什麼幸福感。

等等等...

中臺的概念

今年中臺的概念的很火，我沒怎麼去關注它，由於我認爲它跟咱們前端的距離仍是比較遠，並且大廠才能搞得起來。直到在 TWeb Conf 上聽 張雲龍 講了 《Headless CMS——小微項目的業務中臺解決方案》 讓我對‘中臺’提起了興趣。

這裏有一篇文章《漫畫：什麼是中臺？》 通俗講解了中臺的概念。

不是大廠才能實踐中臺，我發現咱們的應用也存在不少重複的業務，每新建一個應用，後端都要重複去拷貝和實現這些業務。對於後端來講，資源很是浪費，對於前端來講也是一個災難。 由於咱們發現，儘管後端的業務本質上是重複的，可是由於人爲緣由，他們每一次拷貝暴露出來的接口和流程或多或少和以前的應用不一致，每次前端都須要從新適配。

張雲龍介紹了一個適合小微項目的業務中臺解決方案，它舉的例子是 Strapi: 這是一個Headless CMS, 翻譯爲中文就是'無頭'內容管理系統，和傳統 CMS 的最大區別是 Headless，即它只暴露接口，沒有固定的界面。

經過它, 你能夠實現：

• 可視化、快速的業務模型建立。相似建立數據庫模型（數據庫無關），能夠靈活地配置各類字段類型(除了原始類型、還支持郵箱、文件上傳)以及模型關係。
• 暴露規範的接口。支持 Restful 和 GraphQL。內置支持排序、分頁、過濾、自動生成文檔
• 內置權限控制系統。角色、JWT 鑑權
• 輕鬆集成內部系統。能夠靈活地與本身的內部系統對接
• 擴展性。插件系統

Headless CMS 是一種設用於小微企業的業務'中臺'解決方案。經過Strapi 咱們能夠快速搭建簡單的外圍業務模型, 複用通用的服務和插件。

你也能夠認爲這是一種分層的架構，隔離了核心業務和外圍業務。外層相比內層更加多變和冗雜，Strapi 中臺層隔離了 UI 和 核心服務，它讓核心服務能夠下沉，專一於實現更加通用的服務； 經過 Strapi 能夠快速搭建非核心的外圍衍生業務模式，暴露標準化的接口範式，一方面能夠及時響應前端多變的需求，另外一方面提供標準化、一致化的接口範式，也能夠下降溝通成本、提升開發效率。基於此, 前端也能夠沉澱本身的可複用的業務組件。

固然，正如張雲龍所說的，Strapi 相比大廠中臺，就是個玩具。但對於小微企業，迅速開發原型響應市場、提升研發效率，倒是一劑良藥。

先後端分離再分離

你會發現前端開發的體系化、正規化，其實伴隨着先後端分離逐步深化:

• 盤古開天：沒有先後端之分

• 模板時代: 按照MVC架構，後端負責MC, 實現業務，給前端提供數據。前端負責 V, 即寫模板。前端後在項目結構上並無分離，可是職責開始了分化。

• 接口時代：後端提供 HTTP/WS 接口，前端負責請求接口和實現頁面渲染。CSR(客戶端渲染)技術開始爆發，Backbone、Angular、React... 前端在項目結構上已經從後端脫離。開發效率進一步提升。接口就是一個約定，按照約定先行的原則，先後端能夠實現並行開發。可是這個階段後端接口實現仍是須要關心頁面的呈現，必須提供可以知足UI渲染的接口。

• BFF時代：BFF 即 Backends for Frontend。伴隨着陣痛，先後端進一步分離。主要有兩個緣由：終端多樣性，桌面端、iOS、Android、前端、小程序... 不一樣的客戶端對接口有不一樣的需求、並且這些需求是多變的。另外後端業務也向微服務演化, 因而後端的接口會趨向原子化、功能更加單1、更加通用。

  可是這對於前端開發來講也是比較痛苦的，實現一個頁面須要調用不少接口、隨之頁面性能也會下降。分層架構又派上用場，那就多加一層唄，這一層就是BFF，它讓客戶端開發者根據的本身需求在服務端來粘合後端的通用服務。這會後端不再用關心UI了。BFF 時代，GraphQL 和 NodeJS 備受矚目。

• Serverless時代：BFF 推行須要良好的基礎設施和研發流程支撐，架構難度也比較高，所以一般只有大廠搞得起來。Serverless 藉助雲平臺, 下降了對基礎設施的依賴，以及開發和維護的難度。 因此基於 Serverless 的 BFF 門檻更低。Serverless 對前端開發的意義不止於此，強烈推薦 《Serverless 掀起新的前端技術變革》 這篇文章。

後端不想關心 UI 呈現所須要的數據，只想關注於業務的實現。前端也想擺脫後端的下游依賴，既然你們都以爲不合適，分開是最好的。

回到開頭那句話，前端開發的體系化、正規化伴隨着前/後端的分離再分離，反之，正是由於前/後端分離的深化，前端開發得以正規化、體系化。上一節張雲龍介紹的‘中臺‘的概念，在某種意義上，也是一種先後端分離的深化。

所以，若是你的團隊感覺到了陣痛，其實也正好說明公司業務正處於上升狀態，如無心外，大家踏上前人走過的路，和後端進一步撕裂。

極簡的技術棧

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

這四個原則很是重要：

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

舉幾個例子:

‘簡單’主要是爲了減低學習的門檻、下降心智的負擔, 接口越簡潔越好：

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

‘自動化’，可以自動化解決的事情，就不要靠文檔規範、靠口頭溝通:

• ESlint、Styleint、HTMLlint、Markdownlint... *Lint。有各類各樣的 lint 工具和社區推薦規範，自動檢測各個環節是否符合規範。
• Prettier 代碼格式化。只有一種代碼樣式，別BB

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

'約束'，在事情失去控制時，我能體會到那種絕望。這時候你會但願當初有更多的約束，儘可能讓代碼保持在可控範圍以內。例如 Typescript，各類 *Lint。若是沒有約束機制，規範永遠只是規範。

避免'單點故障'

小微前端團隊，人員資源很是有限，每每每一個人負責不一樣的項目，這就可能出現‘單點故障’。假如這時候項目的負責人請假或者離職，就會讓人措手不及。一方面項目交接過程會拉長，另外一方面其餘成員上下文切換的成本也很高。咱們尤爲懼怕接手的項目是一個爛攤子。

解決單點故障的惟一辦法是讓更多的成員交叉參與不一樣的項目，項目的責任在於團隊而不在於我的。另外能夠配合例如代碼 Review 這些手段，多種途徑讓團隊成員能夠熟悉項目的代碼。

代碼規範和共享代碼在這裏也能夠起到很大的做用。若是'知識'能夠在多個項目中複用和共享，那麼項目上下文切換的成本就相對比較低。

集體利益大於我的利益

無論是大公司仍是小公司，集體的利益永遠是大於我的利益的。

上週作了兩個錯誤的決策，一個是批了一個緊急項目負責人請假，二是項目未完整測試上線就帶隊去參加Tweb Conf。這兩個決策致使很大的風險，也捱上級領導批評了，還好最後都搞定了。檢討如下幾點欠缺：

• 集體利益大於我的利益。這是咱們從小被灌輸的思想，在一個集體中，你的行爲和決策是須要對集體負責的。
• 對項目缺少總體的把控，沒有充分的風險評估。儘管前端只是一個完整項目的一環，做爲前端團隊Leader, 仍是須要從總體上了解項目的進度。你要知道項目的開始時間、截止時間、提測時間、開發/測試進度、當前資源狀況等。經過這些信息來進行制定資源的分配計劃和風險預估。
• 推進協做效率的改進。做爲團隊 Leader，就不能只單純關注技術和代碼。咱們須要去關注團隊之間的協做通道，提升團隊層面的協做效率，爲團隊成員掃除溝通方面的障礙。

就像我常常跟咱們的團隊夥伴說：問題不可怕，可怕的是不知道問題在哪裏，你要想進步、就要多反思、多問爲何...

談談我的的發展: 跳槽與跳槽路上

大公司有什麼?

小公司有什麼，可能什麼都沒有，百廢待興... 空間可能很大，天花板也可能很低。大部分狀況下，它可能只是你的一個跳板。你要麼在跳槽，要麼在跳槽路上，或者你已經麻木了，迷茫不知進退。

無論怎麼樣，小微企業的前端須要多考慮本身的我的發展。包括我本身也在不停地思考，不甘平庸，努力尋找能夠花一生去奮鬥的事業，而不僅是工做。

對於我的發展, 我有如下幾點建議：

• 肯定本身想要深刻挖掘方向。不少所謂的大牛大多都是某一具體領域的專家。前端目前也有不少細分領域。見 此次 Tweb Conf 的會場佈置就知道了，它細分了主會場(傳統前端)、小程序&工程化、Node&架構、跨端&綜合。另外GMTC 大會主題劃分也具備參考性
• 跳出本身的溫馨區, 去嘗試新的東西
• 勇氣。人有多大膽，地有多大產。沒有勇氣會錯過不少東西
• 參與社區, 樹立我的品牌
• Stay hungry，Stay foolish
• 基礎很重要。彆着急學花裏胡哨的東西，彆着急跟着別人去看源碼
• 嘗試去理解業務，理解商業和世界運做的規律，提高格局和軟技能

總結

小微企業的圍牆不能靠一我的就能推倒，業務的擴張和升級纔是真正的動力。若是你以爲你公司有上升的動力和勢態，並且你認同公司的價值觀，不妨一塊兒努力推進公司的進步。反之，要認真考慮自身的發展。

不說了，各自珍重，努力奮鬥

擴展

• Serverless For Frontend 前世此生
• Serverless 掀起新的前端技術變革