當(dāng)前情況
SDK之殤
目前ABC客戶端有大量的功能是通過接入sdk的方式實(shí)現(xiàn)的, 同時可以預(yù)見的是, 在未來, 接入sdk的數(shù)量還會跟業(yè)務(wù)一樣增長, 會讓我們的ABC客戶端變得更加臃腫. 這些sdk中, 存在了大量我們客戶端不適合也不會用到的功能.
同時, 這些sdk中, 存在了錯綜復(fù)雜的依賴關(guān)系, 這些關(guān)系是很強(qiáng)的版本依賴關(guān)系. 每次SDK升級, 往往伴隨著連帶的sdk升級, 接入方每次都需要投入人力成本進(jìn)行維護(hù), 從而造成了大量的人力浪費(fèi).性能之惑
ABC客戶端無論是CPU/內(nèi)存/流量使用都是購物類app中最大的. 弱網(wǎng)體驗(yàn)也不好, 甚至不如手淘. 隨之而來的就是響應(yīng)慢, 卡頓, 易崩潰等問題. 我們的安裝包也隨著不斷的接入各種SDK而慢慢變大, 可以跟一款主流游戲一較高下了.研發(fā)之困
流程冗長. 無論大小, 無論業(yè)務(wù)是否穩(wěn)定, 我們都采用了需求-交互-開發(fā)-測試-灰度-發(fā)布 這統(tǒng)一的流程. 面對多變的產(chǎn)品, 我們靈活度不夠, 面對小的需求, 我們的流程又顯的過長.
關(guān)于SDK
SDK中有大量的代碼我們不會用.
SDK是一個很好的提升總體研發(fā)效率的手段. 但是濫用SDK, 就會造成目前我們遇到的種種問題. 在我們接入的SDK中, 有很大一部分功能是我們用不到的, 里面有很大一部分的代碼是我們的業(yè)務(wù)不會走到的. 但是這些功能依然占據(jù)了我們的安裝包, 慢慢的讓ABC變得臃腫和緩慢.讓人頭痛的依賴關(guān)系.
我們接入的SDK并非獨(dú)立的存在, 很多時候, SDK之間有著千絲萬縷的依賴關(guān)系. 比如我們因?yàn)槟硞€視頻業(yè)務(wù)需要接入視頻模塊, 發(fā)現(xiàn)其依賴于底層的webview模塊, 如果接入了webview模塊, 所有依賴于webview的模塊都存在回歸風(fēng)險(xiǎn).
接入了一個sdk就意味著打開了一個潘多拉盒子.不勝其擾的測試需求.
場景一:
"今天我們更新了一個版本, 修正了一個bug, 影響很大. 你們回歸一下"
"重點(diǎn)是什么?"
"都看一下, 影響很大"
"上次也是這么說的啊..."
"你就回歸吧, 反正很大..."
場景二:
"親, 在嗎? 今天我們發(fā)現(xiàn)了一個sdk的bug, 你看看?"
"你們用的sdk版本是多少?"
"1.1.0"
"我們都1.1.2了, 你們先升上去看看吧"
"親, 你確定升級就能解決?"
"恩, 你這個bug我懷疑跟我們之前的那個是同一個問題, 你先升上去看看."
如有雷同, 不勝榮幸
關(guān)于性能
從當(dāng)前收集到的數(shù)據(jù)來看, ABC在幾個購物類應(yīng)用的橫向比較中屬于資源使用非常重的.
一個主要的原因是無線方面的性能的關(guān)注點(diǎn)不夠, 針對業(yè)務(wù)的解決方案偏中重資源消耗. 比如: 對于外部庫的引入不節(jié)制, 使用部分, 或小部分功能也引入. 對于圖片大小, 清晰度沒有實(shí)驗(yàn)意識, 為了滿足產(chǎn)品希望無條件的使用大圖.
現(xiàn)在的App就像是一個房間, 每個人都想把自己的東西裝進(jìn)入, 但是不關(guān)心這個房間還能有多少空間.
同時, 翻看我們啟動過程, 其中, 特殊的業(yè)務(wù)邏輯, 配置拉取, 預(yù)加載等等. 使得我們的啟動愈發(fā)緩慢.
執(zhí)著于加法, 忘記了減法
關(guān)于開發(fā)流程
每個月的移動端發(fā)版都是一個痛苦的過程. 問題的實(shí)質(zhì)就在于反饋過長. 我們絕大多數(shù)的業(yè)務(wù), 使用了瀑布式的開發(fā)模式
需求 -> 交互 -> 開發(fā) -> 測試.
如果每個流程一周, 需要一個月
一個再小的業(yè)務(wù)需求, 都需要4個以上的人參與, 每一個環(huán)節(jié)進(jìn)入到下游都需要巨大的溝通成本
為了應(yīng)對溝通問題, 我們有我們的項(xiàng)目室. 不過, 仍然有很多人傾向于在自己的工位上免打擾的完成工作.
確保這個流程正常運(yùn)轉(zhuǎn)的, 是我們的評審制度.
需求(需求評審) -> 交互(交互評審) -> 開發(fā)(開發(fā)Review) -> 測試(用例評審 + 灰度)
所有這些流程, 大多會在一個月甚至更短的時間完成. 而且還不可避免的涉及到了返工:
- 如果開發(fā)過程中發(fā)現(xiàn)交互不完備, 需要改交互
- 如果開發(fā)過程中發(fā)現(xiàn)需求有紕漏, 需要改需求
- 如果需求點(diǎn)無法實(shí)現(xiàn), 需要改開發(fā)方案
同時, 當(dāng)以上情況發(fā)生時, 很難保證對應(yīng)的評審會有效的召開, 為質(zhì)量埋下了隱患.
幾點(diǎn)思考
- 明確SDK的接入標(biāo)準(zhǔn), 構(gòu)建緩沖層.
作為SDK的接入方, 直接介入某一個SDK是非常危險(xiǎn)的事情. 評估工作量, 依賴關(guān)系, SDK的成熟度, 以及對于應(yīng)用整體性能影響是必要的第一步. 而且, 在實(shí)施接入的過程中, 構(gòu)建一個wrapper來封裝接入的SDK. 使得SDK和接入應(yīng)用之間有一個"緩沖層", 這樣可以有效減少SDK升級, 變動, 功能不完善等造成的影響.
- SDK的設(shè)計(jì)盡量單一化, 盡量減少SDK之間的依賴
如果SDK中有針對接入方的邏輯, 那么這部分必然是浪費(fèi)的. 同是, SDK間依賴關(guān)系也為今后的質(zhì)量買下了隱患. 這就需要在SDK設(shè)計(jì)上, 做到單一化. 應(yīng)該 __嚴(yán)格禁止 __業(yè)務(wù)邏輯和基礎(chǔ)功能混合在一起的SDK.
- SDK的測試全面化
以某一接入方為樣本進(jìn)行測試, 就存在了其他接入方的風(fēng)險(xiǎn). 而修改內(nèi)容不是每個接入方都清楚, 這就造成了測試實(shí)施中溝通成本大, 無謂測試增多. 理想方式, 是SDK升級的測試, 覆蓋所有接入方. 同時, 如果做到了SDK單一化, 那么SDK的測試成本也會大大降低.
- 定期的性能專項(xiàng)測試
相比很多互聯(lián)網(wǎng)公司/團(tuán)隊(duì)都有無線方面的專項(xiàng)測試團(tuán)隊(duì), 我們在這方面的投入真的不多. 無論是流程還是投入人員都無法保證. 性能體驗(yàn)需要一定的專注和堅(jiān)持, 在保證人員投入的同時, 更加頻繁的定期進(jìn)行性能專項(xiàng)測試活動尤為必要.
- 完善現(xiàn)有的評審制度.
需求評審, 交互評審, 開發(fā)方案的評審, 測試用力的評審, 都需要有明確的CheckList和準(zhǔn)入標(biāo)準(zhǔn), 能夠明確的幫助團(tuán)隊(duì)識別出來當(dāng)前處于哪個階段. 盡力避免一句話需求, 不完整的交互, 不完善的開發(fā)方案, 有疏漏的測試.
- 發(fā)版計(jì)劃中, 只包含"成熟度高" 的需求.
我們完整的一個流程既然很長, 而且還涉及到了反復(fù)的修改. 那么在制定發(fā)版計(jì)劃的時候(也就是PM收集需求的時候), 只采用已經(jīng)經(jīng)過交互評審的需求, 這樣會大大減少反復(fù)修改需求造成的問題.
- 采取更輕的項(xiàng)目室制度.
在規(guī)定時間內(nèi), 產(chǎn)品, 交互, 開發(fā), 測試都在一個地方辦公. 在項(xiàng)目起初就制度化.
- 嘗試跨職能的小團(tuán)隊(duì)
減少溝通成本, 有效的控制產(chǎn)品的開發(fā)過程. 職能團(tuán)隊(duì)在控制單品的質(zhì)量方面更加突出, 不過我們目前的團(tuán)隊(duì)個人無論經(jīng)驗(yàn)還是能力, 都屬于行業(yè)中上, 所以有效的溝通, 培養(yǎng)團(tuán)隊(duì)默契對于提升效率更加重要. 同時, 針對新業(yè)務(wù), 尚且處于摸索階段的新功能, 跨職能團(tuán)隊(duì)能給出更快的響應(yīng)速度和更獨(dú)立的品質(zhì)控制.
