當(dāng)前情況

• SDK之殤
  目前ABC客戶端有大量的功能是通過接入sdk的方式實(shí)現(xiàn)的, 同時(shí)可以預(yù)見的是, 在未來, 接入sdk的數(shù)量還會(huì)跟業(yè)務(wù)一樣增長, 會(huì)讓我們的ABC客戶端變得更加臃腫. 這些sdk中, 存在了大量我們客戶端不適合也不會(huì)用到的功能.
  同時(shí), 這些sdk中, 存在了錯(cuò)綜復(fù)雜的依賴關(guān)系, 這些關(guān)系是很強(qiáng)的版本依賴關(guān)系. 每次SDK升級(jí), 往往伴隨著連帶的sdk升級(jí), 接入方每次都需要投入人力成本進(jìn)行維護(hù), 從而造成了大量的人力浪費(fèi).

• 性能之惑
  ABC客戶端無論是CPU/內(nèi)存/流量使用都是購物類app中最大的. 弱網(wǎng)體驗(yàn)也不好, 甚至不如手淘. 隨之而來的就是響應(yīng)慢, 卡頓, 易崩潰等問題. 我們的安裝包也隨著不斷的接入各種SDK而慢慢變大, 可以跟一款主流游戲一較高下了.

• 研發(fā)之困
  流程冗長. 無論大小, 無論業(yè)務(wù)是否穩(wěn)定, 我們都采用了需求-交互-開發(fā)-測(cè)試-灰度-發(fā)布 這統(tǒng)一的流程. 面對(duì)多變的產(chǎn)品, 我們靈活度不夠, 面對(duì)小的需求, 我們的流程又顯的過長.

關(guān)于SDK

• SDK中有大量的代碼我們不會(huì)用.
  SDK是一個(gè)很好的提升總體研發(fā)效率的手段. 但是濫用SDK, 就會(huì)造成目前我們遇到的種種問題. 在我們接入的SDK中, 有很大一部分功能是我們用不到的, 里面有很大一部分的代碼是我們的業(yè)務(wù)不會(huì)走到的. 但是這些功能依然占據(jù)了我們的安裝包, 慢慢的讓ABC變得臃腫和緩慢.

• 讓人頭痛的依賴關(guān)系.
  我們接入的SDK并非獨(dú)立的存在, 很多時(shí)候, SDK之間有著千絲萬縷的依賴關(guān)系. 比如我們因?yàn)槟硞€(gè)視頻業(yè)務(wù)需要接入視頻模塊, 發(fā)現(xiàn)其依賴于底層的webview模塊, 如果接入了webview模塊, 所有依賴于webview的模塊都存在回歸風(fēng)險(xiǎn).
  接入了一個(gè)sdk就意味著打開了一個(gè)潘多拉盒子.

• 不勝其擾的測(cè)試需求.
  場(chǎng)景一:
  "今天我們更新了一個(gè)版本, 修正了一個(gè)bug, 影響很大. 你們回歸一下"
  "重點(diǎn)是什么?"
  "都看一下, 影響很大"
  "上次也是這么說的啊..."
  "你就回歸吧, 反正很大..."
  場(chǎng)景二:
  "親, 在嗎? 今天我們發(fā)現(xiàn)了一個(gè)sdk的bug, 你看看?"
  "你們用的sdk版本是多少?"
  "1.1.0"
  "我們都1.1.2了, 你們先升上去看看吧"
  "親, 你確定升級(jí)就能解決?"
  "恩, 你這個(gè)bug我懷疑跟我們之前的那個(gè)是同一個(gè)問題, 你先升上去看看."

如有雷同, 不勝榮幸

關(guān)于性能

從當(dāng)前收集到的數(shù)據(jù)來看, ABC在幾個(gè)購物類應(yīng)用的橫向比較中屬于資源使用非常重的.

一個(gè)主要的原因是無線方面的性能的關(guān)注點(diǎn)不夠, 針對(duì)業(yè)務(wù)的解決方案偏中重資源消耗. 比如: 對(duì)于外部庫的引入不節(jié)制, 使用部分, 或小部分功能也引入. 對(duì)于圖片大小, 清晰度沒有實(shí)驗(yàn)意識(shí), 為了滿足產(chǎn)品希望無條件的使用大圖.

現(xiàn)在的App就像是一個(gè)房間, 每個(gè)人都想把自己的東西裝進(jìn)入, 但是不關(guān)心這個(gè)房間還能有多少空間.

同時(shí), 翻看我們啟動(dòng)過程, 其中, 特殊的業(yè)務(wù)邏輯, 配置拉取, 預(yù)加載等等. 使得我們的啟動(dòng)愈發(fā)緩慢.

執(zhí)著于加法, 忘記了減法

關(guān)于開發(fā)流程

每個(gè)月的移動(dòng)端發(fā)版都是一個(gè)痛苦的過程. 問題的實(shí)質(zhì)就在于反饋過長. 我們絕大多數(shù)的業(yè)務(wù), 使用了瀑布式的開發(fā)模式

需求 -> 交互 -> 開發(fā) -> 測(cè)試.

如果每個(gè)流程一周, 需要一個(gè)月

一個(gè)再小的業(yè)務(wù)需求, 都需要4個(gè)以上的人參與, 每一個(gè)環(huán)節(jié)進(jìn)入到下游都需要巨大的溝通成本

