前言

一直都对重构有一种迷思：重构是很高大上的事情。由于拖延症以及没有合适的时间节点，所以一直都没有接触过重构。最近公司项目上针对预定类的功能进行了一次重构，趁着这个机会，我也参与了其中两个功能的重构。

重构的目的

重构的原因很明显：代码结构混乱、逻辑混乱以及在新需求面前无法拓展。目的也很明显：代码分层，增强拓展性。就这次 Bus 和 Hotel 来说，第一点就是把 SharedPreferences 改为 Database 存储；第二点是把 Agent 轻量化。

重构工作流

梳理→重构。梳理很重要！因为你即将要动原来的代码，所以最好是把现有的代码先整体梳理一遍，在哪些地方被调用了，调用了哪些地方。最好也进行功能梳理。因为重构完之后，功能必然是要和原来的保持一致，你不能重构后引入了新的问题，那还不如不重构了。最后把梳理的成果文档化。文档化是我比较推崇的，因为一方面别的同事可以直接查看文档而不需要时常打断你的工作；一方面以后自己也可以进行回顾。不要太高估自己的对代码的记忆，过了那么一、两个月，即使是自己写的代码也不可能完全记得。

重构过程

首先把 Agent 的代码分层。Agent 是作为卡片功能的一个总控者，它只需要管控流程，具体的实现要分开到不同的类中进行（单一职责原则）。把设置 Schedule 的逻辑单独成类；把一些工具方法也单独放在一个类中；数据存储的操作也放在一个单独的类中，只暴露接口供别人调用。

一些坑点

因为旧版本是以 SP 存储数据，所以重构后就涉及到数据迁移；因为数据格式变化了，所以重构后就涉及到讲原来的功能按照新的数据格式进行重置，在用户直觉上要保持跟之前一致（卡片重弹）。 重构后要考虑旧版本的一些遗留的东西，做好异常捕捉以及处理。典型的情况是：旧版本已经设置了 schedule 到系统中，那么升级到重构后的新版本，由于格式以及逻辑变更了，是否会存在问题？遇到的一个情况就是：对字符串的转换操作，新逻辑可能要对字符串进行数字转化（或其他操作），那么这个转化操作是否会被旧版本触发？旧版本的数据是否引出一个转换（或其他）异常？

总结

  这次重构总的来说，成果还是有的。最主要是进行了一次尝试，收获还是挺大的。重构的难度比新写的需求难度大，因为还要看原来的代码，一般不能直接把原来的干掉。这是一次小重构，以后继续进行大重构。另外不要为了重构而重构。