重构项目的思考

项目情况

• 该项目是统一SDK接入框架，游戏商接入该框架，即可打包各大渠道
• 游戏层->抽象层->渠道层，该框架处于抽象层，用到较多接口回调，并且没有视图层

之前使用痛点

1. 类名没有言简意赅，包结构混乱，造成上手、混淆难度提升
2. 抽象层没有视图层，游戏接入后，没法测试，需要提供母包，打包后才能测试
3. bean字段不全，没法对应各渠道需求，暂时只能调整业务迂回补救
4. 网络请求没有进行封装，增加调试难度。
5. 渠道层各实现类有很多重复代码，增加了渠道层接入的工作量
6. 个别功能回调缺失，没法满足渠道要求
7. 状态码不全，没法满足渠道要求
8. 功能实现不合理，造成客户端控制起来很困难

版本1

1. 按层级建立包结构
2. 理清运行原理，在抽象层中嵌入自家的SDK作为默认实现
3. 研究国内外各大主流SDK需求，扩充字段
4. 抽取网络请求基类，调用静态工厂方法创建对应请求
5. 抽取渠道抽象模板基类，封装共有行为，提供必需、可选方法，并提供默认实现
6. 调研需求，适配各渠道，增加相应回调
7. 调研需求，适配各渠道，增加相应状态码
8. 转移功能，由服务端控制，返回结果给客户端
9. 修改打包工具代码，增加动态写入配置文件的配置