转载

码妞：领导让我重构代码，怎么办？

什么时候进行重构?

码妞：领导让我重构代码，怎么办？

任何时间都可以进行重构，前提是你有足够的时间以及精力去做这件事情，大部分公司重构代码是不会计入KPI的，甚至重构的越多，出bug的概率就越大，背锅的可能就越大。因此，小规模的重构或者自己负责功能的重构，可以穿插在需求中进行;大规模重构因为耗费时间较长，出错概率较高，必须要得到上级的支持才能进行下去。

大规模重构的需求来源一般都是因为目前技术架构已经不能满足快速的业务迭代，可维护性差，新人上手困难，出现bug几率增加，当代码已经到达这个程度的时候，就需要推进进行大规模重构了。

重构的原则

码妞：领导让我重构代码，怎么办？

需要理清楚的是重构不是重写，更不是解决bug，引入新需求。很多新手在进行重构的时候，往往会在重构过程中去修改之前的固有逻辑，甚至增加一些自己的业务理解去“优化”现有的代码，这是大错特错的，因此重构的第一个原则是：“忠于原代码”，特别是在自己无法理解之前业务的下，尽量忠于原文，可以减少产生的新的bug，可测性增强。

码妞：领导让我重构代码，怎么办？

重构的第二个原则：“逐步实施”。尽量不要一下子就推翻重建，应该从尽量底层去抽取共性，由点及面，分解目标，逐步实施;比如你要对当前代码做整体的MVP重估，这个时候你可以先把当前业务理清楚，分析核心业务，从最简单的业务入手，保留原有的结构，逐步兼容，然后慢慢把之前的代码精简掉甚至移除。

码妞：领导让我重构代码，怎么办？

重构的第三个原则：“简洁逻辑而非减少代码”，重构最终的目标是需要符合软件工程中单一指责以及开闭原则的，代码行数的多少不是关键，怎么理清楚逻辑，让后续维护方便，入手学习成本低才是最关键的。很多人以“从XXX行到XX行”为重构的目标，行数的减少是衡量指标之一，但绝不是最重要的指标。比如RxJava的引入，可能会增加代码量，但是逻辑更清晰了，增加功能更容易了，这就是成功的重构。

码妞：领导让我重构代码，怎么办？

重构的另外一个原则就是：“合适的才是最好的”，很多人重构代码就是炫技，一旦给他重构代码的机会，就如脱缰野马，引入大量自己并不熟悉的框架进行，觉得这是一个学习的好机会，一旦出现问题就无法解决。怎么就算合适了，在我看来，合适的架构一定是以下几个特征：

学习成本低，新人入手容易，市场上资料多;
不过度设计，但是又容易扩展，以后换成新架构也方便;
不要过度结耦;

前面两点比较容易理解，第三点怎么理解呢?写代码久了，就会明白一个定律：“代码逻辑守恒定律”，就是无论你怎么设计架构，代码逻辑是不会减少的，一个地方逻辑减少了，就一定会在另一个地方逻辑增加。解偶就意味着，你把不属于这一块业务的逻辑转移到另外一个地方，过度解构要么是划分了很多个模块，要么就是把对应的业务放在了“看不到”的地方，当“看不到”多了以后，就会造成查找问题非常麻烦，比如过多的在Java使用注解或者编译时注解。过度解偶其实就是隐藏了不必要隐藏的逻辑，对调用者完全透明，问题的追踪就会在透明层被截断，从而导致问题的产生。