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

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

 

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

 

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

 

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

 

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

 

在很多需要快速迭代實現(xiàn)原型的場合，這樣的能力模型是很合適的。問題在于在一個系統(tǒng)的開發(fā)中，多數(shù)情況下團隊成員負責(zé)開發(fā)的是獨立的模塊。而按照信息隱藏的理念，而只有在代碼模塊采用定義良好的接口來封裝，模塊的內(nèi)部結(jié)構(gòu)對外部不可見，復(fù)雜度被屏蔽而非暴露在他人模塊內(nèi)部結(jié)構(gòu)前的時候，開發(fā)的效率才是最高的，也并不是團隊中所有成員都需要了解系統(tǒng)整體的技術(shù)細節(jié)。并且，前端本身也是對開發(fā)職能分工的細化，在后端有成熟穩(wěn)定團隊的前提下，前端在團隊層面按照 Full Stack 的方向積累技術(shù)，在投入和產(chǎn)出上未必是最優(yōu)的。當(dāng)然，這和許多大廠「只招全?！沟睦砟畈⒉幻埽吘乖趥€人開發(fā)者層面的全棧所真正要求的并不是雜而全，而是高效地解決各類問題的學(xué)習(xí)能力，以及對技術(shù)更加全面的深入。

 

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

 

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

 

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

 

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

 

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

 

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

 

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