文章目录
一. 重构概述
重构的要求:
一方面,重构代码对一个工程师能力的要求,要比单纯写代码高得多。重构需要你能洞察出代码存在的坏味道或者设计上的不足,并且能合理、熟练地利用设计思想、原则、模式、编程规范等理论知识解决这些问题。
另一方面,很多工程师对为什么要重构、到底重构什么、什么时候重构、又该如何重构等相关问题理解不深,对重构没有系统性、全局性的认识,面对一堆烂代码,没有重构技巧的指导,只能想到哪改到哪,并不能全面地改善代码质量。
1. 为什么要重构(why)?
重构定义:
这个定义中有一个值得强调的点:“重构不改变外部的可见行为”。
为什么要进行代码重构?
- 首先,重构是时刻保证代码质量的一个极其有效的手段。
- 其次,优秀的代码或架构不是一开始就能完全设计好的,就像优秀的公司和产品也都是迭代出来的。我们无法 100% 遇见未来的需求,也没有足够的精力、时间、资源为遥远的未来买单,所以,随着系统的演进,重构代码也是不可避免的。
- 最后,重构是避免过度设计的有效手段。在我们维护代码的过程中,真正遇到问题的时候,再对代码进行重构,能有效避免前期投入太多时间做过度的设计,做到有的放矢。
2. 到底重构什么(what)?
根据重构的规模,我们可以笼统地分为大规模高层次重构(以下简称为“大型重构”)和小规模低层次的重构(以下简称为“小型重构”)。
大型重构
大型重构指的是对顶层代码设计的重构,包括:系统、模块、代码结构、类与类之间的关系等的重构,重构的手段有:分层、模块化、解耦、抽象可复用组件等等。
这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多,影响面会比较大,所以难度也较大,耗时会比较长,引入 bug 的风险也会相对比较大。
小型重构
小型重构指的是对代码细节的重构,主要是针对类、函数、变量等代码级别的重构,比如规范命名、规范注释、消除超大类或函数、提取重复代码等等。
小型重构更多的是利用我们能后面要讲到的编码规范。这类重构要修改的地方比较集中,比较简单,可操作性较强,耗时会比较短,引入 bug 的风险相对来说也会比较小。你只需要熟练掌握各种编码规范,就可以做到得心应手。
3. 什么时候重构(when)?
提倡的重构策略是持续重构。
就像把单元测试、Code Review 作为开发的一部分,我们如果能把持续重构也作为开发的一部分,成为一种开发习惯,对项目、对自己都会很有好处。
4. 该如何重构(how)?
每个阶段,要控制好重构影响到的代码范围,考虑好如何兼容老的代码逻辑,必要的时候还需要写一些兼容过渡代码。只有这样,我们才能让每一阶段的重构都不至于耗时太长(最好一天就能完成),不至于与新的功能开发相冲突。
5. 如何保证重构不出错?
最可落地执行、最有效的保证重构不出错的手段应该就是单元测试(Unit Testing)了。当重构完成之后,如果新的代码仍然能通过单元测试,那就说明代码原有逻辑的正确性未被破坏,原有的外部可见行为未变,符合我们对重构的定义。
二. 单元测试方法论
1. 什么是单元测试?
单元测试相对于集成测试(Integration Testing)来说,测试的粒度更小一些。
- 集成测试的测试对象是整个系统或者某个功能模块,比如测试用户注册、登录功能是否正常,是一种端到端(end to end)的测试。
- 单元测试的测试对象是类或者函数,用来测试一个类和函数是否都按照预期的逻辑执行。这是代码层级的测试。
写单元测试本身不需要什么高深技术。它更多的是考验程序员思维的缜密程度,看能否设计出覆盖各种正常及异常情况的测试用例,来保证代码在任何预期或非预期的情况下都能正确运行。
举例
publicclassText{privateString content;publicText(String content){this.content = content;}/**
* 将字符串转化成数字,忽略字符串中的首尾空格;
* 如果字符串中包含除首尾空格之外的非数字字符,则返回null。
*/publicIntegertoNumber(){if(content ==null|| content.isEmpty()){returnnull;}//...省略代码实现...returnnull;}}
我们需要设计下面这样几个测试用例。
当我们设计好测试用例之后,剩下的就是将其翻译成代码了。
public class Assert {
public staticvoidassertEquals(Integer expectedValue, Integer actualValue){if(actualValue != expectedValue){
String message = String.format("Test failed, expected: %d, actual: %d.", expectedValue, actualValue);
System.out.println(message);}else{
System.out.println("Test succeeded.");}}
public static boolean assertNull(Integer actualValue){
boolean isNull = actualValue == null;if(isNull){
System.out.println("Test succeeded.");}else{
System.out.println("Test failed, the value is not null:"+ actualValue);}return isNull;}}
public class TestCaseRunner {
public staticvoidmain(String[] args){
System.out.println("Run testToNumber()");
new TextTest().testToNumber();
System.out.println("Run testToNumber_nullorEmpty()");
new TextTest().testToNumber_nullorEmpty();
System.out.println("Run testToNumber_containsLeadingAndTrailingSpaces()");
new TextTest().testToNumber_containsLeadingAndTrailingSpaces();
System.out.println("Run testToNumber_containsMultiLeadingAndTrailingSpaces()");
new TextTest().testToNumber_containsMultiLeadingAndTrailingSpaces();
System.out.println("Run testToNumber_containsInvalidCharaters()");
new TextTest().testToNumber_containsInvalidCharaters();}}
public class TextTest {
public voidtestToNumber(){
Text text = new Text("123");
Assert.assertEquals(123, text.toNumber());}
public voidtestToNumber_nullorEmpty(){
Text text1 = new Text(null);
Assert.assertNull(text1.toNumber());
Text text2 = new Text("");
Assert.assertNull(text2.toNumber());}
public voidtestToNumber_containsLeadingAndTrailingSpaces(){
Text text1 = new Text(" 123");
Assert.assertEquals(123, text1.toNumber());
Text text2 = new Text("123 ");
Assert.assertEquals(123, text2.toNumber());
Text text3 = new Text(" 123 ");
Assert.assertEquals(123, text3.toNumber());}
public voidtestToNumber_containsMultiLeadingAndTrailingSpaces(){
Text text1 = new Text(" 123");
Assert.assertEquals(123, text1.toNumber());
Text text2 = new Text("123 ");
Assert.assertEquals(123, text2.toNumber());
Text text3 = new Text(" 123 ");
Assert.assertEquals(123, text3.toNumber());}
public voidtestToNumber_containsInvalidCharaters(){
Text text1 = new Text("123a4");
Assert.assertNull(text1.toNumber());
Text text2 = new Text("123 4");
Assert.assertNull(text2.toNumber());}}
2. 为什么要写单元测试?
2.1.单元测试能有效地帮你发现代码中的 bug
在离开 Google 之后,尽管我就职的很多公司,其开发模式都是“快、糙、猛”,对单元测试根本没有要求,但我还是坚持为自己提交的每一份代码,都编写完善的单元测试。得益于此,我写的代码几乎是 bug free 的。这也节省了我很多 fix 低级 bug 的时间,能够有时间去做其他更有意义的事情,我也因此在工作上赢得了很多人的认可。可以这么说,坚持写单元测试是保证我的代码质量的一个“杀手锏”,也是帮助我拉开与其他人差距的一个“小秘密”。— 王争
2.2. 写单元测试能帮你发现代码设计上的问题
前面我们提到,代码的可测试性是评判代码质量的一个重要标准。对于一段代码,如果很难为其编写单元测试,或者单元测试写起来很吃力,需要依靠单元测试框架里很高级的特性才能完成,那往往就意味着代码设计得不够合理,比如,没有使用依赖注入、大量使用静态函数、全局变量、代码高度耦合等。
2.3. 单元测试是对集成测试的有力补充
- 程序运行的 bug 往往出现在一些边界条件、异常情况下,比如,除数未判空、网络超时。而大部分异常情况都比较难在测试环境中模拟。而单元测试可以利用mock 的方式,控制 mock 的对象返回我们需要模拟的异常,来测试代码在这些异常情况的表现。
- 除此之外,对于一些复杂系统来说,集成测试也无法覆盖得很全面。复杂系统往往有很多模块。每个模块都有各种输入、输出、异常情况,组合起来,整个系统就有无数测试场景需要模拟,无数的测试用例需要设计,再强大的测试团队也无法穷举完备。
2.4. 写单元测试的过程本身就是代码重构的过程
设计和实现代码的时候,我们很难把所有的问题都想清楚。而编写单元测试就相当于对代码的一次自我 Code Review,在这个过程中,我们可以发现一些设计上的问题(比如代码设计的不可测试)以及代码编写方面的问题(比如一些边界条件处理不当)等,然后针对性的进行重构。
2.5. 阅读单元测试能帮助你快速熟悉代码
在没有文档和注释的情况下,单元测试就起了替代性作用。单元测试用例实际上就是用户用例,反映了代码的功能和如何使用。借助单元测试,我们不需要深入的阅读代码,便能知道代码实现了什么功能,有哪些特殊情况需要考虑,有哪些边界条件需要处理。
2.6. 单元测试是 TDD 可落地执行的改进方案
单元测试是对 TDD (测试驱动开发)的一种改进方案,先写代码,紧接着写单元测试,最后根据单元测试反馈出来问题,再回过头去重构代码。这个开发流程更加容易被接受,更加容易落地执行,而且又兼顾了 TDD 的优点。
3. 如何编写单元测试?
写单元测试就是针对代码设计覆盖各种输入、异常、边界条件的测试用例,并将这些测试用例翻译成代码的过程。
利用单元测试框架,来简化测试代码的编写。
针对 toNumber() 函数的测试用例,我们利用 Junit 单元测试框架重新实现。
importorg.junit.Assert;importorg.junit.Test;publicclassTextTest{@TestpublicvoidtestToNumber(){Text text =newText("123");Assert.assertEquals(newInteger(123), text.toNumber());}@TestpublicvoidtestToNumber_nullorEmpty(){Text text1 =newText(null);Assert.assertNull(text1.toNumber());Text text2 =newText("");Assert.assertNull(text2.toNumber());}@TestpublicvoidtestToNumber_containsLeadingAndTrailingSpaces(){Text text1 =newText(" 123");Assert.assertEquals(newInteger(123), text1.toNumber());Text text2 =newText("123 ");Assert.assertEquals(newInteger(123), text2.toNumber());Text text3 =newText(" 123 ");Assert.assertEquals(newInteger(123), text3.toNumber());}@TestpublicvoidtestToNumber_containsMultiLeadingAndTrailingSpaces(){Text text1 =newText(" 123");Assert.assertEquals(newInteger(123), text1.toNumber());Text text2 =newText("123 ");Assert.assertEquals(newInteger(123), text2.toNumber());Text text3 =newText(" 123 ");Assert.assertEquals(newInteger(123), text3.toNumber());}@TestpublicvoidtestToNumber_containsInvalidCharaters(){Text text1 =newText("123a4");Assert.assertNull(text1.toNumber());Text text2 =newText("123 4");Assert.assertNull(text2.toNumber());}}
关于如何编写单元测试,具体包括以下几点。
- 写单元测试真的是件很耗时的事情吗? 尽管单元测试的代码量可能是被测代码本身的 1~2 倍,写的过程很繁琐,但并不是很耗时。毕竟我们不需要考虑太多代码设计上的问题,测试代码实现起来也比较简单。不同测试用例之间的代码差别可能并不是很大,简单 copy-paste 改改就行。
- 对单元测试的代码质量有什么要求吗? 单元测试毕竟不会在产线上运行,而且每个类的测试代码也比较独立,基本不互相依赖。所以,相对于被测代码,我们对单元测试代码的质量可以放低一些要求。命名稍微有些不规范,代码稍微有些重复,也都是没有问题的。
- 单元测试只要覆盖率高就够了吗? 单元测试覆盖率是比较容易量化的指标,常常作为单元测试写得好坏的评判标准。有很多现成的工具专门用来做覆盖率统计,比如,JaCoCo、Cobertura、Emma、Clover。覆盖率的计算方式有很多种,比较简单的是语句覆盖,稍微高级点的有:条件覆盖、判定覆盖、路径覆盖。
- 写单元测试需要了解代码的实现逻辑吗? 单元测试只关心被测函数实现了什么功能。我们切不可为了追求覆盖率,逐行阅读代码,然后针对实现逻辑编写单元测试。否则,一旦对代码进行重构,在代码的外部行为不变的情况下,对代码的实现逻辑进行了修改,那原本的单元测试都会运行失败,也就起不到为重构保驾护航的作用了,也违背了我们写单元测试的初衷。
- 如何选择单元测试框架? 写单元测试本身不需要太复杂的技术,大部分单元测试框架都能满足。在公司内部,起码团队内部需要统一单元测试框架。
单元测试质量标准
不管覆盖率的计算方式如何高级,将覆盖率作为衡量单元测试质量的唯一标准是不合理的。实际上,更重要的是要看测试用例是否覆盖了所有可能的情况,特别是一些 corner case。
如下代码,只需要一个测试用例就可以做到 100% 覆盖率,比如 cal(10.0, 2.0),但并不代表测试足够全面了,还需要考虑当除数等于0的情况下,代码执行是否符合预期。
publicdoublecal(double a,double b){if(b !=0){return a / b;}}
从过往的经验上来讲,一个项目的单元测试覆盖率在 60~70% 即可上线。如果项目对代码质量要求比较高,可以适当提高单元测试覆盖率的要求。
《设计模式之美》-- 王争
版权归原作者 roman_日积跬步-终至千里 所有, 如有侵权,请联系我们删除。