接手外包团队的项目，虽然给自己了提前打了预防针，但是还是踩了大堆的坑。
接手时候项目结构：
image.png
当时大致情况为使用MVC的设计模式，看分包就大概看的很明白
存在问题：
1.没有按功能按业务分包：其中所有的几十个activity 堆在一个文件夹几十个fragment堆在一个文件夹，其他的适配器控制器也是一堆堆在这。
2.代码质量惨不忍睹：毕竟崩溃跳出率几乎100%,太多回调空指针。
3.重复框架太多：可能是大概第四轮接手，各种重复的轮子比较多，java kt混编的就不说了，图片加载框架竟然用2套fresco和glide，
4.常量引用混乱，造成内存泄漏严重。
5.未有统计异常上报埋点等。
6.命名严重反人类，拼音（并且不标准）+英文。
接手之后思路：先不做代码审查优化，先稳定版本，修复bug,增加新功能，一个方向一个方向去调整。
1.增加统计和异常上报的功能，选择了友盟和腾讯bugly.一边增加新功能一边改bug,
首先使用monkey测试（又是开发测试一手，没办法），就手头现有设备Android版本进行多次monkey测试，把能测出来的明显崩溃级别错误修复。
然后先发了一版没有更新新功能的上架，刚开始用户不多，所以并不是特别在意影响体验，主要侧重新功能的完善。然后大概持续一周又收集到其他未测试的错误，修复完上架：
image.png
就这样的步骤迭代2个小本版本，其中解决了图片加载框架 全部改为fresco,重新分包，修改常量引用，定义一个常量，而不是直接类名引用，改造部分存储方式，引入greendao,重新按功能业务分包等。
10.08
此时的项目结构大概是这样的，至少定位查找方便了很多。
然后新的功能添加同时继续修改bug,开始有条理的做codereview.
image.png
用户是有点少，当然统计的埋点在友盟，未做任何推广
image.png
比较重要工作
0.按功能业务拆分分包；
1.重新完善原有的activity以及fragment的Base；
2.完善网络的封装：okhttp 以及拦截器（是否登陆）；
3.统一图片加载框架；
4.修改了常量引用；
5.完善了第三方分享登录的bug(原项目使用别人GItHub的第三方登录分享，简直了，也只是修复)
6.引入统计上报。
时间太紧，也没有做推广。计划春节前把细节再优化一边。
网友评论