50 lines
4.4 KiB
Markdown
50 lines
4.4 KiB
Markdown
# 第四季回归 | 通向高质量代码之路
|
||
|
||
你好，我是郑晔！
|
||
|
||
细心的老同学可能已经注意到，我的第四个专栏已经上线了。
|
||
|
||
前面我用三个专栏 100 讲的篇幅给你讲了如何做一个不断精进的程序员，通过各种方式把代码写好，《10x 程序员工作法》让我们找准正确的目标，使程序不偏航；《软件设计之美》让程序更加灵活，适应未来的变化；《代码之丑》让我们不犯低级错误，使代码更容易理解。
|
||
|
||
其实，在这三个专栏里，有一条隐隐的线索一直贯穿始终：**我们怎么要怎么验证自己写的程序是对的？能够用来保证程序正确性，唯有测试。**
|
||
|
||
在《10x 程序员工作法》里，我讲了一个测试的小专题；《软件设计之美》中，我讲了用可测试性衡量软件设计的正确性；而在《代码之丑》中，我修正的很多坏味道，就是为了让代码更容易测试。
|
||
|
||
保证代码的正确性是每个程序员口中的目标，但它是多少程序员行动中的目标呢？这件事在行业中的真实情况是，从思想到行动之间有巨大的落差。我们不能质疑程序员的专业精神，但大部分人对代码正确性的要求都停留在个人努力上。
|
||
|
||
可遗憾的是，很多团队并没有对编写测试硬性的要求，即便有，也是很低的要求，比如，测试覆盖率达到50%。为什么团队不要求？一个很可悲的答案是**大多数程序员不会写测试**。对于不会做的事情，人们自然的反应就是少做或者不做。
|
||
|
||
因为测试并不是光知道 xUnit 框架就能够很好完成的，很多人只会用系统测试这种大粒度的测试，结果必然是整个测试又慢覆盖度又不高，还会有很多测不到的地方。反过来，这种笨拙的测试方式也会进一步劣化测试在程序员心目中的形象，导致更多的人不愿意写测试。
|
||
|
||
**程序员写测试就是为了编写高质量的代码**。这里所说的高质量代码分成两个部分，一方面自然是我们常规理解的：经过测试的代码，质量会更高。另一方面，要想写好测试，代码本身的质量也要高。
|
||
|
||
不过，想真正做好测试，需要有很多基础的铺垫，在不少人看来，一些东西看上去与测试并没有直接的关联，比如任务分解，再比如要有高质量的代码等等。其实只有把这些知识连接起来，我们才能知道如何做好测试。好在测试基础的部分，我在前面的几个专栏中已经讲过了，比如：
|
||
|
||
* 我们要懂得任务分解，这是《10x 程序员工作法》中讲过的；
|
||
* 我们要懂软件设计，这是《软件设计之美》中讲过的；
|
||
* 每个函数要整洁小巧，这是《代码之丑》中讲过的。
|
||
|
||
亲爱的老同学们，你们已经掌握了打开通向编写高质量代码大门的通行证，接下来，就是怎样把这些知识运用到编写测试的过程中了。所以，这次我就把“测试”这条隐藏在自己专栏中许久的线索给拿出来做一次完整地呈现，也就是这次的《程序员的测试课》。
|
||
|
||
在《程序员的测试课》中，你会看到：
|
||
|
||
* 程序员的测试和测试人员的测试会有什么不同；
|
||
* 怎么编写单元测试；
|
||
* 如何做到 100%的测试覆盖；
|
||
* 如何在遗留系统上写测试；
|
||
* ……
|
||
|
||
除了测试本身，这个专栏中还实现了一件很多老同学期待已久的事情。在前几个专栏中，很多同学都希望看到一个实战，把所学的知识在一个具体的项目中运用起来。在《程序员的测试课》中，我就用了一个实战的例子作为开篇，你会看到：
|
||
|
||
* 我是怎样做项目准备的，这是迭代 0 和项目自动化；
|
||
* 如何进行设计，这是软件设计；
|
||
* 将需求分解成一个个的具体任务，这是任务分解；
|
||
* 如何设计一个函数接口，如何封装参数，这是编码的过程；
|
||
* ……
|
||
|
||
在这次实战中，你熟悉的那些概念就在这个过程中慢慢地施展了出来。它们不再是我说出来的原则，而变成了一行行具体的代码。
|
||
|
||
作为老同学，你们已经在不经意间具备了写好测试的基础，剩下的，就是把这些知识贯穿起来，推开高质量代码的大门，一步一步地向前走。
|
||
|
||
欢迎回归，这一次，我们一起来编写高质量的代码！
|
||
|