【51CTO.com原創稿件】縱觀互聯網的發展歷史，沒有哪一刻能像現在這樣，存在如此豐富多彩的前端技術。前端技術的發展伴隨著互聯網的發展，逐步成為一個獨立的技術世界，跨越了從BBS、門戶、搜索、社交媒體平臺、APP等互聯網各個黃金發展階段。隨著互聯網行業發展格局的頻繁演進，各個研發團隊也從人才稀缺過渡到了人員即將飽和的階段，前端團隊亦是如此，隨之而來的實質性問題正亟待解決：

· 團隊成員越來越多

· 跨團隊協作越來越多

· 業務系統越來越復雜

· 框架越來越多

· 性能要求越來越高

· 可維護性越來越差

滴滴出行租售業務前端負責人譙洪敏在WOT2018全球軟件與運維技術峰會上從組件與模塊設計理念，復用性、規范化、效率工具、基于Git-flow的分支管理和埋點等方面對以上前端問題進行了詳細的講解。

 圖1 滴滴出行租售前端負責人譙洪敏

組件與模塊設計理念

隨著web應用系統的復雜度不斷提升，需要兼顧開發效率和產品實際運行效率，而組件化和模塊化的價值又在于分治，所以會在開發階段運用組件化和模塊化的手段分離關注點，結合構建工具合理打包。

而組件與模塊另一個價值——粒度控制，需要在運行前進行粒度拆分，拆分后最細的粒度是UI， 而在架構上，CORE和Bridge JS、增量更新等也是不可忽略的一部分。

粒度控制

圖2 粒度控制架構圖

粒度控制在級別上又可拆分成UI級、BC業務組件級、Page頁面級、Module模塊級、項目級(UI之上是BC業務組件、BC組成Page、Page組成功能模塊、功能模塊組成業務模塊、業務模塊匯聚成一個系統。)。由于國內組件和解決方案太多，譙洪敏老師認為可以把有效的時間放到BC業務組件級和Page頁面級方面。

對于那些復雜、無規范性和大量依賴的架構來說，架構的治理也顯得必不可少，目前為止最好的方式就是同時集成SPA(single page web application，單頁Web應用)和MPA(多頁)的優點，整合出具有SPA的高效體驗，加上MPA的靈活性，避免大型SPA的內存管理困難及臃腫。按照微服務的理念，把混亂的服務依賴有條理的進行梳理，讓整個前后端的整理可維護性更強。另外在接入層就可以給前端暴露比較規范的API(Application Programming Interface,應用程序編程接口)，這樣前后端的結合才會更加順暢。

如果說架構是軟件搭建的骨架，那么代碼就是骨架上的血肉。架構的問題在于復雜、無規則，而代碼的問題在于不同需求同時開發的代碼合并該如何解決。在分支管理出現之前，代碼合并是編碼人員最頭疼的問題之一，在經過分支改造以后，這一難題迎刃而解，其中最好的模式，就是Git-flow，現在，在基礎上不斷的進化之后，Git-flow已經是業界最佳的實踐了。

基于Git-flow的分支管理

在Git-flow的分支模型中，有兩個主分支master和develop，還有幾個額外的分支來支持代碼的版本管理。下面先簡要介紹一下這些分支的特點。

1. master

·master分支只有一個，基于master上線，上線前打tag標識。

·master分支上的代碼總是穩定的，隨時可以發布出去。

·平時一般不在master分支上操作，當release分支和hotfix分支合并代碼到master分支上時，master上代碼才會更新。

·當倉庫創建時，master分支會自己創建。

2. develop

develop分支只有一個。

新特性的開發是基于develop分支的，但不直接在develop分支上開發業務需求，特性的開發是在feature分支上進行，develop分支永遠是融合最快且最不穩定的分支，這種不穩定會有很多好處，因為團隊成員在協作的過程中不斷的面對這種不穩定，也就可以及早發現問題。

當develop分支上的特性足夠多以至于可以進行新版本的發布時，可以基于develop分支創建release分支。

3. feature

可以同時存在多個feature分支，新需求特性的開發正是在此分支上面。

可以對每個新特性創建一個新的feature分支，當該特性開發完畢，將此feature分支合并到develop分支。

4. release

當完成了特性的開發，并且將feature分支上的內容融入到develop分支上，這時可以開始著手準備新版本的發布，release分支正是作為發布而開設的分支。

release分支是多個即將上線的feature分支融合而成，其生命周期較短，只是為了發布而使用。這意味著，在release分支上，只是進行較少代碼修改，比如bug的修復，原有功能的完善等。不允許在release分支增加較大的功能，因為這樣會導致release分支的不穩定，不利于發布的進行。

5. hotfix

當發現master分支出現一個需要緊急修復的bug，可以使用hotfix分支。hotfix分支基于master分支，是用來修復bug的，當完成bug的修復工作后，需要將其融回master分支，但其生命周期較短。

