普通程序员和厉害程序员的差距!

大家好,我是程序员陶朱公

前言

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

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

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

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

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

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

重构三技巧

、结构化你的代码

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

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

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

 

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

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

、单测

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

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

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

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

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

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

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

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

、对修改关闭,对新增开放

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

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

 

 


写到最后

感谢您一路陪伴着我,探索编程的奇妙世界。如果您对程序员职场进阶窍门、编程技巧和计算机原理等充满兴趣,那么不要错过未来我为大家奉上的精彩内容!点击关注,让您的程序员之旅更加丰富多彩,我们一同成长,一同前行!🚀💻📚
求一键三连点赞、转发、在看

推荐关注

最近在整理本地资料库的时候,发现工作多年,已陆续积累、收藏了近百本经典的计算机书籍,有计算机基础的,有编程语言的,有数据结构和算法的,有面试相关的,以下是具体资料(看看你的书架是否缺其中一本),有需要的小伙伴自行获取,点击👉:那些年,我书架上的几本经典计算机书籍!查看详情。
posted @ 2024-03-23 11:10  陶朱公Boy  阅读(185)  评论(0编辑  收藏  举报