1.2 把错误关在笼子里的五道关卡

本文内容是极客时间课程——代码精进之路中代码规范篇的学习笔记。

 

1.人人都会犯错误

 

第一个比较普遍的观点是好的程序员不会写坏的代码；

这个观点一定程度上忽视了人类犯错误的复杂性，和影响因素的多样性；

 

第二个更加普遍的观点是同样的错误不能犯第二次；

这个观点应该是我们对自身的期望和要求；对于他人，我们可以更宽容；

对于一个团队，我们首先要思考如何提供一种机制，以减少此类错误的发生；

 

第三个深入人心的观点是一个人犯了错误并不可怕，怕的是承认错误；

一旦陷入自责的指责的漩涡，很多有建设意义的事情，我们可能没有意识去做；或者即使意识到了，也没法做，做不好。

 

2.把错误关在笼子里

 

以苹果公司操作系统的安全漏洞举例：

第三行会直接跳到fail，而忽略后边代码：

    if ((error = doSomething()) != 0)
        goto fail;         
        goto fail;    
    if ((error= doMore()) != 0)        
        goto fail;
fail:    
    return error;

 

这样的错误是如何被发布出来的，通过下边的”五道关卡“：

 

第一道关：程序员

提高程序员的修养，是一个永不过时的主题。从别人的失败和自己的失败中学习、积累、提高，是一个人成长的必修课。

 

首先，他应该正确使用缩进

    if ((error = doSomething()) != 0)
        goto fail;
    goto fail;
    if ((error= doMore()) != 0)
        goto fail;
fail:
    return error;

 

其次，他应该使用大括号

    if ((error = doSomething()) != 0) {
        goto fail;
        goto fail;
    }
    if ((error= doMore()) != 0) {
        goto fail;
    }
fail:
    return error;

 

魔鬼藏于细节。很多时候，优秀的代码源于我们对细节的热情和执着。可能，你遇到的或者是想到的问题，不是每一个都有完美的答案或者解决方法。但是，如果你能够找到哪怕仅仅是一个小问题的一个小小的改变方法，都有可能会给你的代码质量带来巨大的提升和改变。

 

 

第二道关：编译器

 

这一次编译器的防守并没有做好，因为它毫无察觉地漏过了多余的”Go To Fail“

对于编译器的警告，我们一定要非常警觉。能消除所有的警告，你就应该消除掉所有的警告，就算实在没有办法消除掉编译警告，那你也一定要搞清楚警告产生的原因，并确认编译警告不会产生任何后续问题。

 

 

第三道关：回归测试

 

一般地，软件测试会尽可能地覆盖关键逻辑和负面清单，以确保关键功能能够正确执行，关键错误能够有效处理。一般情况下，无论是开发人员，还是测试人员，都要写很多测试代码，来测试软件是否达到预期的要求。

软件测试没有办法覆盖所有的应用场景。但是，我们千万要覆盖关键逻辑和负面清单。一个没有良好回归测试的软件，很难保证代码变更的质量；也会使得代码变更充满不确定性，从而大幅地提高代码维护的成本。

 

 

第四道关：代码评审

代码评审是一个有效的在软件研发过程中抵御人类缺陷的制度，比如OpenJDK采用Webrev

 

 

第五道关：代码分析

静态代码分析

代码测试覆盖率