Development of mobile multi-person video calling software (vi)--reconstruction

After a successful demonstration, we began to move towards the product, but more and more we found that some of the modules and parts of the architecture are increasingly not adapted to the overall requirements and schedule requirements, so we started a large-scale refactoring, the overall input workload of about 6 people months.

1. Reason for refactoring

A) The demand is not satisfied, because the bottom part of our product needs to support all the existing products of the company, but the current design is only considering the current needs to demonstrate the products, so in some of the architecture of the module does not consider too much, need to refactor

b) need to support multiple platforms, ios/android/windows, and the existing part of the module's processing code is basically independent of each platform, resulting in a large maintenance workload, need to refactor

c) In the development process, we add some of our own modules of the interface does not adapt to our overall architectural process, resulting in the integration of the various modules, need to refactor

D) The responsibilities of some modules are not clear, resulting in mutual coupling is too serious, further resulting in more synchronization problems, crash problem is more difficult to get, need to reconstruct

e) Code specification, etc.

2. Refactoring principles

A) test tools first, automated test tools

b) module to pass

c) walk fast, one version a week, without affecting the overall release progress

3. Refactoring steps

A) Devote 4 people to do it at the same time, specifically as follows: Control process and overall interface, codec part refactoring and interface, network part reconfiguration and interface, de-Live555 and RTP partial refactoring and interface

b) First week: Overall process and internal interface reconfiguration of each module completed

c) Second week: The whole interface reconfiguration is completed, and the internal reconstruction of the modules is continued.

D) Third week: Overall control reconstruction complete, the internal reconstruction of each module

e) Fourth week: internal reconfiguration of each module completed

f) Refactoring details dedicated to explaining

4. Refactoring results and lessons learned

A) Basic objectives have been achieved, maintainability and scalability have been significantly improved

b) Progress control a bit biased, then the estimate was a little optimistic, followed by a 2-person month to improve stability and audio and video quality optimization

c) For this refactoring, we have dedicated 3 technology sharing

d) A small step in a large reconstruction. This is a good way to promote

e) Automated testing tools to improve the efficiency of refactoring

Development of mobile multi-person video calling software (vi)--reconstruction