You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

50 lines
4.4 KiB
Markdown

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

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