我们的课程一步步由普通架构重构为组件化架构又重构插件化架构，那大家想没想过，一般出现什么时机的时候，需要我们去重构呢

讨论题目:

课程从第3章开始就对APP慢慢进行重构改造，那大家有没有想过，是什么原因导致了老师要对一个可以正常运行的音乐APP去进行重构，直接在原代码上继续开发新功能不可以吗？以下几点是老师总结的重构可以开始的一些时机

思路点拨：

1. 业务代码层重构，这个一般是由于以前的老业务代码设计的不合理，导致修改起来困难，这个场景一般我们会在新的功能要修改到老业务代码时，顺手完成对老业务代码的重构，如果一直不会修改到老代码，我们可以考虑先不先进此部分业务的重构
2. 架构层面的重构，这个一般是google或者其它开发者开源了一些新的架构模式，如新出现了MVP，MVVM等架构，需要我们去重构代码，以适配新的架构模式
3. 技术方案的重构，这个一般是有一些新的技术点出现，需要替代我们的老的技术，如出现了新的OKHttp库，需要替换掉我们老的网络库实现方案

发散思维，大家还能想到什么导致重构发生的场景，不要害怕重构，代码写出来就不会是一成不变的，欢迎大家在我们的课程分享区分享自己认为会发生重构的一些场景。