移動端質(zhì)量提升探索與實踐

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

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

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

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

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

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

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

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

• 受限的硬件水平。

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

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

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

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

門店場景中供門店收銀的HD應(yīng)用

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

• 營銷計算中的資損風(fēng)險

• 問題的及時修復(fù)能力

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

問題的及時修復(fù)能力：當(dāng)線上問題可能涉及資損時，也進(jìn)而會對移動端的問題修復(fù)能力提出更高的要求。

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

2、受限的硬件水平

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

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

• 紅米 Note9 手機(jī)，安卓千元機(jī)，內(nèi)存6G，某電商平臺售價999

  
  

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

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

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

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

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

我們將探索中的心得歸納為以下幾點(diǎn)：

• 主動發(fā)現(xiàn)問題

• 更早發(fā)現(xiàn)問題

• 有效的流程機(jī)制支撐

• 重視性能

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

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

天網(wǎng)數(shù)據(jù)報警平臺

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

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

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

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

• 任務(wù)分配：問題可以分配給責(zé)任人跟進(jìn)

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

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

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

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

• 數(shù)據(jù)校驗：對于端上通過輸入或者計算產(chǎn)生的數(shù)據(jù)，可以通過交叉校驗分析異常；

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

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

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

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

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

• 支付信息（最終通過會員價2.5元結(jié)算，通過現(xiàn)金進(jìn)行支付）

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

  
  

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

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

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

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

看完前文可能有細(xì)心的同學(xué)已經(jīng)會問了：如果對問題進(jìn)行了埋點(diǎn)報警，那么又何必等到它上線再去處理呢？是不是在上線前就可以把問題修復(fù)掉？

回歸階段

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

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

開發(fā)階段

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

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

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

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

方案設(shè)計階段

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

行為校驗

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

我們?nèi)匀徊捎蒙衔奶岬降挠唵螀?shù)中忘記傳會員卡信息的 bug 為例，這里選中卡這個操作是客戶端用戶點(diǎn)擊觸發(fā)的，那么用戶選卡的這個操作就是最終開單參數(shù)中應(yīng)當(dāng)包含會員卡的交叉校驗點(diǎn)。

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

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

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

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

3、有效的流程機(jī)制支撐

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

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

不懂得克制的報警，相當(dāng)于沒有報警。

因此我們反復(fù)優(yōu)化了報警策略，以“報出來的問題都是需要立即響應(yīng)，不需要立即響應(yīng)的都不要報出來”為原則，沉淀了一系列報警策略，詳細(xì)內(nèi)容可以參見之前的公眾號文章《有贊移動天網(wǎng)平臺搭建》中的相關(guān)章節(jié)。

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

betterMR

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

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

CR過程中的溝通成本

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

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

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

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

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

  
  

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

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

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

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

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

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

• 及時性問題：團(tuán)隊對MR進(jìn)行了分級，對應(yīng)提出了及時性的要求

• 普通MR，要求24小時內(nèi)完成review建議

• 緊急MR，要求2小時內(nèi)完成review建議

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

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

過去兩年移動團(tuán)隊的線上問題走勢

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

4、重視性能

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

• APM平臺的搭建：主動發(fā)現(xiàn)線上問題，并且為線上卡頓問題提供分析數(shù)據(jù)與線索。APM平臺的詳細(xì)設(shè)計與實現(xiàn)，參加之前的公眾號文章《有贊移動性能監(jiān)控平臺（二）》

• 線下監(jiān)控平臺：對于性能問題，我們也同樣在探索在問題上線前發(fā)現(xiàn)和解決的可能性。我們所搭建的線下監(jiān)控平臺，在回歸階段對關(guān)鍵環(huán)節(jié)進(jìn)行自動化測試并采集數(shù)據(jù)，如果發(fā)現(xiàn)同比上個版本某個數(shù)據(jù)有顯著提升，就會報警提示開發(fā)接入排查；線下監(jiān)控平臺的詳細(xì)實現(xiàn)參加之前的公眾號文章《有贊移動性能監(jiān)控平臺（一）》

• 主動優(yōu)化：根據(jù)APM平臺和線下監(jiān)控平臺的數(shù)據(jù)與反饋，我們會主動安排性能優(yōu)化的方案，對app性能進(jìn)行持續(xù)優(yōu)化。我們之前的公眾號文章《線程池優(yōu)化與監(jiān)控》就是其中的一個典型例子。

可用性、性能與流程規(guī)范共同構(gòu)建了移動質(zhì)量建設(shè)矩陣

質(zhì)量提升的成果

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

過去兩年，有贊移動團(tuán)隊僅在質(zhì)量建設(shè)方面就產(chǎn)出了多篇公眾號文章，每篇文章背后都是技術(shù)同學(xué)的積累和沉淀：

• 有贊移動性能監(jiān)控平臺（一）

• 有贊移動性能監(jiān)控平臺（二）

• 有贊移動天網(wǎng)平臺搭建

• 有贊移動Crash平臺建設(shè)

• 有贊移動日志實踐

• 線程池優(yōu)化與監(jiān)控

• 有贊移動熱修復(fù)平臺建設(shè)

• 有贊iOS精準(zhǔn)測試實踐

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

我們也非常期待和歡迎更多喜歡這樣工作方式的同學(xué)加入到我們有贊移動的家庭中，一起enjoy。