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

· 團隊成員越來越多

· 跨團隊協(xié)作越來越多

· 業(yè)務(wù)系統(tǒng)越來越復(fù)雜

· 框架越來越多

· 性能要求越來越高

· 可維護性越來越差

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

 圖1 滴滴出行租售前端負責(zé)人譙洪敏

組件與模塊設(shè)計理念

隨著web應(yīng)用系統(tǒng)的復(fù)雜度不斷提升，需要兼顧開發(fā)效率和產(chǎn)品實際運行效率，而組件化和模塊化的價值又在于分治，所以會在開發(fā)階段運用組件化和模塊化的手段分離關(guān)注點，結(jié)合構(gòu)建工具合理打包。

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

粒度控制

圖2 粒度控制架構(gòu)圖

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

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

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

基于Git-flow的分支管理

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

1. master

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

·master分支上的代碼總是穩(wěn)定的，隨時可以發(fā)布出去。

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

·當倉庫創(chuàng)建時，master分支會自己創(chuàng)建。

2. develop

develop分支只有一個。

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

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

3. feature

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

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

4. release

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

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

5. hotfix

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

根據(jù)各分支的功能可以分成核心分支、功能分支、發(fā)布分支、維護分支。

核心分支

· master分支對應(yīng)線上實際發(fā)布版本

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

功能分支

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

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

發(fā)布分支

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

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

維護分支

·hotfix分支從master分支切出做補丁修復(fù)

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

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

埋點

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

手工埋點(手動埋點)

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

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

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

可視化埋點配置化能力相對手動埋點更強，是對手動埋點的補充而不是代替，很多手動埋點都可以通過好的規(guī)劃和架構(gòu)變?yōu)榭梢暬顸c。

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

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

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

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

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

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

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

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