關(guān)于提高無線研發(fā)效率的建議

當(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ì)控制.

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末桐款,一起剝皮案震驚了整個濱河市猾编,隨后出現(xiàn)的幾起案子撮奏,更是在濱河造成了極大的恐慌报账,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,946評論 6 518
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件董济,死亡現(xiàn)場離奇詭異步清,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī)虏肾,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,336評論 3 399
  • 文/潘曉璐 我一進(jìn)店門廓啊,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人封豪,你說我怎么就攤上這事谴轮。” “怎么了吹埠?”我有些...
    開封第一講書人閱讀 169,716評論 0 364
  • 文/不壞的土叔 我叫張陵第步,是天一觀的道長。 經(jīng)常有香客問我缘琅,道長雌续,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,222評論 1 300
  • 正文 為了忘掉前任胯杭,我火速辦了婚禮,結(jié)果婚禮上受啥,老公的妹妹穿的比我還像新娘做个。我一直安慰自己,他們只是感情好滚局,可當(dāng)我...
    茶點(diǎn)故事閱讀 69,223評論 6 398
  • 文/花漫 我一把揭開白布居暖。 她就那樣靜靜地躺著,像睡著了一般藤肢。 火紅的嫁衣襯著肌膚如雪太闺。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,807評論 1 314
  • 那天嘁圈,我揣著相機(jī)與錄音省骂,去河邊找鬼。 笑死最住,一個胖子當(dāng)著我的面吹牛钞澳,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播涨缚,決...
    沈念sama閱讀 41,235評論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼轧粟,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起兰吟,我...
    開封第一講書人閱讀 40,189評論 0 277
  • 序言:老撾萬榮一對情侶失蹤通惫,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后混蔼,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體履腋,經(jīng)...
    沈念sama閱讀 46,712評論 1 320
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,775評論 3 343
  • 正文 我和宋清朗相戀三年拄丰,在試婚紗的時候發(fā)現(xiàn)自己被綠了府树。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 40,926評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡料按,死狀恐怖奄侠,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情载矿,我是刑警寧澤垄潮,帶...
    沈念sama閱讀 36,580評論 5 351
  • 正文 年R本政府宣布,位于F島的核電站闷盔,受9級特大地震影響弯洗,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜逢勾,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,259評論 3 336
  • 文/蒙蒙 一牡整、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧溺拱,春花似錦逃贝、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,750評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至句占,卻和暖如春沪摄,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背纱烘。 一陣腳步聲響...
    開封第一講書人閱讀 33,867評論 1 274
  • 我被黑心中介騙來泰國打工杨拐, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人凹炸。 一個月前我還...
    沈念sama閱讀 49,368評論 3 379
  • 正文 我出身青樓戏阅,卻偏偏與公主長得像,于是被迫代替她去往敵國和親啤它。 傳聞我的和親對象是個殘疾皇子奕筐,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,930評論 2 361

推薦閱讀更多精彩內(nèi)容