<form id="xxnnn"></form>

    <form id="xxnnn"></form>
    <form id="xxnnn"></form>

        <form id="xxnnn"><nobr id="xxnnn"></nobr></form>

        APP開發咨詢熱線:0755-23578246 | 136-2233-6324歡迎來到深圳市來科信科技有限公司網站!
        您當前的位置:深圳APP開發 > 新聞資訊 > APP開發資訊 >

        已閱讀

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

        來源:lexintech.com ?? ?? 發布時間:2017-08-24
        在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 的成本還不如直接實現……熟悉業務后,這樣的場景總是容易發現的。
         
        網站開發 微信公眾號 APP開發 產品設計 用戶體驗 APP運營 APP開發公司 微信小程序 產品經理 網站設計
        免费看成年人视频在线观看 - 视频 - 在线观看 - 影视资讯 - 新赏网