為了應(yīng)對(duì)溝通問題, 我們有我們的項(xiàng)目室. 不過, 仍然有很多人傾向于在自己的工位上免打擾的完成工作.

確保這個(gè)流程正常運(yùn)轉(zhuǎn)的, 是我們的評(píng)審制度.

需求(需求評(píng)審) -> 交互(交互評(píng)審) -> 開發(fā)(開發(fā)Review) -> 測(cè)試(用例評(píng)審 + 灰度)

所有這些流程, 大多會(huì)在一個(gè)月甚至更短的時(shí)間完成. 而且還不可避免的涉及到了返工:

• 如果開發(fā)過程中發(fā)現(xiàn)交互不完備, 需要改交互
• 如果開發(fā)過程中發(fā)現(xiàn)需求有紕漏, 需要改需求
• 如果需求點(diǎn)無法實(shí)現(xiàn), 需要改開發(fā)方案

同時(shí), 當(dāng)以上情況發(fā)生時(shí), 很難保證對(duì)應(yīng)的評(píng)審會(huì)有效的召開, 為質(zhì)量埋下了隱患.

幾點(diǎn)思考

• 明確SDK的接入標(biāo)準(zhǔn), 構(gòu)建緩沖層.

作為SDK的接入方, 直接介入某一個(gè)SDK是非常危險(xiǎn)的事情. 評(píng)估工作量, 依賴關(guān)系, SDK的成熟度, 以及對(duì)于應(yīng)用整體性能影響是必要的第一步. 而且, 在實(shí)施接入的過程中, 構(gòu)建一個(gè)wrapper來封裝接入的SDK. 使得SDK和接入應(yīng)用之間有一個(gè)"緩沖層", 這樣可以有效減少SDK升級(jí), 變動(dòng), 功能不完善等造成的影響.

• SDK的設(shè)計(jì)盡量單一化, 盡量減少SDK之間的依賴

如果SDK中有針對(duì)接入方的邏輯, 那么這部分必然是浪費(fèi)的. 同是, SDK間依賴關(guān)系也為今后的質(zhì)量買下了隱患. 這就需要在SDK設(shè)計(jì)上, 做到單一化. 應(yīng)該 __嚴(yán)格禁止 __業(yè)務(wù)邏輯和基礎(chǔ)功能混合在一起的SDK.

• SDK的測(cè)試全面化

以某一接入方為樣本進(jìn)行測(cè)試, 就存在了其他接入方的風(fēng)險(xiǎn). 而修改內(nèi)容不是每個(gè)接入方都清楚, 這就造成了測(cè)試實(shí)施中溝通成本大, 無謂測(cè)試增多. 理想方式, 是SDK升級(jí)的測(cè)試, 覆蓋所有接入方. 同時(shí), 如果做到了SDK單一化, 那么SDK的測(cè)試成本也會(huì)大大降低.

• 定期的性能專項(xiàng)測(cè)試

相比很多互聯(lián)網(wǎng)公司/團(tuán)隊(duì)都有無線方面的專項(xiàng)測(cè)試團(tuán)隊(duì), 我們?cè)谶@方面的投入真的不多. 無論是流程還是投入人員都無法保證. 性能體驗(yàn)需要一定的專注和堅(jiān)持, 在保證人員投入的同時(shí), 更加頻繁的定期進(jìn)行性能專項(xiàng)測(cè)試活動(dòng)尤為必要.

• 完善現(xiàn)有的評(píng)審制度.

需求評(píng)審, 交互評(píng)審, 開發(fā)方案的評(píng)審, 測(cè)試用力的評(píng)審, 都需要有明確的CheckList和準(zhǔn)入標(biāo)準(zhǔn), 能夠明確的幫助團(tuán)隊(duì)識(shí)別出來當(dāng)前處于哪個(gè)階段. 盡力避免一句話需求, 不完整的交互, 不完善的開發(fā)方案, 有疏漏的測(cè)試.

• 發(fā)版計(jì)劃中, 只包含"成熟度高" 的需求.

我們完整的一個(gè)流程既然很長, 而且還涉及到了反復(fù)的修改. 那么在制定發(fā)版計(jì)劃的時(shí)候(也就是PM收集需求的時(shí)候), 只采用已經(jīng)經(jīng)過交互評(píng)審的需求, 這樣會(huì)大大減少反復(fù)修改需求造成的問題.

• 采取更輕的項(xiàng)目室制度.

在規(guī)定時(shí)間內(nèi), 產(chǎn)品, 交互, 開發(fā), 測(cè)試都在一個(gè)地方辦公. 在項(xiàng)目起初就制度化.

• 嘗試跨職能的小團(tuán)隊(duì)

減少溝通成本, 有效的控制產(chǎn)品的開發(fā)過程. 職能團(tuán)隊(duì)在控制單品的質(zhì)量方面更加突出, 不過我們目前的團(tuán)隊(duì)個(gè)人無論經(jīng)驗(yàn)還是能力, 都屬于行業(yè)中上, 所以有效的溝通, 培養(yǎng)團(tuán)隊(duì)默契對(duì)于提升效率更加重要. 同時(shí), 針對(duì)新業(yè)務(wù), 尚且處于摸索階段的新功能, 跨職能團(tuán)隊(duì)能給出更快的響應(yīng)速度和更獨(dú)立的品質(zhì)控制.