洪流学堂,让你快人几步。
本篇内容来自洪流读书会精选内容。
前面我们已经知道了重构是什么、为什么应该重构、选择何时何处进行重构这三个问题,今天我们来解决第四个问题:如何着手进行重构?
重构前我们需要哪些准备工作?
重构前,先检查自己是否有一套可靠的测试集,这些测试必不可少,因为尽管遵循重构手法可以使我们避免绝大多数引入bug的情形,但程序员毕竟是人,是人就有可能犯错。程序越大,在修改中不小心破坏其它代码的可能性就越大。在数字时代,软件本身即是强大和脆弱的矛盾体。
测试过程中重要的是测试程序对于结果的报告方式。通常它们要么变红,要么变绿,变红的就列出失败清单以显示问题出现的型号。注意测试本身需要自我检验的能力,这样能节约很多进行代码比对的时间。目前的测试框架都提供支持编写和运行能够自检的测试,这样还是能节省很多时间的。
构建测试集的4个关键注意事项
第一 要注意自我测试代码的价值
确保所有测试都完全自动化,让他们检查自己的测试结果。一套测试就是一个强大的bug侦测器,能够大大缩减查找bug所需的时间。
第二 要注意测试频率
当我为类似的既有代码编写测试时,发现一切正常工作固然是好,但我天然持怀疑精神。特别是有很多测试运行时,我总会担心测试没有按我期望的方式检查结果,从而没办法在世界出错的时候抓到bug。
频繁的运行测试,对于你正在处理的代码,与其对应的测试至少每隔几分钟就要运行一次,每天至少运行一次所有的测试。一个真实的系统可能拥有数千个测试。好的测试框架应该能帮我简单快速地运行这些测试,一旦出错,我能马上看到。尽管这种反馈非常简单,但对于自测试代码频繁的运行测试,要么是检验新代码的进展,要么是检查重构过程是否出错。
第三 测试边界条件
前面的测试都聚焦于正常行为上,与此同时把测试推到这些条件的边界处也是不错的实践,这可以检查操作出错时软件的表现。考虑可能出错的边界条件,把测试火力集中在那儿。
比如当我拿到一个集合,我总想看看集合为空时会发生什么;如果是数值类型,0会是不错的边界条件。
不要因为测试无法捕捉所有的bug就不写测试,因为测试的确可以捕捉到大多数bug。
第四 测试的深度
一个常见的问题是,“要写多少测试才算足够?”这个问题没有很好的衡量标准。有些人拥护以测试覆盖率作为指标,但测试覆盖率的分析只能识别出那些未被测试覆盖的代码,而不能用来衡量一个测试集的质量高低。
一个测试集是否足够好,最好的衡量标准其实是主观的,请你试问自己;如果有人在代码里引入了一个缺陷,你有多大的自信它能被测试集揪出来?这种信心难以被定量分析,盲目自信不应该在内,但自测试代码的全部目标,就是要帮你获得此种信心。如果我重构完代码,看见全部变绿的测试就可以十分自信没有引入额外的bug,这样我就可以高兴地说,我已经有了一套足够好的测试。
测试同样可能过犹不及。测试写得太多的一个征兆是,相比要改的代码,我在改动测试上花费了更多时间——并且我能感到测试在拖慢我。不过尽管过度测试时有发生,相比测试不足的情况还是少得多。
总结
至此我们将马丁福勒的这本《重构-改善既有代码的设计》(第2版)解读完毕。希望你可以鞭策自己以及整个团队:在一开始的时候,就不写或者少写那种味道很坏的代码。还应该激励自己,深入地理解架构、理解业务、理解需求,减少因设计失误而导致徒劳无益的反复重构。
扩展阅读
【扩展学习】在洪流学堂公众号回复
读书会
可以阅读本系列所有文章
我是大智(vx:zhz11235),你的技术探路者,下次见!
别走!点赞,收藏哦!
好,你可以走了。