APP開發公司的前端團隊如何技術積累？

在APP開發公司中，前端是必不可缺的崗位。有的深圳APP開發公司比較重視前端設計，前端團隊實力還是比較強的。樂信科技lexintech就是一家注重產品設計的深圳APP開發公司。下面樂信小編跟大家聊一聊前端團隊如何進行技術積累。

前端是個挺特別的崗位，一方面它的技術棧更新幾乎是軟件開發領域中最快的，但另一方面它的不可替代性相對而言卻并不算高。并且，雖然多數APP開發公司都有相對獨立的前端團隊，但團隊多半都有不少業務負擔，加上前端較高的迭代速度，一線業務同學的成長多少容易遇到些瓶頸：需求都做不完了，還有時間讀源碼解析嗎？

 

其實我們都知道，個人成長和團隊成長是分不開的。一方面在技術氛圍較好的團隊中個人的進步會更快，另一方面團隊的技術積累也是由一個個成員們貢獻出來的。這就引出了我們的問題：在業務團隊中，有什么方法能讓個人和團隊在迭代中都得到更好的成長呢？

 

能想到最簡單的答案應該就是「定期技術分享」和「不加班，給大家更多的學習時間」這樣的吧。不只是前端，相信這肯定也是廣大開發同學們喜聞樂見的。可惜業務壓力擺在那里，如果個人學習影響了短期內的團隊產出，那么老板們的臉色也許會有些微妙……從另一個角度上來說，前端同學提升技能水平所需學習的各種模式、框架、類庫、工具，在開源社區都有非常詳盡的文檔和教程，如何提升個人能力的話題也更不是本文所能覆蓋的。不過，如果一個前端團隊能夠通過一些技術層面上的方式，培養出由團隊成員共建的良好技術基礎的話，相信老板們和開發同學們都可以接受吧。這其實也正是本文所關注的。

 

在介紹「怎么做」之前，我們不妨考慮下「做什么」，即在什么方向上去培養技術積累呢？

 

我們知道 Full Stack Developer 的概念一直很火，那么按照 Full Stack 的概念，前端團隊的所需的技術積累是怎樣的呢？這意味著前端團隊需要橫向地擴展自己的能力，拉通 DB 到 HTML 的流程。技術棧覆蓋面廣自然是好事，可是為什么還是經常能夠聽見對全棧的爭議呢？

 

在很多需要快速迭代實現原型的場合，這樣的能力模型是很合適的。問題在于在一個系統的開發中，多數情況下團隊成員負責開發的是獨立的模塊。而按照信息隱藏的理念，而只有在代碼模塊采用定義良好的接口來封裝，模塊的內部結構對外部不可見，復雜度被屏蔽而非暴露在他人模塊內部結構前的時候，開發的效率才是最高的，也并不是團隊中所有成員都需要了解系統整體的技術細節。并且，前端本身也是對開發職能分工的細化，在后端有成熟穩定團隊的前提下，前端在團隊層面按照 Full Stack 的方向積累技術，在投入和產出上未必是最優的。當然，這和許多大廠「只招全棧」的理念并不矛盾，畢竟在個人開發者層面的全棧所真正要求的并不是雜而全，而是高效地解決各類問題的學習能力，以及對技術更加全面的深入。

 

這種模式下，前端的職責并不僅僅局限在傳統的客戶端 HTML + CSS + JS 中，而是一系列與用戶交互相關的技術合集。這個背景下，可以把前端團隊理解為一個垂直的功能性的團隊，技術積累上也是更多地圍繞著我們所面對的業務問題去做沉淀。套用《人月神話》里外科手術式團隊的概念，如果說全棧的角色更接近于全能的「外科醫生」的話，那么 Full Life Cycle Engineer 則更接近于縱向深入的「代碼專家」。

 

圍繞著這個理念展開，不難發現許多技術點是在團隊層面上可以去做積累的。那么是否有必要去積累團隊內部的輪子，又在什么方向去做呢？

 

這其實視團隊情況不同，是非常業務驅動的。比如，維護 C 端產品的團隊，可能更需要性能優化、監測告警方向的輪子，而開發 B 端中后臺產品的團隊，對狀態管理、統一組件庫一類的輪子需求度則會更高。在深入業務的過程中，幾乎總能找到特定的場景能夠抽取出特定的復用模塊，或找到適合針對性優化的地方，這其實就相當于技術積累的起點了：在業務驅動下開始造（甚至發明）團隊內部的輪子。其實造輪子對技術積累的促進，并不僅僅體現在實現輪子這件事本身。比如，即便是一個非常簡單的 UI 按鈕，在將它實現為可復用的代碼時，所需要做出的工程化努力都可以是很深度的。比如，即便一開始只在團隊內部使用，API 設計得簡單沒有關系，但作為一個可復用的模塊，怎么樣讓使用者不需要讀源碼就能用呢？這時候我們需要最基本的文檔；怎么樣保證升級后 API 穩定呢？這時候單元測試就體現出了意義；發布為模塊的話，樣式怎樣和組件一起提供呢？這時候需要的是構建流程……這些和基本業務邏輯并不直接相關的工程化內容，即便只是開發出一個簡單的內部輪子時都可以漸進地去考慮和實現。并且，這些工程化的特性也正是做技術積累的良好切入點。

 

如果編寫的代碼都是不需要復用的「一次性」代碼，那么文檔就是多余的；如果實現 UI 邏輯只是為了滿足基本的業務需要，那么實際上是沒有什么機會和必要去將單元測試落地的；如果最終打出的包始終只是面向用戶而非面向開發者，那么甚至也不需要考慮 dependency 和 devDependency 的區別…工作內容限制在一個狹窄的子集內的時候，成長顯然是會受限的。

 

當然，以上引入的工程化特性客觀上都需要時間投入，也不免會有重復造輪子浪費人力之嫌。這時如何去做權衡和取舍呢？

 

我們不妨評估一下引入新輪子的投入和產出。比如，分析一個沒有積累公共組件或依賴第三方組件庫的團隊，是否有開源項目中未能提供的 UI 組件，這些組件是否有復用的可能性和條件呢？如果有的話，引入工程化的發布流程會帶來多少時間成本，是否能夠方便其他同學在后續的使用中節約回來呢？再比如，是否存在業務場景是現有的開源輪子不能完全符合需求的？如果自己動手，能夠收獲多少易用性或性能上的提升呢？畢竟造輪子也是工程，而工程問題總是可以評估、分析和 Tradeoff 的。

 

實際上，前端領域中，由于業務場景的多樣性，開源輪子不能完全匹配實際需求的情況是很常見的。比如，Redux 是個用來支持復雜應用的狀態管理庫，在增查改刪的后臺應用中使用起來十分沉重；實現不需考慮兼容的簡單頁面時，自己封裝出的簡單 DOM 操作庫肯定比 jQuery 或 Zepto 更加輕量；封裝登錄認證庫時如果全部交互都通過 JSONP，那么依賴 fetch polyfill 或 axios 的成本還不如直接實現……熟悉業務后，這樣的場景總是容易發現的。