微信支付大規模前端開發背後，如何用外包解決困境

目前我們基於外包已經做出了20多個系統，這些系統粗略估計有超過200個模組。我們組建了20多人的前端外包團隊，將20多個內部的後臺開發培養成了前端SE，負責和外包配合。同時建立了40多個文件、5個視訊教程和和5個招聘流程，由2個全職前端持續跟進。

在2015年下半年，我們把整個專案丟給外包去做。結果一個相對比較簡單的小系統，整整做了兩個多月，而且我們負責指導外包的同事也非常累。

因為是遠端溝通，所以合作溝通成本高。

很多該配套的文件不完善，導致很多時間浪費在了溝通、瞭解需求上。

外包研發水平相對較低，和騰訊內部培養出的專業人員還是有差距。

建設引入外包團隊的前端系統研發模式，提升組織研發效能。

微支付的需求發起方可能是資料、運營等各種部門，於是我們打造了“XPHP”前端外包協同研發平臺，在上面提供各種各樣的工具、框架給外包使用。

這種模式就是需求發起方提出需求後，由業務團隊研發SE來接需求，然後交付給外包團隊，讓外包最終實現出高質量的系統工具。

整個微信支付90%以上的研發都是後臺，我們培訓這些後臺出身的同學，讓他們瞭解前端。由這些同學負責制定每一個系統實施的技術方案，整理微服務文件，指導外包團隊工作，最後配合需求發起方驗收工作成果。

1、抽象“契約式”開發模式，提升溝通合作效率。

我們把表現層前端協議配置模組拆分給外包團隊來實施，後臺業務邏輯層由我們自己維護。

為了讓外包更高效地進行研發，我們做了一個系統，可以在這個系統上建立需求，再進行協議配置，將協議用到每個欄位。配置完協議後，系統提供能力就可以填一些假資料，呼叫系統就可以返回假資料。讓外包團隊可以直接基於這份協議進行開發。

我們規定前端儘量不要有業務邏輯，只通過資料驅動進行展示。儘可能讓外包少懂點業務邏輯，以減少溝通。

有一種程式設計思想叫做“契約式”程式設計。“契約式”有幾個關鍵的概念，例如先驗條件、不變式、後置條件之類的。

我們的“契約式”開發模式還只是一個雛形，現在只是配置一個欄位、配置一些格式，前端以“契約”精神進行開發。

2、抽象前端請求生命週期，填空完成業務邏輯開發。

我們對整個MIS系統了業務邏輯層做了抽象，把整個業務邏輯層的生命週期抽象出來。

比如一個前端請求過來，會統一經過安全過濾器做過濾，再通過一個業務鑑權過濾器進行鑑權。然後到了契約檢查器，可以檢查配給前端的契約引數是否按照契約規定進行傳輸，以及一些回包也可以通過契約檢查器進行判斷，保證回包是按照當時契約制定的格式進行回包。

資料層是微信支付內部各個業務團隊自己用C++所做的那些底層微服務。MIS系統只是呼叫底層的介面去改一些資料、配置。所以我們也統一封裝了一個RPC請求器去呼叫各種各樣不同協議的底層微服務。

最終我們挖出了兩個“空”：在呼叫底層服務的時候需要傳什麼引數給它，當它返回的時候需要做什麼加工來保證最終要返回給當時和前端制定的契約。

開發人員只需要“填空”。根據前端傳過來的引數做一點加工，把它傳給底層的服務，。返回的時候再做些加工然後返回給前端

整個生命週期其它的程式碼全都由系統自動生成，這就形成了“填空式”研發。這種研發的好處就是一方面寫的東西非常少，另一方面只要保證自動化生成的這份程式碼質量夠高，它基於這個生成的最終程式碼質量就可以得到保障。

在這個系統裡可以配置依賴底層的哪幾個介面。

3、給低水平的研發賦能，提升前端研發質量

由於外包團隊經驗不足，我們希望能多提供一些工具給他們賦能。

我們提供了一個UI元件庫，讓他們在這個元件庫裡拼頁面。有了官方提供的UI元件庫，他們後續可以直接拿高質量的react元件庫進行開發，提升了外包團隊的效率和質量。

