阅读 53

工作中重构小总结

前言

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

重构的目的

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

重构工作流

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

重构过程

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

一些坑点

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

总结

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

关注下面的标签,发现更多相似文章
评论