高效前端團隊的秘密

前言

看到前端團隊成為整個項目的瓶頸的時候，這兩年來痛過。今日早讀文章由今目標移動端負責人 @houyulei 授權分享。

正文從這開始~

前端開發的挑戰

如果說，服務端開發的最主要的挑戰是保證服務的高可用性、高穩定性、高安全性、高擴展性，那前端開發的最主要的挑戰是什麼？

在我看來，除了某些情況下的多端適配，就是：

在需求多變的情況下能快速迭代，且保證質量。

簡單說就是：又快又好

前端交互和業務自有其易變性和複雜性，產品經理或設計提出改動時，前端開發深受其苦。在改版或開發新端時，如果服務端架構合理，服務端基本只需做少量改動；但對前端基本意味著要完全重寫。

但是由於：

個人局限

項目上線前無法取得數據支撐

業務的發展

時代和趨勢的變化

...

導致產品的變更，升級，重構不可避免；新的項目又會接連不斷，因此前端開發往往成了整個團隊的瓶頸。市場上缺前端的聲音此起彼伏，我也不止聽過一個老闆談到前端是卡脖子的地方。

問題在哪呢？

問題在於很多前端團隊沒有像後端一樣，有一個更高層次的抽象，把產品的視覺，交互，邏輯，數據做分層隔離。耦合的成本是巨大的，當視覺，交互或某處邏輯變動時，很難對應修改；同時也難以復用，每個應用的開發都幾乎從0開始。也許會有一些公共UI插件各項目共用，但是這樣遠遠不夠。

前端項目估期

傳統的前端開發估期，是按照頁面數量和頁面複雜度來預估。

比如兩個簡單的新聞列表，新聞詳情頁面，新聞列表可以下拉刷新，上拉載入更多，可以推送，可以滑動切換不同的新聞分類頻道。新聞詳情可以Like，可以評論，可以看其他人的評論。

可以想像估期的時間很大程度上取決於現在是否有合適的組件：下拉刷新，上拉載入更多，切換滑動。以我的經驗，如果沒有這方面的積累，這三個組件達到優良的效果（主要是性能）至少需要15d的時間。

如果組件有了，那可以這樣預估，兩個頁面的顯示並不複雜1d完成靜態頁面製作。列表頁的業務有以下幾個：

下拉刷新，上拉載入更多，列表切換-組件集成2h

推送，刷新，載入介面聯調 2h

列表渲染 4h

不錯，看起來1天能搞定，但等等，好像漏了些什麼。

無網怎麼辦，是否有數據緩存 2h

列表為空怎麼辦，請求異常怎麼辦 2h

列表如果有圖片要不要做延遲載入？ 4h

無限載入？列表太長怎麼辦？

再來估詳情頁的時間：

詳情頁渲染 1h

Like 2h

評論會有些複雜，比如輸入校驗，字數校驗，空校驗，現在假設我們有了一個輸入框組件幫我們解決了這些問題。

那需要：

評論發布 4h

評論列表 4h

評論列表分頁-可能用到上面的上拉載入更多組件 2h

理想情況有了需要的組件的情況下，我們需要用5d的完成功能開發。當然這是理想情況，實際情況因為前後端聯調，需求變更，跟原生客戶端交互等問題，需要多出大概50%的時間，也就是7.5d。

但如果從0開始，這個項目會實際耗費30d。

我們已經能夠看到組件庫的巨大威力，更進一步我們可以把延遲載入，評論也封裝成組件。開發時間可以進一步縮短。

但是這個例子的特殊之處是業務非常簡單，實際項目中會遇到一些業務複雜的項目，業務開發時間佔比會高一些。

如果這個項目交互優化了或者視覺變或者服務端介面變了，又會怎樣？

很遺憾，如果我們架構不合理，這會是個大麻煩。

因為前端開發有個傳統，根據設計稿自頂向下開發，根據交互寫頁面邏輯。因此當視覺設計或交互改變時，不可避免的要重構業務實現的邏輯。

業務邏輯和頁面的交互是強關聯的，同時後端請求也是寫在業務邏輯里。

如果我們用的是React，這會體現在React Component會比較臃腫，有很多響應頁面交互的邏輯，也有向服務端發送請求的邏輯。

