何时重构？重构可以随时进行，只要你有足够的时间和精力去做。大多数公司重构代码都不会计入KPI，甚至重构越多，出现bug的概率就越大，被指责的可能性就越大。因此，你负责的功能的小规模重构或重构，可以穿插需求；大规模重构耗时长，出错概率高，必须得到上级支持才能进行。大规模重构的需求来源一般是因为当前的技术架构已经不能满足业务的快速迭代，可维护性差，新人上手困难，出现bug的概率增加。当代码到了这个层次，就要推进大规模的重构。重构。需要明确重构的原则，重构不是重写，更不是解决bug和引入新的需求。很多新手在重构的时候，往往会在重构的过程中修改之前固有的逻辑，甚至加入一些自己的业务理解来“优化”已有的代码。这是一个很大的错误，所以重构的首要原则是：“忠于原代码”，尤其是当你看不懂之前的业务时，尽量忠于原文，这样可以减少新bug的产生和增强可测试性。重构的第二个原则：“分步实施”。尽量不要一下子推翻重建。尽可能从底层提取共性，将目标从点到面分解，分步实施；例如，如果要重新评估当前代码的整体MVP，可以明确当前业务，分析核心业务，从最简单的业务开始，保留原有结构，逐渐兼容，再逐步精简甚至去掉之前的代码。重构的第三条原则：“简洁逻辑而非代码缩减”。重构的最终目的是为了符合软件工程中的单一责备和开闭原则。代码行数不是关键。如何理清逻辑，最重要的是后续维护方便，学习成本低。很多人把“从XXX线到XX线”作为重构的目标。线路数量的减少是衡量指标之一，但绝不是最重要的指标。比如引入RxJava可能会增加代码量，但是逻辑更清晰，添加功能也更容易。这是成功的重构。重构的另一个原则是：“合适的才是最好的”。许多人重构代码来炫耀自己的技能。一旦给他们重构代码的机会，他们就像一匹脱缰的野马，介绍了很多不熟悉的东西，觉得这是学习的好机会，一旦出了问题，就解决不了了。怎么才算合适呢？在我看来，一个合适的架构必须具备以下特点：学习成本低，新手容易上手，市场资料多；不会过度设计，但易于扩展，也方便日后切换到新的架构；不要过度耦合；前两点比较好理解，第三点怎么理解？代码写久了，你就会明白一个规律：“代码逻辑守恒定律”，就是无论你怎么设计架构，代码逻辑都不会减少是的，如果逻辑减少在一个一个地方，必须增加另一个地方的逻辑。解耦就是你把不属于这个业务的逻辑转移到另一个地方。过度的解构，要么把很多模块分割开来，要么把相应的业务放在一个“看不见”的地方。如果“看不到”太多，发现问题会很麻烦，比如Java中的注解太多，或者编译时的注解太多。过度的解耦实际上隐藏了不必要的隐藏逻辑，对调用者是完全透明的。问题的跟踪会在透明层被截断，从而导致问题。如何实施重构参与重构的人数不宜太多，两三个人为宜；功能不能分散，至少每个人重构一个业务功能模块或功能点，这样可以更好的降低沟通成本。大规模重构应该自下而上，明确要实现的目标，从底层逻辑入手，逐步向上层移动。比如Android中之前代码的重构，应该从模块开始，然后是组件，再逐步到具体的业务，这样才能保证重构全程的一致性。重构前，需要对要实现的重构目标做出评估，是完成重构，还是只需要梳理关键业务，还是需要梳理一个模板，然后分布式实现.不同的目标对应不同的方法和不同的工作量；重构前，需要梳理当前的关键业务，明确周边的支撑组件和必须推进的工作量。比如某次重构：目标：完成所有业务模块的MVP重构关键业务：打车、订单管理、地图效果模块提取（module1/moduel2...）基础组件推送/IM网络支付...规格预估的时间是30天/1人围绕关键业务进行设计，关键流程设计好了，重构就成功了一半。在重构中，还有一个基本的问题：编码标准的问题；编码标准应该使用的工具是最规范的。sonar/lint之类的工具可以自动识别和提醒，所以不要在上面浪费太多时间。
