移動端群組視訊通話軟體開發（六）-- 重構

標籤：架構   重構   視頻   voip   webrtc   

成功進行示範之後，我們開始往產品化方向前進，但是越來越發現部分模組及部分架構越來越不適應整體需求和進度要求，所以我們啟動了一次較大規模的重構，整體投入的工作量大概為6人月。

 

1.   重構原因

a)       需求不滿足，由於我們這個產品的底層部分需要支援所有公司的現有產品，但是當前在設計的時候只是考慮了當前需要示範的產品，所以在某些模組的架構方面沒有考慮太多，需要重構

b)       需要支援多個平台，iOS/Android/Windows, 而現有的部分模組的處理代碼基本是各個平台獨立開來的，導致維護工作量較大，需要重構

c)       在開發過程中，我們自己增加的一些模組的介面沒有適應我們總體的架構流程，導致各個模組無法統一，需要重構

d)       部分模組的職責不明確，導致相互之間的耦合太嚴重，進一步導致同步問題較多，crash問題比較難弄，需要重構

e)       代碼規範等

 

2.   重構原則

a)       測試載入器先行，自動化測試載入器

b)       模組內測要通過

c)       小步快走，一周一個版本，不影響整體發布進度

 

3.   重構步驟

a)       投入4個人同時做， 具體如下分工：控制流程程和整體介面，編解碼部分重構和介面，網路部分重構和介面，去Live555化及RTP部分重構和介面

b)       第一周：整體流程和各模組內部介面重構完成

c)       第二周：整體介面重構完成，各模組內部繼續重構

d)       第三周：整體控制重構完成，各模組內部繼續重構

e)       第四周：各模組內部重構完成

f)        重構細節專門篇幅講解

 

4.   重構結果和經驗教訓

a)       基本完成了既定目標，可維護性和可擴充性得到了大幅提高

b)       進度控制有點偏差，當時的估計有點樂觀，後續又投入了2人月提高穩定性和音視頻品質的最佳化

c)       針對這次重構，我們專門做了3次技術分享

d)       較大重構的時候的小步快走這方式很好，需要推廣

e)       自動化測試載入器能夠提高重構的效率

移動端群組視訊通話軟體開發（六）-- 重構