在技術團隊，質量的話題相信大家都不陌生。以有贊的業(yè)務為例，質量問題無論是發(fā)生在業(yè)務上的交易鏈路還是在引流鏈路上，亦或是啟動時的閃退或 loading 時間過長的性能問題，都會造成我們所服務的商家經營上的低效和 GMV 的流失，導致商家對有贊的技術能力產生質疑和抱怨，最終影響到有贊SaaS服務的續(xù)費率。

但事實上，質量不佳不僅會影響到業(yè)務和商家，對于技術團隊自身的影響也不容小覷。

有贊移動團隊也曾經歷過從0到1快速迭代功能上線而對代碼質量重視不足的階段，這些挖下的坑在業(yè)務快速拓展的過程中帶來了大量的線上問題和故障。線上問題的頻發(fā)會讓整個團隊陷入一種效率上的惡性循環(huán)：應對線上問題會打斷進行中的項目進度，嚴重的時候很多開發(fā)同學甚至不得不整個白天都在忙于處理線上問題，到了晚上才有空開始補今天的開發(fā)進度。這種情況下不僅會產生加班、延期等顯性的影響，更嚴重的是技術方案考慮不周、Code Review不細致等隱性影響，會進一步降低線上代碼的質量。這樣的惡性循環(huán)也會讓整個團隊忙于救火，技術沉淀和氛圍更加無從談起。

質量不佳對于技術團隊會形成惡性循環(huán)

因此我們深刻的感受到，對于一個技術團隊而言，質量和穩(wěn)定性其實是團隊的地基。在好的質量基礎上，我們才能更好去追求業(yè)務上的支撐與推動、研發(fā)效能提升、團隊技術氛圍等其他目標。

不同類型的業(yè)務場景中，對于移動端的要求也會有不同的側重點。有些金融背景的業(yè)務會對于 app 的安全性要求更高，而另一些電商背景的業(yè)務可能對于動態(tài)能力要求更高，而技術團隊在質量上努力的方向和側重點都與業(yè)務特點密切相關。

那么有贊的業(yè)務場景中對移動端有哪些要求呢？我們歸納成以下兩個突出的特點：

• 離線的業(yè)務能力

• 受限的硬件水平。

1、離線的業(yè)務能力

對于市面上的大部分app，當用戶在移動 app 上操作下單的過程中，移動端通常只會負責信息的展示和用戶的交互。而訂單金額的營銷計算（比如某個商品是否可以用優(yōu)惠券減錢、某個商品是否在訂單中符合成為贈品的條件）、數據的校驗、訂單的生成這些敏感的業(yè)務邏輯都會放在后端進行處理。

但是在有贊的門店業(yè)務場景中，我們?yōu)殚T店收銀員開發(fā)的收銀終端 HD 應用需要提供離線開單的能力。

這是因為門店場景中面對的是來店的顧客和真實排在收銀臺前的待付款消費者。這種場景要求收銀系統(tǒng)在面臨斷網或者服務端宕機的挑戰(zhàn)時，需要具有本地收銀的能力。如果來店的消費者因為收銀系統(tǒng)卡住而離店，那么商家就會蒙受巨大的損失。

門店場景中供門店收銀的HD應用

本地去做營銷計算和訂單生成的要求不僅對于移動端本地數據緩存能力、數據變更及時性、邏輯復雜度、數據安全性提出了更高要求，在質量保障上還帶來了兩點挑戰(zhàn)：

• 營銷計算中的資損風險

• 問題的及時修復能力

營銷計算中的資損風險：如果移動端在創(chuàng)建訂單過程中只負責信息展示和用戶點擊操作時，移動端由于自身 bug 導致資損風險的概率是極低的。但是當商品的折扣計算、優(yōu)惠分攤、組包拆包、優(yōu)惠疊加互斥邏輯都落在移動端本地時，編碼 bug 導致訂單金額計算錯誤，進而導致商家或者消費者資損的概率就會直線上升。比如一個商品并不在商家的限時折扣活動范圍中，但是由于bug導致給這個商品也打了折扣賣了出去，就會給商家?guī)碣Y損。而資損故障是非常嚴重的。這就要求我們必須有更嚴格的機制去確保核心代碼的L0級穩(wěn)定性。

