重构不是一朝一夕的事情，是一个持续的过程

• 要注重代码注释，对创建的每一个页面，类，方法，关键变量都要有对应的注释，对于类要写明作者是谁，创建修改时间，还有是做什么。
  这样对后面的同学或者自己时间久了梳理流程的时候，会顺畅很多。类头注释规范可以在setting -> File and Code Templates -> File Header 中添加固定样式
• 命名规范，包括类，方法，字段，xml布局，string、color、drawable等资源文件
  对于命名要做到见其名，知其意，长一点也没关系，要注重编码规范，对于资源命名，不光要能见名知意，还要开了组件化开发，为了防止后期资源冲突，可以在module的build.gradle中给资源添加前缀限制，就会提示在创建资源时需要添加前缀了
  推荐使用插件：Alibaba Java Coding Guidelines

//给 Module 内的资源名增加前缀, 避免资源名冲突 resourcePrefix "${project.name.toLowerCase().replaceAll("-", "_")}_"

• 对工具类进行封装，比如Log、Toast、dialog、SharedPreferences（MMKV）、屏幕管理类（dp、px转换，屏幕宽高的获取）线程池等，对于对人维护过的项目，工具类可能就有好几套，删除多余的工具类，汇聚到一起，只维护一套
• 第三方框架统一，比如网络请求、图片加载等
  对于第三方的网络请求框架，时间太长可能会维护很多套请求框架，比如最早期的HttpURLConnection，Volley，后来的OkHttp，以及Retrofit等，如果存在多套网络请求，如果后期需要修改一些公共参数，比如增加头部参数，更改域名，参数加密等，就很难受了，对于这种问题如果直接全部替换，风险就会很大，要循序渐进，要选择一个稳定性好、性能好的框架。将代码中的请求与网络框架进行解耦，使用工厂模式来负责初始化对应的网络框架，由统一抽象类约束网络框架的行为，这样就算有新的网络框架也可以无需修改业务代码的情况下替换底层框架
• 使用模块化、组件化，使用模块化、组件化来实现架构的分层
  分析模块分层的颗粒是否符合预期，随着业务的发展，可能之前的模块分层出现问题，代码臃肿，需要考虑是否需要细分
  当项目越来越大，就需要考虑组件化了，在模块化的基础上去做组件化，
  • 模块化是按照业务划分，独立的业务模块，每一个模块业务都可以单独抽取出来作为SDK对外发布使用，比如登录、订单、个人中心、视频，音频
  • 组件化是按照功能划分，指的是单一的功能组件，比如网络、图片、数据库等，划分为基础功能组件，通用UI组件，基础业务组件
• MVVM、MVP，对代码隔离
  如果项目中已经使用了mvp，那就接着用mvp，不要因为一些东西出来了，比如现在Google强推一个jetpack，就马上换MVVM，那样风险是非常大的，如果需要大的整改可以使用MVVM来进行重构。LiveData + ViewModel优势是很大的
• 使用设计模式：可以根据自己实际的项目来使用一些设计模式，比如单例，观察者，工厂，Build模式，策略模式，门店模式，装饰模式等
• 网络数据模式：后端返回的数据结构统一
• 性能优化：启动、卡顿，内存，启动，布局优化，apk体积
• 技术文档输出：需要一边重构，一边输出文档
• 需要定期重构：后续发现有问题的地方，就可以进行重构