上一個星期一直忙於救火，週末又趕去參加了 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、前端、小程式... 不同的客戶端對介面有不同的需求、而且這些需求是多變的。另外後端業務也向微服務演化, 於是後端的介面會趨向原子化、功能更加單一、更加通用。
但是這對於前端開發來說也是比較痛苦的，實現一個頁面需要呼叫很多介面、隨之頁面效能也會降低。分層架構又派上用場，那就多加一層唄，這一層就是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
- 基礎很重要。彆著急學花裡胡哨的東西，彆著急跟著別人去看原始碼
- 嘗試去理解業務，理解商業和世界運作的規律，提升格局和軟技能
總結
小微企業的圍牆不能靠一個人就能推倒，業務的擴張和升級才是真正的動力。如果你覺得你公司有上升的動力和勢態，而且你認同公司的價值觀，不妨一起努力推動公司的進步。反之，要認真考慮自身的發展。
不說了，各自珍重，努力奮鬥
