阅读 35

重构:高手的姿势你学不会

软件开发是一门工程技术,其中任何一个技术或技能如果孤立地看都会是管中窥豹,只见一斑。任何一个作者在写书时都有一些前提和细节,然而经常是要不作者没说清楚,要不读者直奔主题而忽略了这些前提和细节,结果是东施效颦,适得其反,照猫画虎不成反类犬。

我在和很多人交流重构的时候发现,大家非常注重重构的结果,即重构前后的代码是什么样的,但会忽略重构的姿势。

高手重构的姿势

老马在书中强调频繁且小步地进行重构:"犯错误是很容易的,至少我很容易犯错误……重构技术是以微小的步伐修改程序,如果你犯下错误,很容易便可发现……真的犯错后,只考虑一个很小的改动范围,这使得查错和修复问题易如反掌,如果我改动了太多的东西,犯错时就可能陷入麻烦的调试,并为此耗费大把时间。小步修改,以及它带来的频繁的反馈,正是防止混乱的关键“。

这个重构的过程可以用下图表示:

"这就是重构过程的精髓所在,小步修改,每次修改后就运行测试"

然而,我们大部分人做不到。

不是我们做不到小步修改。

是我们做不到每次修改后就运行测试。准确的说是无法做到每次修改后运行充分的测试,这成本太高了。要做到这一点,除非修改部分的代码有充分的自动化单元测试代码覆盖。然而,我见过的大部分工程中,单测代码少的可怜。所以,我们的重构过程可能是这样的:

由于测试成本太高,导致以下两个问题:

重构的步子变大,这样可以少测试几次,但步子大了,容易累积错误,修改错误变得困难

更可怕的是步子大了,累积的错误也多,有些错误不容易及时发现,会在某个节点暴雷,如果是提测后上线前还算幸运,但如果是在上线后暴雷,重构的罪过就大了

所以,结论是,对一般人来说,重构非常危险。

给普通人的建议

如果做不到自动化单元测试覆盖,但为了避免危险,建议就是:不要对已经上线的代码进行重构,甚至,时间点再提前一点,不要在测试之后去重构。

写一段新的代码的时候,很难一开始就把代码写的很整洁,所以先怎么舒服怎么写,写的差不多了,能跑通了,这时候,先不要去做全面的人工测试,先去重构,先去整理代码,整理完后,在做全面的人工测试。这样可以省下人工回归测试的成本。

这是对一般开发人员最实用的重构姿势。按理想的重构姿势做,软件原有功能很少被破坏,所以有非常多的时机做重构,这来源于自动化测试的保障以及这种保障下的小步修改,这些是"防止混乱的关键";但对于实用的重构姿势,你安全重构的机会只有测试前的这一次。所以,要无比珍惜

除了这种安全的重构的时机,还有一些相对比较安全的重构,如果你的情怀能支撑你冒一点风险的话。

比如修改一个线上BUG的时候。

首先,有时候重构有助于你改BUG。你根本看不懂那个BUG所处的"屎山"一样的代码块,俗称"不敢改",在修复BUG前重构一下可能会帮助你读懂它,然后你稍微变的敢改了。

其次,由于改一个线上BUG引入的新的BUG后果并不严重,我说的不是对系统来说不太严重,而是说对改BUG的人。大多数管理者能容忍这种改BUG引入的BUG,但难以容忍只为了改善代码可读性而引入的BUG。

最后,你改完BUG,总得回归测试一下吧,包括你自己,包括测试人员。如果引入了新的BUG,测试人员也能承担一部分责任。

不是教你学坏,实在是没有办法,除非你不介意在"屎山"上再贡献一些自己的力量。这种相对比较安全的重构孰是孰非,难以说清,我个人既不赞成也不反对。

大家还是用好唯一的那一次安全重构的机会吧。

取法乎上得乎其中

我是一个叶公好龙式的书法爱好者,我经常会照着字帖去临摹,但一直无法达到专业的水准。

有一次我看到老师教孩子写隶书,讲的是"蚕头燕尾" 笔法,一个笔画被拆的特别细,完全是一个技术活,没有一点写字的乐趣。但我从中明白了我无法达到专业的水准的原因。

但知道和做到还是有一段距离的,我依然无法静下心练这些笔法,我还是喜欢随意地按字帖去临摹。

我知道永远也达不到专业的水准了,但这些临摹确实让我的字变得比以前好看了。

对于大部分人来说,重构也是这样。

取法乎上得乎其中。

读者福利:

分享免费学习资料

针对于还会准备免费的Java架构学习资料(里面有高可用、高并发、高性能及分布式、Jvm性能调优、MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料) 为什么某些人会一直比你优秀,是因为他本身就很优秀还一直在持续努力变得更优秀,而你是不是还在满足于现状内心在窃喜!希望读到这的您能点个小赞和关注下我,以后还会更新技术干货,谢谢您的支持!

资料领取方式:加入Java技术交流群963944895,私信管理员即可免费领取

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