CRR研發框架就是一個簡易版的react+redux，目前正在開發中。我們計劃把它封裝成一個提供給外包團隊看的介面，研發方式就像在研發小程式一樣簡單，但是最終編譯出的程式碼就是react+redux的方式。

構建工具就是XPP研發系統裡把以前慣用的構建方法內容全部整合進去，外包基於這一整套東西做構建編譯。這樣頁面和前端研發的規範都能在裡面得到保障。

給外包開發賦能的思想基本圍繞這個思路來做。

4、提供更簡單的研發檢視，降低研發門檻

通過CRR編譯器，把CR程式碼轉換成虛擬語法樹的結構，在裡面注入redux產生的額外程式碼，寫的時候就像寫小程式一樣，只需要在幾個檔案裡進行編譯。

小結：兼顧效率和質量，給研發人員賦能

我們做了協議配置&Mock來解決表現層高效外包開發。從效率上基於協議Mock開發頁面渲染邏輯，從質量上基於協議配置做引數欄位強校驗。

業務整合用來解決業務邏輯層程式碼高效開發。填空式業務邏輯開發，寫的東西越少效率越高。自動化生成高質量、強校驗的程式碼。

UI元件庫+CRR框架可以解決外包開發的效率和質量。React的UI元件本身的效能優化由我們內部人員保障，讓外包可以基於整套充分效能優化過的UI元件去研發，他們就可以交付出更高質量的程式碼。

大規模外包團隊正面臨一些嚴峻的考驗，例如沒有測試人員、溝通成本高、開發流動性高、系統繁多。

為了在生產自動化測試用例這一塊能更好地提升效能，去年年底我提出了一個無痛前端自動化測試的概念，我給它取名為PFAT。

PFAT的靈感來自於react+redux單向資料流的思路。好處是我們只需要運算元據、改變狀態。

React本身有一箇中介軟體機制，PFAT用這個中介軟體來擷取所有的狀態變化、事件，然後把它錄下來。這就是PFAT感知頁面狀態的方法。

關於前端非同步請求的用例錄製問題，常見的解決方案是業務自己將非同步動作拆分為多個對應的同步動作。例如一個SEND_REQUEST可以拆分為START_REQUEST、REQUEST_SUCC、REQUEST_FAIL這三個Action。

這種方案的缺點是每個業務需要開發自己去拆分，不方便統一管理。

XPHP的解決方案是基於XPHP標準化協議管理的優勢，封裝通用非同步請求中介軟體將非同步動作拆分為多個對應的同步動作。業務標準化使用，不用自己拆分。

把PFAT做成瀏覽器外掛，顯示、隱藏靈活，不干擾正常體驗和驗收工作，後臺錄製操作過程並可以直接儲存。就能將PFAT無痛嵌入正常的研發流程中。

Jest的方式比較傳統，要額外寫程式碼；PFAT可以一鍵錄製需要的用例，更方便。PFAT比Jest更加無痛。

PFAT對於測試驗收效率提升的重大意義就是擁有了回放BUC的能力。

傳統方式反饋BUG只有一個截圖，開發除錯效率非常低。而PFAT可以把案發現場每一部操作的資料、動作全都一鍵儲存下來，供開發回放除錯，大大提升開發定位問題修復BUG的效率。

PFAT適用於一切react+redux專案。

小結：

1、規範研發模式：定義“基於狀態機扭轉”的前端研發模式CRR。

2、高效用例錄製：高效單元測試用例錄製工具PFAT。

3、自動用例迴歸：日常自動化迴歸、版本變更迴歸。

4、變更及時觸達：變更關聯發現機制、用例失敗告警機制。

“PFAT無痛前端自動化測試方案”設計思想：

1、認清本質。“ROI第一”原則，不盲目追求100%覆蓋度。

2、最小化感知。“無侵染”原則，不改變研發流程、不額外寫用例、不額外匯入資料；“保證效率”原則，工具化錄製、自動化迴歸、用例管理能力、告警能力。

3、借力打力。“跟開源社群接軌”原則，模擬瀏覽器環境、自動迴歸、Diff展示。

外包模式：持續培訓、持續平臺建設。

系統維護：持續推進標準化建設，持續加強系統管理分析能力。

我們要善於借力和賦能，用有限的人做更多的事。解放勞動力，做更有價值的事，獲得更快速的成長。

今天的分享就到這裡，謝謝大家！