高手重构的姿势
=======
老马在书中强调频繁且小步地进行重构:"犯错误是很容易的,至少我很容易犯错误……重构技术是以微小的步伐修改程序,如果你犯下错误,很容易便可发现……真的犯错后,只考虑一个很小的改动范围,这使得查错和修复问题易如反掌,如果我改动了太多的东西,犯错时就可能陷入麻烦的调试,并为此耗费大把时间。小步修改,以及它带来的频繁的反馈,正是防止混乱的关键“。
这个重构的过程可以用下图表示:
“这就是重构过程的精髓所在,小步修改,每次修改后就运行测试”。
然而,我们大部分人做不到。
不是我们做不到小步修改。
是我们做不到每次修改后就运行测试。准确的说是无法做到每次修改后运行充分的测试,这成本太高了。要做到这一点,除非修改部分的代码有充分的自动化单元测试代码覆盖。然而,我见过的大部分工程中,单测代码少的可怜。所以,我们的重构过程可能是这样的:
由于测试成本太高,导致以下两个问题:
重构的步子变大,这样可以少测试几次,但步子大了,容易累积错误,修改错误变得困难
更可怕的是步子大了,累积的错误也多,有些错误不容易及时发现,会在某个节点暴雷,如果是提测后上线前还算幸运,但如果是在上线后暴雷,重构的罪过就大了
所以,结论是,对一般人来说,重构非常危险。
给普通人的建议
=======
如果做不到自动化单元测试覆盖,但为了避免危险,建议就是:不要对已经上线的代码进行重构,甚至,时间点再提前一点,不要在测试之后去重构。
写一段新的代码的时候,很难一开始就把代码写的很整洁,所以先怎么舒服怎么写,写的差不多了,能跑通了,这时候,先不要去做全面的人工测试,先去重构,先去整理代码,整理完后,在做全面的人工测试。这样可以省下人工回归测试的成本。
这是对一般开发人员最实用的重构姿势。按理想的重构姿势做,软件原有功能很少被破坏,所以有非常多的时机做重构,这来源于自动化测试的保障以及这种保障下的小步修改,这些是"防止混乱的关键";但对于实用的重构姿势,你安全重构的机会只有测试前的这一次。所以,要无比珍惜。
除了这种安全的重构的时机,还有一些相对比较安全的重构,如果你的情怀能支撑你冒一点风险的话。
比如修改一个线上BUG的时候。
最后
本人也收藏了一份Java面试核心知识点来应付面试,借着这次机会可以送给我的读者朋友们:
目录:
Java面试核心知识点
一共有30个专题,足够读者朋友们应付面试啦,也节省朋友们去到处搜刮资料自己整理的时间!
Java面试核心知识点
足够读者朋友们应付面试啦,也节省朋友们去到处搜刮资料自己整理的时间!**
[外链图片转存中…(img-ILfFK88I-1714813548175)]
Java面试核心知识点