問題的及時修復能力：當線上問題可能涉及資損時，也進而會對移動端的問題修復能力提出更高的要求。

就問題修復及時性而言，移動端相對于前后端有著天然的劣勢。后端或者前端同學發(fā)現線上問題時，可以通過回滾做到幾分鐘內止血。但移動端不可能讓每個終端卸載重裝老版本，同時市面上的熱修手段也存在諸多限制。這讓我們不得不對于問題修復流程中的每個環(huán)節(jié)做更深入的思考與探索，盡可能在問題發(fā)生時能夠快速止血，降低影響面。

2、受限的硬件水平

在門店場景中，我們?yōu)殚T店收銀員提供的HD應用安卓端是運行在收銀機上的。對于收銀機的硬件能力，我們可以通過一個簡單的對比感受一下：

• 商米 T2 收銀機，也是我們目前客戶中使用率較高的一款設備，內存2G，某電商平臺上售價3000多元

• 紅米 Note9 手機，安卓千元機，內存6G，某電商平臺售價999

  
  

我們拋去 CPU 能力等其他因素，但看內存這一項就存在著巨大的差距。有限的內存能力，要求我們移動技術同學不僅在編碼和技術方案設計階段在性能上有更細致的考量和設計，也要求我們對于線上的 app 性能卡頓問題有更強的分析能力和解決能力。

結合前文提到的有贊業(yè)務場景的要求，我們著重圍繞以下幾個命題，思考和探索如何提升移動質量：

• 如何深度防范資損故障，讓資損的風險盡可能清零？

• 如何體系性的提升移動端質量，讓線上問題數量保持在較低的水平？

• 如何搭建完善的性能監(jiān)控體系，全面提升app性能，降低卡頓的發(fā)生？

我們將探索中的心得歸納為以下幾點：

• 主動發(fā)現問題

• 更早發(fā)現問題

• 有效的流程機制支撐

• 重視性能

1、主動發(fā)現問題

在我們曾經出現過的一例線上資損故障中，由于場景實際觸發(fā)頻率較低，導致測試過程中被遺漏了。這個bug是6月6日發(fā)布上線的，但是直到7月10日有一個商家上報了一例我們才發(fā)現了這個涉及資損的問題。這件事情引發(fā)了我們的反思，對于核心業(yè)務鏈路上的異常行為，難道我們發(fā)現問題的途徑只能依賴用戶上報嗎？

天網數據報警平臺

事實上，主動去發(fā)現和修復問題對于移動端同學并不陌生。一個移動團隊即使是在建立初期也會通過一些三方平臺，對自己每個上線的版本進行 crash 的監(jiān)控和分析。crash 平臺就是主動發(fā)現和解決問題的表現。那么業(yè)務流程中的問題，我們是否也能做到主動上報、主動發(fā)現、主動修復處理呢？答案一定是可以的。

因此我們搭建了天網報警平臺，目標就是對于核心業(yè)務鏈路上的異常情況，可以達到 crash 上報、分析、跟蹤的同樣效果。一套 crash 分析平臺通常具備以下能力：問題上報、數據聚合、任務分配、版本過濾、上下文信息等，我們的天網平臺也提供了相同的完整能力：

• 數據上報：通過業(yè)務核心環(huán)節(jié)的主動埋點，對異常進行主動上報，根據問題不同分級支持設置不同的上報優(yōu)先級策略

• 數據聚合：相同的問題通過后臺進行聚合，提供問題列表并支持各種條件篩選

• 任務分配：問題可以分配給責任人跟進

• 消息報警：當問題符合報警策略，自動關聯(lián)到企微報警，并直接at對應業(yè)務域的負責人，第一時間介入處理

