谈谈代码重构

很久没写文章了，最近太忙了，诈个尸,刚好最近在代码重构，简单谈谈何时重构、重构的原则以及怎么实施去重构。

何时进行重构？

任什么时候间均可以进行重构，前提是你有足够的时间以及精力去作这件事情，大部分公司重构代码是不会计入KPI的，甚至重构的越多，出bug的几率就越大，背锅的可能就越大。所以，小规模的重构或者本身负责功能的重构，能够穿插在需求中进行；大规模重构由于耗费时间较长，出错几率较高，必需要获得上级的支持才能进行下去。大规模重构的需求来源通常都是由于目前技术架构已经不能知足快速的业务迭代，可维护性差，新人上手困难，出现bug概率增长，当代码已经到达这个程度的时候，就须要推动进行大规模重构了。

重构的原则

须要理清楚的是重构不是重写，更不是解决bug，引入新需求。不少新手在进行重构的时候，每每会在重构过程当中去修改以前的固有逻辑，甚至增长一些本身的业务理解去“优化”现有的代码，这是大错特错的，所以重构的第一个原则是：“忠于原代码”，特别是在本身没法理解以前业务的下，尽可能忠于原文，能够减小产生的新的bug，可测性加强。

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

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

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

• 学习成本低，新人入手容易，市场上资料多；
• 不过分设计，可是又容易扩展，之后换成新架构也方便；
• 不要过分结偶;

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

怎么实施重构

参与重构人数不宜过多，两三人为宜；功能不宜分散，至少每一个人应该要重构一个业务功能模块或者功能点，这样能够更好减小沟通成本。

大规模重构，应该从下至上，先理清晰要达到的目标，先从底层逻辑开始重构，逐步到上层。好比在Android中对以前代码的重构，应该是先模块，后组件，而后逐渐到具体业务，这样就能够保证整个过程当中重构的一致性。

在进行重构以前，须要对要达到的重构目标作一个评估，是要彻底重构完，仍是只须要对关键业务作梳理，亦或是须要整理出一个模版，而后分布实施。不一样的目标对应不一样的作法以及不一样的工做量；在重构以前还须要须要对当前关键业务作梳理，理清楚周边支撑组件和必需要提早的工做量。

好比，某一次重构：

• 目标：完成全部业务模块的MVP重构
• 关键业务：打车、订单管理、地图
• 效果
  • 模块抽取（module1/moduel2...）
  • 基础组件
    • 推送/IM
    • 网络
    • 支付
    • ...
  • 规范
• 预估时间 30天/1人

围绕关键业务设计，设计好了关键流程，重构就成功了一半。在重构中，还有一个比较基础问题就是：编码规范的问题；编码规范尽可能使用工具去最规范。相似于sonar/lint等工具作到自动识别，自动提醒，不要浪费太多时间在上面。

总结

快下班了，先写到这里吧，有什么能够在评论中探讨。