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

內容來源：2017年6月24日，騰訊前端高級工程師郭潤增在「騰訊Web前端大會 TFC 2017」進行《微信支付大規模前端外包實戰》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3543 | 9分鐘閱讀

嘉賓演講視頻及PPT回顧： t.cn/RntiHx4

摘要

業務高速發展離不開各類配套運營系統的高效建設，微信支付也不例外。在前端人力極其匱乏的條件下咱們另闢蹊徑，大規模引入外包團隊協同做業，而且在如何保證效率和質量，控制版本變動風險，保證可持續性等方面作了很多研究實踐，藉此機會跟你們分享交流。

爲何要引入外包

相關數據

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

第一次慘痛的失敗

在2015年下半年，咱們把整個項目丟給外包去作。結果一個相對比較簡單的小系統，整整作了兩個多月，並且咱們負責指導外包的同事也很是累。

失敗的客觀緣由

由於是遠程溝通，因此合做溝通成本高。

不少該配套的文檔不完善，致使不少時間浪費在了溝通、瞭解需求上。

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

願景

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

微支付的需求發起方多是數據、運營等各類部門，因而咱們打造了「XPHP」前端外包協同研發平臺，在上面提供各類各樣的工具、框架給外包使用。

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

定義關鍵角色SE

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

引入外包的三大挑戰

如何解決外包效率和質量問題

一、抽象「契約式」開發模式，提高溝通合做效率。

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

爲了讓外包更高效地進行研發，咱們作了一個系統，能夠在這個系統上建立需求，再進行協議配置，將協議用到每一個字段。配置完協議後，系統提供能力就能夠填一些假數據，調用系統就能夠返回假數據。讓外包團隊能夠直接基於這份協議進行開發。

咱們規定前端儘可能不要有業務邏輯，只經過數據驅動進行展現。儘量讓外包少懂點業務邏輯，以減小溝通。

有一種編程思想叫作「契約式」編程。「契約式」有幾個關鍵的概念，例如先驗條件、不變式、後置條件之類的。

咱們的「契約式」開發模式還只是一個雛形，如今只是配置一個字段、配置一些格式，前端以「契約」精神進行開發。

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

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

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

數據層是微信支付內部各個業務團隊本身用C++所作的那些底層微服務。MIS系統只是調用底層的接口去改一些數據、配置。因此咱們也統一封裝了一個RPC請求器去調用各類各樣不一樣協議的底層微服務。

最終咱們挖出了兩個「空」：在調用底層服務的時候須要傳什麼參數給它，當它返回的時候須要作什麼加工來保證最終要返回給當時和前端制定的契約。

開發人員只須要「填空」。根據前端傳過來的參數作一點加工，把它傳給底層的服務，。返回的時候再作些加工而後返回給前端

整個生命週期其它的代碼全都由系統自動生成，這就造成了「填空式」研發。這種研發的好處就是一方面寫的東西很是少，另外一方面只要保證自動化生成的這份代碼質量夠高，它基於這個生成的最終代碼質量就能夠獲得保障。

在這個系統裏能夠配置依賴底層的哪幾個接口。

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

因爲外包團隊經驗不足，咱們但願能多提供一些工具給他們賦能。

咱們提供了一個UI組件庫，讓他們在這個組件庫裏拼頁面。有了官方提供的UI組件庫，他們後續能夠直接拿高質量的react組件庫進行開發，提高了外包團隊的效率和質量。

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

構建工具就是XPP研發系統裏把之前慣用的構建方法內容所有集成進去，外包基於這一整套東西作構建編譯。這樣頁面和前端研發的規範都能在裏面獲得保障。

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

四、提供更簡單的研發視圖，下降研發門檻

經過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項目。

小結：

一、規範研發模式：定義「基於狀態機扭轉」的前端研發模式CRR。

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

三、自動用例迴歸：平常自動化迴歸、版本變動迴歸。

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

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

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

二、最小化感知。「無侵染」原則，不改變研發流程、不額外寫用例、不額外導入數據；「保證效率」原則，工具化錄製、自動化迴歸、用例管理能力、告警能力。

三、借力打力。「跟開源社區接軌」原則，模擬瀏覽器環境、自動迴歸、Diff展現。

如何解決可持續問題

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

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

總結

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

今天的分享就到這裏，謝謝你們！