• 版本過濾：問題修復后支持設置已修復版本，后續(xù)上報問題如果小于等于已修復版本則不再報警，如果大于已修復版本則代表問題再次發(fā)生，會再次報警需要跟進

• 周報日報：周期性匯總線上報警問題數量和狀態(tài)，提醒責任人及時處理

搭建了完整的平臺能力之后，我們也深知整套系統(tǒng)的有效運轉其實是深度依賴于業(yè)務同學在業(yè)務流程的關鍵環(huán)節(jié)中的主動分析和埋點，豐富的業(yè)務埋點才能讓這套系統(tǒng)真正在業(yè)務主動防控中發(fā)揮效果，因此我們還匯總了適合業(yè)務主動埋點的最佳實踐：

• 數據校驗：對于端上通過輸入或者計算產生的數據，可以通過交叉校驗分析異常；

• 關鍵內容缺失：各環(huán)節(jié)在收口階段均可以校驗自己獲取的參數完整性，如果有關鍵內容缺失可以主動上報；

• 系統(tǒng)異常：無論是 iOS 系統(tǒng) API 返回了 error，還是 Android 系統(tǒng)中 try/catch 的異常，都代表本地系統(tǒng)調用出現了預期外的行為，可以主動上報

以下是一個天網報警的例子，在收銀員操作一筆訂單的過程中，移動端上報后端的開單參數中會包含以下信息：

• 商品信息（如一聽可樂，售價3元）

• 營銷信息（限時折扣7折，或者會員價2.5元）

• 支付信息（最終通過會員價2.5元結算，通過現金進行支付）

• 會員信息（用戶登錄的會員、在該筆訂單中所使用的是哪張會員卡等）

  
  

我們曾經出現過的一個bug是在大型項目改造的過程中，在調用后端API傳參時沒有傳選中的會員卡號。這個場景下，當這張會員卡有發(fā)放多倍積分的設置時，就會導致該筆訂單最終發(fā)放的積分錯誤。這種場景下，我們增加對參數的主動校驗：當開單參數中的營銷信息中存在會員卡優(yōu)惠，但是會員信息中又沒有傳卡信息時，就很有可能是開發(fā)中出現了bug，通過這樣的參數內部交叉校驗，我們就可以進行主動上報。

事實上，在一年后的一次重構過程中，開發(fā)同學真的又一次出現了同樣的失誤，而天網報警提供的信息這次就給與了我們很大的幫助。

截止目前，我們已經在業(yè)務核心鏈路上預埋了上百個報警點，并在線上多次真實預警了線上問題，讓我們可以第一時間進行主動修復。

2、更早發(fā)現問題

看完前文可能有細心的同學已經會問了：如果對問題進行了埋點報警，那么又何必等到它上線再去處理呢？是不是在上線前就可以把問題修復掉？

回歸階段

答案當然是可以的。有贊的移動端發(fā)版是采用發(fā)版車機制，每周一我們會將測試驗收通過的需求代碼 merge 到 dev分支，去打出“高鐵包”給測試同學進行回歸，并且配合自動化測試進行核心流程的回歸驗收，下周一高鐵包將會發(fā)布到市場。而高鐵的這一周時間，就是回歸發(fā)現問題的最佳時機。

因此我們將 crash 分析報警和天網業(yè)務告警的范疇都拓展到了回歸階段。高鐵階段的問題同樣會主動觸發(fā)報警，過去一年間，這兩個平臺都有多次在 bug 上線前主動報警的立功表現。

開發(fā)階段

回歸階段報警并不是我們思考的終點，核心鏈路問題的發(fā)現和解決還可以更早嗎？在開發(fā)階段，甚至是方案設計階段，有機會提前把一些線上問題扼殺在萌芽中嗎？

我們在針對端上可能發(fā)生資損的環(huán)節(jié)設計了單元測試，并將單測的運行接入到了 CI 流程中，這樣代碼在提交時，就會直接經過單測的檢驗。

那么什么樣的代碼適合寫單元測試呢？