這種模式有很多問題，這裡不做展開，只是指出，這種模式當視覺、交互變更或介面變更時，必須很小心的修改對應的Component，維護、測試成本很高。

團隊的開發效率

團隊的開發效率並不是個人開發效率的簡單相加，而是要做乘法。

因為我們可以從多個項目中提取公共部分進行抽象，封裝，優化，測試；這部分將作為基礎設施沉澱。

實際中，公司內部的各項目可抽象出的共同部分很可能會多於異同部分，因此項目越多，沉澱的越多，開發效率是會大幅上升的。因此，1個人可以負責1個項目，但5個人組成的高效團隊可以負責10個項目，其中的秘訣就是：

優良的軟體架構和合理的團隊配比。

優秀的工程師的效率秘訣也在這裡，優秀的工程師總是盡量避免做重複的工作，並對相似的一類工作做一種抽象的統一處理。

如果沒有合理的前端架構或者團隊組成，那就糟糕了，因為隨著項目的增長，面臨的狀況會愈加複雜化。很可能需要20人的團隊去負責10個項目，並且完成質量也不高。相差4倍,有這麼誇張嗎？真的有這麼誇張。業界有「10倍效率的開發人員(10x developer)」這樣的說法，放到團隊身上，只會放大這種現象。

低效，就是老闆說前端是卡脖子的地方的根本原因。

下面我們講講什麼是優良的軟體架構和合理的團隊配比。

優良的前端架構

這是很大個主題，並不是本文主要想表達的內容。這裡只列出一些原則：

團隊代碼規範與風格統一

組件庫，包括樣式組件，UI組件，基礎組件，業務組件

數據模型（domain），業務邏輯（state），view（React組件）三者分離；view只是很薄的一層，無邏輯

ES2017/TypeScript

Unit Test

高效前後端協作-Swagger

我在工作中有一些實踐，取得了不錯的效果：今目標前端技術體系

合理的團隊配比

可以把開發人員分為4個等級：

專家

高級

初級

不合格

和兩個維度：

能力：高、中、低

投入：高、中，低

其中絕大部分工程師的投入是中偏高，如果公司認為很多工程師投入不夠，那公司要反思是不是公司文化和公司管理出了問題。能力中低投入低的工程師即為不合格的工程師，合理的團隊不需要他們。

初級工程師：

快速成長，能力成長速度大於工資成長速度，因此公司能獲得更多溢價收益。

在公司一路成長，對公司更有認同感，穩定性更好。

輔助高級工程師工作，減輕高級工程師的壓力，有利於高級工程師focus更有挑戰的業務。

不是所有的初級工程師都能成長為高級工程師，不能以資歷提拔。

很多團隊會犯把初級工程師當高級工程師使用的錯誤，讓初級工程師獨立負責一塊業務，會有比較大的隱患。

高級工程師：

高級工程師的一個標準是能全部吸收理解當前的技術架構，因此有能力基於架構高效完成業務開發。

高級工程師是團隊的骨幹，他們是能保證技術架構落地和項目順利推進的核心。

高級工程師會做初級工程師的導師，指導初級工程師的成長，同時他們在某些領域會補足技術專家的短板。

一個完美的團隊是成員有各自不同的專長，類似木桶原理，團隊的瓶頸在某個細分領域的最短板；當高級工程師和技術專家能各有所長時，團隊戰鬥力是最強的。

投入度高或有專長的高級工程師是公司最寶貴的財富，請善待他們。

我建議的初級，高級工程師配比是1:1，導師制。

技術專家：

技術專家同時可能是Team Leader，當項目較小或團隊較小時，不太需要這樣一位角色。但當團隊大於6人，業務又多時，技術專家又是至關重要的一個角色。因為正如上文所述，好的技術專家可以幫助大幅提升團隊開發效率。技術專家更像一個光環型的角色，可以顯著的影響團隊效率，高低相差幾倍。

技術專家設計搭建的前端架構，影響深遠，甚至會影響公司未來幾年的項目開發。切換技術棧的成本非常高。

兵熊熊一個，將熊熊一窩。一個糟糕的leader會讓公司遭受非常大的損失。

好的技術專家可以打造一個專業合理的團隊，讓團隊開發效率成倍增加。

好的前端技術專家可遇而不可求，遇到請珍惜。

關於本文

作者：@houyulei

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！