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