我們經過討論，將范圍圈定在了移動端重新建模和發(fā)生運算兩種場景上，各個業(yè)務域的同學通過梳理產出自己的單測用例。

方案設計階段

還有比開發(fā)階段更早的時機嗎？可以在項目開發(fā)前就主動預防嗎？我們在移動端設計了行為校驗機制

行為校驗

所謂行為校驗，就是將用戶的操作行為和數據進行交叉校驗，這個校驗可以增加一個新的維度來預防 bug 的發(fā)生。

我們仍然采用上文提到的訂單參數中忘記傳會員卡信息的 bug 為例，這里選中卡這個操作是客戶端用戶點擊觸發(fā)的，那么用戶選卡的這個操作就是最終開單參數中應當包含會員卡的交叉校驗點。

這樣的校驗邏輯對于我們就是一條“校驗規(guī)則”，我們開發(fā)了行為校驗的底層SDK，就是在核心開單業(yè)務鏈路上通過將全流程的用戶操作行為和最終訂單數據進行double check，新增一個維度來為業(yè)務保駕護航，提前避免開發(fā)過程中的低級失誤引入 bug 的可能性。

類似的規(guī)則例子還有很多，比如一筆在線訂單收款成功之前，一定曾經成功調用過支付接口，可以用來預防一些同學在頁面跳轉上的bug；

目前我們的行為校驗已承載了核心業(yè)務鏈路上的多條規(guī)則，大大降低了資損故障的可能性。

問題的發(fā)現和解決貫穿整個研發(fā)流程

3、有效的流程機制支撐

雖然我們有了多樣的工具平臺來報警和及時發(fā)現問題，但是這樣就可以提升質量了嗎？在實踐中，我們深刻的認識到，工具只有在配套高效合理的流程機制支撐，才能真正發(fā)揮威力。

在平臺搭建初期，線上的crash和數據校驗報警平臺在報警時缺乏策略，沒有就報警頻率和at的負責人做收斂，導致單臺設備的一個小問題，機器人就會短時間在群里發(fā)出幾百條at所有人的報警消息。這種“狼來了”的報警只會讓大家關掉群消息提示，或者關掉企微的通知。

不懂得克制的報警，相當于沒有報警。

因此我們反復優(yōu)化了報警策略，以“報出來的問題都是需要立即響應，不需要立即響應的都不要報出來”為原則，沉淀了一系列報警策略。

除去報警策略，我們另一個在流程規(guī)范上的沉淀是在Code Review環(huán)節(jié)上。

betterMR

在我們團隊質量問題最嚴峻的時期，我們扭轉被動戰(zhàn)局的核心手段還是加強Code Review。但CR這件事情要想真的扎實做出效果，而不流于形式，是非常依賴好的流程機制進行支撐的。在強化和落地CR的過程中，我們面臨以下挑戰(zhàn)：

• 效率問題：我們約定每個MR都需要2個reviewer去做CR。事實上在整個CR過程中是需要很多溝通成本的，開發(fā)同學將MR發(fā)給兩位reviewer，reviewer會提一些建議反饋，開發(fā)同學進行修改后再次review，這個過程可能會反復多次，直到兩位reviewer都同意merge最后合并，整個過程中需要大量的溝通。而且reviewer常常手頭也在忙要晚些才有空，就更加會拖慢開發(fā)者的節(jié)奏。

CR過程中的溝通成本

• 顆粒度問題：一個項目中，改動到幾十個文件數千行代碼并不是小概率事件。reviewer要想在這么大面積的代碼中找出一些細節(jié)的邏輯問題或者typo的低級問題并非易事。

• 時機問題：以往我們CR的時機是放在上線前，事實上這個時間提出的一些優(yōu)化建議已然太晚，如果想要優(yōu)化改造又需要測試再次介入。因此一些好的建議只能塵封積灰，有些可能很久都等不到下次優(yōu)化的機會。

