聲明：本文轉自搜狐網 原文地址：http://www.sohu.com/a/215395326_635110 編輯｜覃雲 嘉賓｜樑士興
伴隨着業務的飛速發展，美團點評的客戶端研發團隊的規模從初期的 20 餘人的發展爲數百人，且分散在不同的業務團隊。擁有如此大規模的研發團隊，他們是如何保證高效的內外部協同效率？美團與大衆點評原本是兩家獨立運營的大型互聯網公司，分別有着不同的積累和儲備。兩家的合併爲業務帶來巨大的好處的同時也爲技術團隊帶來了巨大的挑戰——如何能夠同時高效地在美團和大衆點評兩個 App 上實施業務開發？
在突破了這些難題之後，美團希望繼續提高自身的研發效率，經過系統性地分析，他們的解決方案是實施自動化測試。那麼他們是如何在大規模業務開發團隊中高效實施自動化測試，進一步提升研發效率和質量的？
本文就帶你揭曉美團點評技術團隊背後的故事，分享一些美團點評客戶端團隊的技術架構及其設計思路，幫助團隊技術負責人設計有利於提升研發效率的業務架構。以下全文來自美團技術研究員樑士興在 2017 北京 ArchSummit 全球架構師峯會上的演講內容。
爲什麼要建設客戶端架構？
客戶端架構與客戶端或 APP 的發展經歷是相關的。早些年 APP 通常是由個人開發者或者小團隊來實施，那時候它往往是作爲一個業務創新或某一個實踐去做的。
APP 從小型變成了巨無霸，代碼動輒上百萬行，美團移動支付的佔比也早就超過 90%，開發團隊也從小變大，美團點評現已有數百人專門從事 APP 開發。迭代週期主要和業務的重要性相關，如果是核心的業務載體，迭代週期就需要做得越來越頻繁、越來越迅速。
美團點評使客戶端架構統一是希望得到這方面的收益，通過標準化，就可以實現三個統一：統一的基礎設施、統一的邏輯分層、統一的開發範式。然後會帶來四個明確的好處：
讓一線開發人員聚焦在業務開發上；
可以實施靈活的人力調配；
可以用標準化的方式介入一個新的業務以支持其快速啓動；，
一旦實現了標準化，必然可以基於它做一些自動化的實現，可以把一些相對機械重複的事通過自動化去取代人工。
最終帶來的好處是：可以更好地服務業務。
美團客戶端的演變歷程
上圖是針對美團客戶端整理的技術研發體系。縱向是按時間和階段劃分的，橫向按業務邏輯、開發範式、技術棧整理出來的。從技術體系圖來看，進行業務開發的技術挑戰其實是蠻大的，需要了解數據採集、監控、質量保證等方方面面。設計業務架構的目的是讓業務研發人員把精力集中在業務開發上。
美團客戶端架構發展分爲三個階段：
蠻荒階段：這個階段並沒有什麼體系化的架構設計；
標準化的階段：內部細分了三個小階段，實現了業務隔離、基礎設施複用、開發範式等。
自動化是正在建設中的階段，希望通過使用工程自動化的手段去持續提升效率。
蠻荒階段
蠻荒階段也就是最初的 APP 形態，衆所周知，美團是做團購起家的，萬物都是團購，在這個階段美團並沒有針對性地設計任何架構相關的東西。但是團購有一個好處就是可以以很低的成本把業務觸達到各個領域，在這個階段中，美團實現了業務遍地開花，很輕鬆地觸達到不同的品類，比如酒店、電影等。於此同時，美團也讓移動 APP 成爲了核心業務載體，移動支付的佔比超過了 90%。
面臨的挑戰
那這個階段能繼續下去嗎？挑戰很快就接踵而至。挑戰主要來源於兩個方面：業務差異化和業務間的協同效率，從業務層面上來講，雖然美團實現了業務的遍地開花，用團購方式觸達到各個業務領域，但還不足以把業務做深。例如：團購這種形式並不適用於所有的領域，如酒店一定要預定，它和美食的團購行爲是不一樣的，這個時候要有訴求地去深耕業務，把不同業務特點的東西做出來，就是所謂的垂直化。因爲業務這邊已經有了不錯的發展，換句話說就是賺到錢了，所以團隊的規模在極速擴張，同時美團的研發團隊被拆分到各個業務去，這也是爲了更好地服務業務。
標準化階段
第一階段，美團主要通過分層和隔離的方式來解決問題，首先把跟各個業務都無關的和與各個業務都相關的公共基礎設施定義爲平臺的基礎設施。我們把一個平臺做強，同時在這個平臺的基礎之上去構建各個業務，而且在業務裏面進行有特色的垂直化建設，這個階段會帶來很明顯的收益。
通過這樣的平臺設施，在一定程度上實現了複用和業務的積累，解決了業務之間的耦合，各個業務在物理上會隔離開，放到不同的代碼倉庫裏面，只是在構建的時候把他們集成在一起，這種模式還有一個好處，就是爲新業務的接入保持開放，任何一個新業務都可以按照規範輕鬆地接進來。
具體步驟
如果想要達成這樣的目的，首先應該開發一套標準的業務模板，所有的新業務都按照這個模板去開發，根據模板的內容去進行業務的定製，並且通過統一的方法來實現接入，誰做比較合適？顯然是新業務，讓新業務去做小白鼠，在這個階段裏，短期內是可以接受代碼拷貝的，通過解耦拷一份代碼，將其分到一個獨立的倉庫裏。爲什麼說短期可以接受這種行爲？客戶端有一個特點，哪怕不動彈，過一段時間頁面也會被產品改得面目全非。
在這個過程中美團的收益是什麼？總結起來有三點：
首先是在業務層面實現了業務間的隔離，解除了業務間的干擾，再也不會看到改電影模塊導致酒店模塊出現故障的現象，也不會把外賣的東西展示到美食區；
在工程層面上實現了工程標準化，使得新業務接入的方式是標準化的；
在技術層面上實現了獨立的編譯和二進制的集成，一旦實現了業務間的獨立編譯，就可以利用分佈式的系統進行多機構建，這樣就可以極大地縮短應用的構建時間。
但樑士興認爲這個階段並不完美，還有很大的改進空間。因爲一線開發者的研發效率並沒有因爲這次重構得到任何提高，這是爲什麼呢？因爲開發層面沒有標準化，代碼複用是非常困難的一件事，所以需要實現開發範式，通過定製開發範式，將開發過程統一化，開發產物也是標準化的，可以被更好地複用起來。
統一開發範式
從上圖來看，茴字有五種寫法，而 USB 接口的實現方式更多。也就是說客戶端開發的實現方式有很多種，這就使得複用變得非常困難，因爲大家做事的方式都不一樣，業務模塊接口也是不統一的，想用統一的方式把所有模塊調度起來就會非常困難。
這個問題讓開發範式的目標明確了起來，開發範式實現的是書同文、車同軌，即開發方式統一化，業務接口標準化。
在這裏以一個實際頁面爲例，這是一個複雜的頁面，這個頁面天然地劃分成若干塊，從這幾個角度上來講，頁面本身並不存在什麼東西，所有東西都被放到模塊裏，經過這樣的抽象，我們把頁面上的每一塊定義爲一個模塊，同時頁面會退化成模塊容器的概念。
進一步來說，模塊之間通常存在着通信的需要，這種通訊包括 UI 上的聯動、數據的共享等，模塊之間如果需要強依賴去獲取數據，則模塊之間也存在着依賴，這個是不能接受的，我們設計的目標是希望能實現模塊級別的複用。
爲此，樑士興說他們團隊引入了一個消息總線的概念，可以允許模塊在上面訂閱或發佈消息，通過這種方式也能實現模塊之間的耦合。他們還進一步對模塊的內部也進行了約束，要求模塊統一，按照這樣的方式去組織，能夠更好地實現自動化測試。經過這樣的設計，美團主要頁面的實現方式得到了統一，最直接的好處就是模塊可以跨業務複用了。
按樑士興的說法，他們在設計統一開發範式的時候就設定了目標，他們希望對高級工程師的依賴能夠降低，以及開發效率能夠得到提升，提升的邏輯在於代碼可以複用。對此他給出了以下案例：將 2014 年 7 月、2016 年 12 月以及 2017 年夏天開發獨立 APP 時做的需求進行對比，前兩者比較，發現 2016 年效率提升了 33%，而 2017 年獨立 APP 只用了 2 倍的人力實現了 8 倍工作量，效率提升了 400%，這種提升是非常值得開發人員自豪的。同時他們團隊參與這些項目的高級工程師的比例也在持續降低，到最後做獨立 APP 時，一個高工帶着一羣小弟就能把事情搞定了。
想實現統一開發範式也會存在一些困難，這裏的困難和上文是一樣的，主要有兩點，第一，整體重構一遍成本極高，第二，業務永遠不會等着技術，所以開發的同時要進行重構。他們只對新需求涉及的頁面進行重構，客戶端的代碼總是很快地迭代到，藉着產品迭代這樣的時機把對應的架構重構做完。
做到這個程度，樑士興認爲他們已經進入了相對理想的狀態，但有些事情是不受他們控制的。由於公司戰略的原因，美團和點評進行了合併，衆所周知，這兩家公司一直以來是獨立運營的，各自都有不一樣的積累，合併會帶來大量的不統一：兩邊的 APP 技術棧不統一，後端服務不統一，交互樣式也不統一。對產品經理來說相當於多了一個 APP，再加上大量的基礎設施不統一，想把某功能整體從美團遷移到點評，這幾乎比登天還難。但是技術人員就是解決問題的，所以針對這三個不統一，他們做了兩層抽象。
首先，針對基礎服務層的差異，他們做了一層抽象接口，這個接口不做具體功能的實現，它的具體實現是由兩個平臺真正的基礎設施來實施的。第二個方案是針對差異進行了設計，在一套代碼倉庫裏利用構建過程，把一些差異化的地方讓它產生不同的構建產物。
通過這樣的方式，可以在 APP 裏寫不一樣的代碼，同時去支持美團和點評兩個 APP 的業務開發，這套方案其實是一個通用的方案，它並不僅限於對這兩個 APP 的支持。美團在開發獨立 APP 的時候，也是直接利用這樣一套模式，就把美團的東西複用到美團獨立的 APP 中，在三端之間實現了代碼複用，而且這套模式本身對自動化測試也是極好的，可以直接利用二進制構建的結果接入到自動化測試的工程，這樣自動化測試的構建效率是非常高的。
解決了多應用複用的問題，帶來的收益更加明顯。統一架構優化之後遷移成本整體控制在 30% 以下，其實平均是低於 20% 的，在這個階段下，美團多應用同時支持需求迭代的情況就變得可行了，而且是一個常態化的過程，代碼複用率也從一開始不復用，到後面整體複用率在 95% 以上。
自動化階段
經過了這樣幾輪架構方面的迭代，還有沒有辦法進一步提升研發效率呢？在這裏，美團用了一個方法論：既然已經實現了標準化，是否可以進行自動化了呢？因爲有了自動化的工具做保障，反過來可以促成標準化的達成，殺掉非標準化的行爲。
那我們應該針對什麼事情做自動化？樑士興表示，根據一個迭代週期的各個環節的實際人力投入，可以發現測試的成本很高，測試和開發的時間比例是 4：5，同時把測試和開發的若干個環節再去做拆解，會發現測試裏面有一個很可怕的東西叫做迴歸測試，佔的比重非常大，而且迴歸測試還有一個特點：迴歸測試的規模只與 APP 的規模有關，並不與迭代的新功能有關，這也是一件很可怕的事情。某個版本做了很小的需求想快速上線，同時還要爲了保證線上的質量進行完整的迴歸，迴歸的規模並不因爲需求小而變小，應該優化迴歸測試的過程，從這個角度上來說，自動化測試就是解決迴歸測試最有效的手段。
從開發階段上來講，美團在這幾個環節中的投入基本相當，他們希望通過代碼腳手架的方式減少開發階段的成本，如涉及網絡的開發與後端進行 API 聯調的工作，如果使用聯合腳手架的話就會變得非常輕鬆。
如何進行自動化測試？
在自動化測試上，美團的思路是從業務特點出發，對美團的業務形態進行了分析，他們發現幾乎所有業務線都可以落到一個套路中來：首先業務有它的入口，通過入口可以進入到業務線的主流程，如列表、詳情、購買、售後等。配合主流程的各個環節會有大量的信息增值服務，比如攻略、地圖、相冊等增值服務。
通過這樣的業務流程對各個頁面進行分析，可以得到一個結論：現在只有兩種類型的頁面，信息展示頁面和交互邏輯型頁面，前者佔比超過了 80%，如果對這類頁面進行測試，只關注它的展示行爲，會發現它並沒有很複雜的邏輯；後者的情況正好相反，它的佔比很少，但是它的交互邏輯會變得非常複雜，同時它內部的各種細節都會對質量有至關重要的影響，對它的測試要做得比較重，而且它的測試更多關注的是程序邏輯的實現。
然後再針對這些頁面去做測試技術的選型，上圖中的三角是通用的模型，涉及測試的各個場景，中間是分界線，分成黑盒和白盒兩種方式，美團選擇了靠近分界線的這一塊，從 UI 自動化測試和集成測試裏選取一個子集，一個子集是 UI 的截屏測試，應用在信息展示型頁面，一個子集是面向 UI 接口應用於交互邏輯型頁面。
首先是 UI 截屏測試方案，一份截屏測試需要參考圖、實際效果圖、Diff 分析，還包括後端返回的數據，即數據樁，還有模擬登錄層出、設置時間等，同時需要把上下文的所有信息都設置成可控的，展示結果也是可控的。
面向 UI 接口的集成測試模擬了視圖該有的結果，可以供開發者執行測試，套用到三部曲裏，第一步，設置上下文環境，設置測試數據；第二步模擬用戶操作，就是用測試用例調用 VM 上的命令；第三步校驗結果，即監測 VM 上的數據狀態。有些測試用例數據一直在端上，我們要把最終發起的請求攔截住，在請求那一層檢查，比如選擇了下單信息，最終去發出請求看這些是否正確。
自動化測試的挑戰
實施自動化測試也有很大的挑戰，主要有兩點：一是實施測試的成本，二是自動化測試的執行效率。成本方面主要體現在開發測試用例的人力投入和測試用例本身失效帶來的額外成本（也可以說是維護的成本）。
在執行效率方面，前面介紹過通過複用二進制構建方式，把構建 + 執行時間從 30 分鐘優化到 6 分鐘，然後另一個是執行成功率，因爲有 15% 的概率會失敗，所以需要引入重試的機制，把失敗率降低到 5% 以下。
自動化測試的收益
自動化測試帶來的收益，首先最明顯是線上質量的提升。另一個是對研發效率有很大的提升，這主要體現在對迭代頻率的影響，因爲一旦對應的模塊實施了自動化測試，就只需要抽查 2% 的測試用例。
未來之路
對於未來，樑士興表示他們希望把前面測試用例通過平臺化的方式統一管理起來，同時會在這些場景裏面對日常開發有很大的效率提升。另一個是代碼腳手架，從上文迭代週期可以看到這塊也是值得去做的。