根據各分支的功能可以分成核心分支、功能分支、發布分支、維護分支。

核心分支

· master分支對應線上實際發布版本

·develop分支作為功能的集成分支

功能分支

·feature自己的分支從develop分支拉出

·功能完成后再合并進develop分支

發布分支

· release分支從develop分支切出但只做bug修復等工作

·發布準備做完后再合并進master分支并打上tag，同時合并進develop分支

維護分支

·hotfix分支從master分支切出做補丁修復

· 修復完成合并進master分支并打上tag，同時合并進develop分支

分支的使用可以將每個開發者從開發主線上分離開(即脫離主分支)，然后在不影響主線的同時繼續編程工作，但Git-flow的分支是”與眾不同”的，無論創建、切換和刪除分支，Git-flow在1秒鐘之內就能完成，大大提高了分支效率。但是隨著互聯網公司越來越關注數據的轉化、新增、留存，編程人員已經不滿足于解決分支管理的問題了，而是放眼到數據采集問題上，所以“埋點”又成為一項重中之重的任務。

埋點

所謂“埋點”就是在數據采集領域(尤其是用戶行為數據采集領域)，針對特定用戶行為或事件進行捕獲、處理和發送的相關技術及其實施過程。“埋點”基本可以分為三大類：手工埋點、可視化埋點和無埋點。

手工埋點(手動埋點)

手動埋點讓使用者可以方便地設置自定義屬性、自定義事件。所以當需要深入下鉆，并精細化自定義分析時，比較適合使用手動埋點。但是手工埋點也有缺點，當項目工程量大時，需要埋點的位置就會增加，而且需要產品開發運營之間相互反復溝通，容易出現手動差錯，如果出現錯誤，重新埋點的成本也很高。這會導致整個數據收集周期變的很長，收集成本變的很高，而且效率很低。因為手動埋點需要開發人員完成，所以每次有埋點更新，或者漏埋點，都需要重新進行上線發布流程，更新成本也高，對線上系統穩定性也有一定危害。

可視化埋點(框架式埋點、無痕埋點)

可視化埋點解決了純手動埋點的開發成本和更新成本問題，通過可視化工具快速配置采集節點(圈點)，在前端自動解析配置，并根據配置上傳埋點數據，比起手動埋點更無痕，配置數據可以設置過濾條件，避免針對所有元素(比如全埋點)，可以在調用開啟自動監控API時通過設置特征屬性來過濾不符合條件的元素，實現只針對某些元素進行自動上報數據的需求。

可視化埋點配置化能力相對手動埋點更強，是對手動埋點的補充而不是代替，很多手動埋點都可以通過好的規劃和架構變為可視化埋點。

無埋點(自動埋點、全埋點)

無埋點并不是沒有任何埋點，所謂“無”只是不需要工程師在業務代碼里面插入侵入式的代碼。只需要簡單的加載一段定義好的SDK(Software Development Kit，軟件開發工具包)代碼，技術門檻更低，使用與部署簡單，避免了需求變更、埋點錯誤導致的重新埋點。

通過這個SDK代碼，前端會自動全量采集全部事件并上報埋點數據，能夠呈現用戶行為的每一次點擊、每一次跳轉、每一次登錄等全量，并且可以實時監控用戶行為數據，在這些數據傳到后端后，可通過用戶分群、漏斗對比等功能，分析不同訪問來源、不同城市、不同廣告來源等多維度的不同轉化細節。

無埋點相比可視化埋點，在解決數據“回溯”問題上更有優勢。如果想分析某一天某個控件的點擊情況，在沒有針對這個按鈕做可視化埋點的情況下，只能從針對這個按鈕做可視化配置的這一時刻之后才有埋點數據，而無埋點，則從部署SDK那一刻就一直有數據在收集。

但無埋點也有劣勢，其自定義屬性不靈活，傳輸時效性差，數據可靠性欠佳，耗費網絡流量，還會增加服務器負載，而且兼容性也不佳。

雖然三種埋點類型各有利弊，但在實際請求中會根據業務混合使用多種埋點類型。

譙洪敏老師在會上介紹了前端技術的發展趨勢以及個人對于前端技術的實戰經驗。就前端主流技術框架的發展而言，過去的幾年里發展極快，在填補原有技術框架空白和不足的同時也漸漸趨于成熟。未來前端在已經趨向成熟的技術方向上將會慢慢穩定，并進入技術迭代優化階段。但這并不代表前端領域技術就此穩定，因為新的技術方向已經出現，并在等待著下一個風口的到來。

以上內容是51CTO記者根據滴滴譙洪敏在WOT2018全球軟件與運維技術峰會的演講內容整理，更多關于WOT的內容請關注51cto.com。