我們意識到，CR的過程必須通過流程規(guī)范提高其效率，降低對開發(fā)同學的打擾和負擔，這樣大家才能真正高質量的投入到CR中，相互保駕護航。

最終我們推出了betterMR機制，通過以下機制解決以上的挑戰(zhàn)：

• 硬性要求：所有上線代碼，至少2人review通過后才可以合入dev

  
  

• 時機問題&顆粒度問題：代碼在開發(fā)過程中，拆分成多個子任務，分批提MR合并到自己的feature分支。因此CR過程可以穿插到整個開發(fā)流程中，而不是在上線前最后review

• 溝通成本問題：企微通知全程介入CR流程，核心鏈路通知相關人，無需線下單獨溝通

• CR發(fā)起：開發(fā)同學在MR中at兩位reviewer，兩位reviewer都會收到企微通知消息

• CR建議：reviewer提出建議后，在評論中輸入[N]命令觸發(fā)企微通知給開發(fā)同學

• CR再次review：開發(fā)同學根據建議完成改造后，在評論中輸入[R]命令觸發(fā)企微通知給reviewer再次review代碼，確認建議已落地

• CR通過：reviewer通過后評論“+1”，當MR中已累計兩個“+1”時，開發(fā)同學會收到企微通知，代碼已可以合并

• 及時性問題：團隊對MR進行了分級，對應提出了及時性的要求

• 普通MR，要求24小時內完成review建議

• 緊急MR，要求2小時內完成review建議

• 數據匯總激勵：我們針對MR還統(tǒng)計了周報和月報，對于團隊中積極review代碼的同學，在周會和月會上給與激勵，讓大家都認可review的積極效果

這套機制我們在2020年6月推出后，團隊的線上問題數量立刻得到了有效控制。我們在當年Q3迅速將線上問題數量縮減到了之前的1/3，并在之后長期保持了很低的線上問題率。

過去兩年移動團隊的線上問題走勢

配合有效的流程機制，工具能力才能真正發(fā)揮效果

4、重視性能

前文也提到有贊移動的性能挑戰(zhàn)。在性能問題上我們的動作包括以下三個方面：

• APM平臺的搭建：主動發(fā)現線上問題，并且為線上卡頓問題提供分析數據與線索。

• 線下監(jiān)控平臺：對于性能問題，我們也同樣在探索在問題上線前發(fā)現和解決的可能性。我們所搭建的線下監(jiān)控平臺，在回歸階段對關鍵環(huán)節(jié)進行自動化測試并采集數據，如果發(fā)現同比上個版本某個數據有顯著提升，就會報警提示開發(fā)接入排查；

• 主動優(yōu)化：根據APM平臺和線下監(jiān)控平臺的數據與反饋，我們會主動安排性能優(yōu)化的方案，對app性能進行持續(xù)優(yōu)化。

可用性、性能與流程規(guī)范共同構建了移動質量建設矩陣

質量提升的成果

過去兩年我們在質量上的深耕與探索也給我們帶來了豐厚的成果，這個成果不僅體現在我們的月均線上問題數量上，更體現在我們持續(xù)的技術產出上。技術同學救火的頻率低了，就有更多時間主動出擊，去體系化的搭建系統(tǒng)去預防線上問題的發(fā)生，預防機制又能進一步降低線上問題發(fā)生的概率，形成良性循環(huán)，這無論對于團隊，還是開發(fā)同學個人的成長都是很有幫助的。

本文講到的有贊移動質量提升與實踐的過程，其實也一定程度上代表了我們團隊的工作方式。我們在應對有贊業(yè)務場景的過程中，會遇到如離線收銀、性能深度優(yōu)化等有挑戰(zhàn)有意思的技術難題。而面對這些挑戰(zhàn)和難題，我們會主動出擊，尋求體系化的解決方法。這些解決方案中往往還會涉及到后端服務和前端頁面的工作，以及產品化的思考，我們移動同學在此過程中不設邊界的拓展自己的技能包，最終形成讓人頗具成就感的技術沉淀。