趣图 | 代码重构前vs代码重构后

前言

今天跟大家聊一下关于代码重构的话题。

话说，很多程序员对自己写的代码平时很随心所欲(各种魔法变量，一个方法几十上百行代码，还有各种让人崩溃的变量或方法命名)。

当有一天让他维护他人的代码，他就会抓狂，很容易激发他体内重构的瘾。（大多数程序员审阅完别人代码后，先会忍不住吐槽一番，然后会忍不住想重构一把，😂）

在我看来，重构本身是一件值得肯定的事，但有个前提，一定不能影响原先业务功能！

不能因为重构了之后，原来好好的功能反而出问题了，甚至还影响了其他功能，那你这不是重构，是制造问题者。

这里我分享三个关于重构的小技巧，希望日后小伙伴能谨慎的对待“重构”这件事，避免因为重构导致线上事故发生。

重构三技巧

x 一、结构化你的代码

大家看下下面截图assembleOffer这个方法，一个方法内部有很多段代码，比如1.核心商品信息代码片段，2.产品属性信息片段等等。

这样的方法，因为内部需要执行很多件事情，统一完成后，这个大方法才算真正完成。

那么现在问题来了，几十、上百行代码都集中在一个大方法内部，这样的方法显得太过混乱，最终导致”爆炸“的情况发生，以后维护成本也会成倍增加。

那如果你能用结构化思维梳理一下你的代码，然后重新组织如下：

将一个大方法内部的代码拆分成多个有明确意义的小方法，然后将它们组装在一起，这样的方法就会清晰很多，以后维护起来也会很方便，甚至有一定的复用性。

上述内容摘自 阿里高级技术专家张建飞的著作：《程序员的底层思维》一书，里面有众多他发现、总结、提炼的程序员底层思维，这些思维是真正意义上能帮助我们程序员提高编程能力和软件架构、设计能力的，建议大家花点时间认真阅读，如有需要电子书，在我的公众号后台回复“思维”即可免费获取。

x 二、单测

重构完后，一定一定要记得单测。可千万别过分自信，觉得说自己没修改多少多少代码，然后就强制发布上线。

这种因为轻视或过分自信，在不自测的情况下，强制上线的生产事故，这两年还少吗。

所以经过充分的单测，才能保障你写的代码质量稳健。

最后，如果有条件，我建议你用账号登陆你的应用，去使用一下你重构后的功能，看它是否表现正常，就当全链路验证了。

关于发布，这里提醒一下：如果你此次改动内容比较多，比如新增了数据库表的字段、新增了配置中心新的选项等，建议大家提前准备一份发布计划，大致内容如下：

发布前，每执行完一项，就标注一下Done。这样一路下去，直到最后一项任务的完成。

这样能帮助你因为发布的内容过多，避免丢三落四的情况，最终导致发布失败，需要二次发布。

最后成功发布后，一定记得仔细按照刚我跟大家说的，验证一下你发布的功能。当然也要留意一下其他功能特别是主流功能的日志，观察是否正常打印，千万别因你的发布影响到了其他功能。

x 三、对修改关闭，对新增开放

大家如果在重构的时候，面对被修改的代码，其多个地方引用，这个时候一定要小心了，很有可能你改了某一处，但影响了其他功能代码。

这里我有一个建议：不要去修改这种被多个地方引用的代码，你可以新增一个方法：比如重载一个新方法，供你这次的功能调用。然后你在这段新方法内部去重构，这样你的更改，一定不会影响其他功能。