成功进行演示之后，我们开始往产品化方向前进，但是越来越发现部分模块及部分架构越来越不适应整体需求和进度要求，所以我们启动了一次较大规模的重构，整体投入的工作量大概为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) 自动化测试工具能够提高重构的效率
原文地址：http://blog.csdn.net/wanghorse/article/details/41379483
