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

在APP開發公司中，前端是必不可(kě)缺的(de)崗位。有的(de)深圳APP開發公司比較重視前端設計，前端團隊實力還(hái)是比較強的(de)。樂(yuè)信科技lexintech就是一家注重産品設計的(de)深圳APP開發公司。下(xià)面樂(yuè)信小編跟大(dà)家聊一聊前端團隊如何進行技術積累。

前端是個(gè)挺特别的(de)崗位，一方面它的(de)技術棧更新幾乎是軟件開發領域中最快(kuài)的(de)，但另一方面它的(de)不可(kě)替代性相對(duì)而言卻并不算(suàn)高(gāo)。并且，雖然多(duō)數APP開發公司都有相對(duì)獨立的(de)前端團隊，但團隊多(duō)半都有不少業務負擔，加上前端較高(gāo)的(de)叠代速度，一線業務同學的(de)成長(cháng)多(duō)少容易遇到些瓶頸：需求都做(zuò)不完了(le)，還(hái)有時(shí)間讀源碼解析嗎？

 

其實我們都知道，個(gè)人(rén)成長(cháng)和(hé)團隊成長(cháng)是分(fēn)不開的(de)。一方面在技術氛圍較好的(de)團隊中個(gè)人(rén)的(de)進步會更快(kuài)，另一方面團隊的(de)技術積累也(yě)是由一個(gè)個(gè)成員(yuán)們貢獻出來(lái)的(de)。這(zhè)就引出了(le)我們的(de)問題：在業務團隊中，有什(shén)麽方法能讓個(gè)人(rén)和(hé)團隊在叠代中都得(de)到更好的(de)成長(cháng)呢(ne)？

 

能想到最簡單的(de)答(dá)案應該就是「定期技術分(fēn)享」和(hé)「不加班，給大(dà)家更多(duō)的(de)學習(xí)時(shí)間」這(zhè)樣的(de)吧。不隻是前端，相信這(zhè)肯定也(yě)是廣大(dà)開發同學們喜聞樂(yuè)見的(de)。可(kě)惜業務壓力擺在那裏，如果個(gè)人(rén)學習(xí)影(yǐng)響了(le)短期内的(de)團隊産出，那麽老闆們的(de)臉色也(yě)許會有些微妙……從另一個(gè)角度上來(lái)說，前端同學提升技能水(shuǐ)平所需學習(xí)的(de)各種模式、框架、類庫、工具，在開源社區(qū)都有非常詳盡的(de)文檔和(hé)教程，如何提升個(gè)人(rén)能力的(de)話(huà)題也(yě)更不是本文所能覆蓋的(de)。不過，如果一個(gè)前端團隊能夠通(tōng)過一些技術層面上的(de)方式，培養出由團隊成員(yuán)共建的(de)良好技術基礎的(de)話(huà)，相信老闆們和(hé)開發同學們都可(kě)以接受吧。這(zhè)其實也(yě)正是本文所關注的(de)。

 

在介紹「怎麽做(zuò)」之前，我們不妨考慮下(xià)「做(zuò)什(shén)麽」，即在什(shén)麽方向上去培養技術積累呢(ne)？

 

我們知道 Full Stack Developer 的(de)概念一直很火，那麽按照(zhào) Full Stack 的(de)概念，前端團隊的(de)所需的(de)技術積累是怎樣的(de)呢(ne)？這(zhè)意味著(zhe)前端團隊需要橫向地擴展自己的(de)能力，拉通(tōng) DB 到 HTML 的(de)流程。技術棧覆蓋面廣自然是好事，可(kě)是爲什(shén)麽還(hái)是經常能夠聽(tīng)見對(duì)全棧的(de)争議(yì)呢(ne)？

 

在很多(duō)需要快(kuài)速叠代實現原型的(de)場(chǎng)合，這(zhè)樣的(de)能力模型是很合适的(de)。問題在于在一個(gè)系統的(de)開發中，多(duō)數情況下(xià)團隊成員(yuán)負責開發的(de)是獨立的(de)模塊。而按照(zhào)信息隐藏的(de)理(lǐ)念，而隻有在代碼模塊采用(yòng)定義良好的(de)接口來(lái)封裝，模塊的(de)内部結構對(duì)外部不可(kě)見，複雜(zá)度被屏蔽而非暴露在他(tā)人(rén)模塊内部結構前的(de)時(shí)候，開發的(de)效率才是最高(gāo)的(de)，也(yě)并不是團隊中所有成員(yuán)都需要了(le)解系統整體的(de)技術細節。并且，前端本身也(yě)是對(duì)開發職能分(fēn)工的(de)細化(huà)，在後端有成熟穩定團隊的(de)前提下(xià)，前端在團隊層面按照(zhào) Full Stack 的(de)方向積累技術，在投入和(hé)産出上未必是最優的(de)。當然，這(zhè)和(hé)許多(duō)大(dà)廠「隻招全棧」的(de)理(lǐ)念并不矛盾，畢竟在個(gè)人(rén)開發者層面的(de)全棧所真正要求的(de)并不是雜(zá)而全，而是高(gāo)效地解決各類問題的(de)學習(xí)能力，以及對(duì)技術更加全面的(de)深入。

 

這(zhè)種模式下(xià)，前端的(de)職責并不僅僅局限在傳統的(de)客戶端 HTML + CSS + JS 中，而是一系列與用(yòng)戶交互相關的(de)技術合集。這(zhè)個(gè)背景下(xià)，可(kě)以把前端團隊理(lǐ)解爲一個(gè)垂直的(de)功能性的(de)團隊，技術積累上也(yě)是更多(duō)地圍繞著(zhe)我們所面對(duì)的(de)業務問題去做(zuò)沉澱。套用(yòng)《人(rén)月(yuè)神話(huà)》裏外科手術式團隊的(de)概念，如果說全棧的(de)角色更接近于全能的(de)「外科醫生」的(de)話(huà)，那麽 Full Life Cycle Engineer 則更接近于縱向深入的(de)「代碼專家」。

 

圍繞著(zhe)這(zhè)個(gè)理(lǐ)念展開，不難發現許多(duō)技術點是在團隊層面上可(kě)以去做(zuò)積累的(de)。那麽是否有必要去積累團隊内部的(de)輪子，又在什(shén)麽方向去做(zuò)呢(ne)？

 

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

 

如果編寫的(de)代碼都是不需要複用(yòng)的(de)「一次性」代碼，那麽文檔就是多(duō)餘的(de)；如果實現 UI 邏輯隻是爲了(le)滿足基本的(de)業務需要，那麽實際上是沒有什(shén)麽機會和(hé)必要去将單元測試落地的(de)；如果最終打出的(de)包始終隻是面向用(yòng)戶而非面向開發者，那麽甚至也(yě)不需要考慮 dependency 和(hé) devDependency 的(de)區(qū)别…工作内容限制在一個(gè)狹窄的(de)子集内的(de)時(shí)候，成長(cháng)顯然是會受限的(de)。

 

當然，以上引入的(de)工程化(huà)特性客觀上都需要時(shí)間投入，也(yě)不免會有重複造輪子浪費人(rén)力之嫌。這(zhè)時(shí)如何去做(zuò)權衡和(hé)取舍呢(ne)？

 

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

 

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