分类 技术志 下的文章

Go测试的20个实用建议

本文永久链接 – https://tonybai.com/2024/01/01/go-testing-by-example

2023年11月初,Go语言技术负责人Russ Cox在GopherCon Australia 2023大会上进行了题为“Go Testing By Example”的演讲:

12月初Russ Cox重新录制了该演讲内容的视频,并在个人网站上放了出来。这个演讲视频是关于如何编写好的Go测试的,Russ Cox介绍了20个实用建议,非常值得Go初学者甚至Go资深开发者学习并应用到实践中。这里是基于该视频整理的文字稿(可能并非逐字逐句),供广大Gopher参考。

注:在GopherCon Australia 2023,退休后暂定居澳大利亚的Go语言之父Rob Pike也做了一个名为“What We Got Right, What We Got Wrong”的主题演讲。在Go开源14年之后,有很多事情值得思考。这个演讲“事后诸葛亮般地”探讨了Go迄今为止取得的一些经验教训:不仅包括进展顺利的方面,还包括本可以做得更好的方面。可惜目前该演讲视频或文字稿并未放出,我们也只能等待。


大家好!这是几周前我在GopherCon Australia 2023进行的一次演讲,演讲的内容是关于如何编写好的测试。

不过首先让我们来思考一下为什么我们要编写测试。一些有关编程的书中常讲到:测试是为了发现程序中的错误!比如Brian W. Kernighan和Rob Pike合著的《The Practice of Programming》一书中讲到:“测试是一种坚定的、系统地尝试,旨在破坏你认为可以正确运行的程序”。这是真实的。这就是为什么程序员应该编写测试。但对于今天在这里的大多数人来说,这不是我们编写测试的原因,因为我们不仅仅是程序员,我们是软件工程师。什么意思呢?我想说的是,软件工程就是当你编程时增加时间和其他程序员时所发生的事情。编程意味着让程序运行,你有一个问题需要解决,你编写一些代码,运行它,测试它,调试它,得到答案,你就完成了。这本已经相当困难了,而测试是该过程的重要组成部分。但软件工程意味着你在长期与其他人一起开发的程序中完成所有这些工作,这改变了测试的性质。

让我们先看一个对二分查找函数的测试:

如图所示,这个函数接受一个有序(sorted)切片、一个目标值(target)和一个比较函数(cmp)。它使用二分搜索算法查找并返回两个内容:第一,如果目标存在,则返回其索引(index),第二是一个布尔值,指示目标是否存在。

大多数二分查找算法的实现都有错误,这个也不例外。我们来测试一下。

下面是一个很好的二分搜索的交互式测试:

你输入两个数字n和t,测试程序便创建一个包含n个元素的切片,其元素值按10倍增,然后程序在切片中搜索t并打印结果,然后你反复重复这一过程。

这可能看起来不足为奇,但有多少人曾经通过运行这种交互式测试程序来测试生产环境用的代码(production code)?我们所有人都这样做过。当你独自编程时,像这样的交互式测试程序对于查找bug非常有用,到目前为止代码看起来可以正常工作。

但这个交互式测试程序只适合独自编程时使用,如果你从事软件工程,意味着你要长时间保持程序的运行,并与其他人合作,那么这种类型的测试程序就不太有用了。

你需要一种每个人都可以在日常工作中运行的测试程序,可以在他们编写代码的同时运行,并且可以由计算机在每次代码提交时自动运行。问题在于仅通过手动测试程序只能确保它在今天正常工作,而自动化、持续的测试可以确保它在明天和未来都可以正常工作,即使其他不熟悉这段代码的人开始对其进行维护。并且我们要明确一点:那个不太熟悉代码的人可能是指未来六个月甚至六周后的你。

这是一个软件工程师的测试。你可以在不了解代码工作原理的情况下运行它。任何同事或任何计算机都可以使用”go test”运行该测试,并可以立即知道该测试是否通过。我肯定你已经见过这样的测试了。

软件工程的理想是拥有能够捕捉到后续可能出现的所有错误的测试。如果你的测试达到了这个理想状态,那么当你的所有测试都通过时,你应该可以放心地自动将你的代码部署到生产环境中,这就是人们所称的持续部署。如果你还没有这样做,如果这个想法让你感到紧张,那么你应该问问自己为什么。要么你的测试已经足够好,要么它们还不够好。如果它们足够好,那为什么不这样做呢?而如果它们不够好,那就倾听这些疑虑,并找出它们告诉你哪些测试被遗漏了。

几年前,我正在为新的Go官方网站go.dev编写代码。那时我们还在手动部署该网站,并且至少每周一次。我做的一项代码变更在我的机器上运行正常,但在部署到生产环境后便无法正常工作了,这着实令人非常烦恼和尴尬。解决办法是进行更好的测试和自动化的持续部署。现在,每当代码库中有新的提交时,我们使用一个Cloud Build程序来运行本地测试,并将代码推送到一个全新的服务器,然后运行一些只能在生产环境中运行的测试。如果一切正常,我们会将流量打到新的服务器。这样做改善了两点。首先,我不再导致令人尴尬的网站宕机。其次,每个人都不再需要考虑如何部署网站。如果他们想做变更,比如修复拼写错误或添加新的博客文章,他们只需发送更改请求,对其进行审核、测试和提交,然后自动化流程会完成其余工作。

要确信当其他人更改代码时你的程序不会出错,要确信只要测试通过就可以随时将程序推送到生产环境,你需要一套非常好的测试。但是什么样的测试才算是好的呢?

一般来说,使测试代码优秀的因素与使非测试代码优秀的因素是相同的:勤奋(hard work)、专注(attention)和时间(time)。对于编写优秀的测试代码,我没有什么“银弹式”的或硬性的规则,就像编写优秀的非测试代码一样。然而,我确实有一系列基于我们在Go上的良好实践的建议,我将在这次演讲中分享20个编写优秀测试代码的实用建议。

建议1:让添加新测试用例变得容易

这是最重要的建议。因为如果添加一个新测试用例很困难,你就不会去做。在这方面,Go已经提供了很好的支持。

上图是函数Foo的一个最简单的测试。我们专门设计了Go测试,使其非常容易编写。没有繁杂的记录或仪式会妨碍你。在包级别的测试中,这已经相当不错了,但在特定的包中,你可以做得更好。

我相信你已经了解了表驱动测试。我们鼓励使用表驱动测试,因为它们非常容易添加新的测试用例。这是我们之前看到的那个测试用例:假设我们只有这一个测试用例,然后我们想到了一个新的测试用例。我们根本不需要编写任何新的代码,只需要添加一行新的数据。如果目标是“使添加新的测试用例变得容易”,那么对于像这样的简单函数,向表中添加一行数据就足够了。不过,这也引出了一个问题:我们应该添加哪些测试用例?这将引导我们来到下一个建议。

建议2:使用测试覆盖率来发现未经测试的代码

毕竟,测试无法捕捉到未运行的代码中的错误。Go内置了对测试覆盖率的支持。下面是它的样子:

你可以运行“go test -coverprofile”来生成一个覆盖率文件,然后使用“go tool cover”在浏览器中查看它。在上图的显示中,我们可以看到我们的测试用例还不够好:实际的二分查找代码是红色的,表示完全未经测试。下一步是查看未经测试的代码,并思考什么样的测试用例会使这些代码行运行。

经过仔细检查,我们只测试了一个空切片,所以让我们添加一个非空的切片的测试用例。现在我们可以再次运行覆盖率测试。这次我将用我写的一个小命令行程序“uncover”来读取覆盖率文件。Uncover会显示未被测试覆盖的代码行。它不会给你网页视图那样的全局视图,但它可以让你保持在一个终端窗口中。Uncover向我们展示了只剩下一行代码未被测试执行。这是进入切片的第二半部分的行,这是有道理的,因为我们的目标是第一个元素。让我们再添加一个测试,搜索最后一个元素。

当我们运行测试时,它通过了,我们达到了100%的覆盖率。很棒。我们完成了吗?没有,这将引导我们到下一个实用建议。

建议3:覆盖率不能替代思考

覆盖率对于指出你可能忽略的代码部分非常有用,但机械工具无法替代对于高难度的输入、代码中的微妙之处以及可能导致代码出错的情况进行的实际思考。即使代码拥有100%的测试覆盖率,仍然可能存在bug,而这段代码就存在bug。这个提示也适用于覆盖率驱动的模糊测试(fuzzing test)。模糊测试只是尝试通过代码探索越来越多的路径,以增加覆盖率。模糊测试也非常有帮助,但模糊测试也不能替代思考。那么这里缺少了什么呢?

需要注意的一点是,唯一一个无法找到目标的测试用例是一个空输入切片。我们应该检查在具值的切片中无法找到目标的情况。具体来说,我们应该检查当目标小于所有值、大于所有值和位于值的中间时会发生什么。所以让我们添加三个额外的测试用例。

注意添加新测试用例是多么容易。如果你想到一个你的代码可能无法正确处理的情况,添加该测试用例应该尽可能简单,否则你就会觉得麻烦而不去添加。如果太困难,你就不会添加。你还可以看到我们正在开始列举这个函数可能出错的所有重要路径。这些测试对未来的开发进行了约束,以确保二分查找至少能够正常工作。当我们运行这些测试时,它们失败了。返回的索引i是正确的,但表示target是否找到的布尔值是错误的。所以让我们来看看这个问题。

阅读代码,我们发现返回语句中的布尔表达式是错误的。它只检查索引是否在范围内。它还需要检查该索引处的值是否等于target值。所以我们可以进行这个更改,如图所示,然后测试通过了。现在我们对这个测试感到非常满意:覆盖率是良好的,我们也经过了深思熟虑。还能做什么呢?

建议4:编写全面的测试

如果你能够测试函数的每一个可能输入,那就应该这样做。但现实中可能无法做到,但通常你可以在一定约束条件下测试特定数量以内的所有输入。下面是一个二分查找的全面测试:

我们首先创建一个包含10个元素的切片,具体来说就是从1到19的奇数。然后我们考虑该切片的所有可能长度的前缀。对于每个前缀,我们考虑从0到两倍长度的所有可能目标,其中0是小于切片中的所有值,两倍长度是大于切片中的所有值。这将详尽地测试每个可能的搜索路径,以及长度不超过我们的限制10的所有可能尺寸的切片。但是现在我们怎么知道答案是什么呢?我们可以根据测试用例的具体情况进行一些数学计算,但有一种更好、更通用的方法。这种方法是编写一个与真正实现不同的参考实现。理想情况下,参考实现应该明显是正确的,但它只需与真实实现采用不同的方法即可。通常,参考实现将是一种更简单、更慢的方法,因为如果它更简单和更快,你会将其用作真正的实现。在这种情况下,我们的参考实现称为slowFind。测试检查slowFind和Find是否可以在答案上达成一致。由于输入很小,slowFind可以采用一个简单的线性搜索。

通过生成所有可能的输入并将结果与简单的参考实现进行比较,这种模式非常强大。它做的一件重要的事情是覆盖了所有基本情况,例如0个元素的切片、1个元素的切片、长度为奇数的切片、长度为偶数的切片、长度为2的幂的切片等等。大多数程序中的绝大多数错误都可以通过小规模的输入进行重现,因此测试所有小规模的输入非常有效。事实证明,这个全面测试通过了。我们的思考相当不错。

现在,如果全面测试失败,那意味着Find和slowFind不一致,至少有一个有bug,但我们不知道是哪一个有问题。添加一个直接测试slowFind会有所帮助,而且很容易,因为我们已经有了一个测试数据表。这是表驱动测试的另一个好处:可以使用这些表来测试多个实现。

建议5:将测试用例与测试逻辑分开

在表驱动测试中,测试用例在表中,而处理这些测试用例的循环则是测试逻辑。正如我们刚才所看到的,将它们分开可以让你在多个上下文中使用相同的测试用例。那么现在我们的二分查找函数完成了吗?事实证明没有,还有一个bug存在,这引导我们到下一个问题。

建议6:寻找特殊情况

即使我们对所有小规模情况进行了全面测试,仍然可能存在潜在的bug:

现在,这里再次展示了代码。还剩下一个bug。你可以暂停视频,花一些时间来查看它。

有人看出bug在哪里了吗?如果你没有看到,没关系。这是一个非常特殊的情况,人们花了几十年的时间才注意到它。Knuth告诉我们,尽管二分查找在1946年发表,但第一个正确的二分查找实现直到1964年才发表。但是这个bug直到2006年才被发现。

bug是这样的,如果切片中的元素数量非常接近int的最大值,那么i+j会溢出,因此i+j/2就不是切片中间位置的正确计算方法了。这个bug于2006年在一个使用64位内存和32位整数的C程序中被发现,这个程序用于索引包含超过10亿个元素的数组。在Go语言中,这种特定组合基本上不会发生,因为我们要求使用64位内存时,也要使用64位整数,这正是为了避免这种bug。但是,由于我们了解到这个bug,而且你永远不知道你或其他人将来如何修改代码,所以避免这个bug是值得的。

有两种常见的修复方法可以避免数学计算溢出。速度稍快的方法是进行无符号除法。假设我们修复了这个问题。现在我们完成了吗?不。因为我们还没有编写测试。

建议7:如果你没有添加测试,那就没有修复bug

这句话在两个不同的方面下都是正确的。

第一个是编程方面。如果你没有进行测试,bug可能根本没有被修复。这听起来可能很愚蠢,但你有多少次遇到过这种情况?有人告诉你有一个bug,你立即知道修复方法。你进行了更改,并告诉他们问题已经修复。然后他们却回来告诉你,不,问题还存在。编写测试可以避免这种尴尬。你可以说,很抱歉我没有修复你的bug,但我确实修复了一个bug,并会再次查看这个问题。

第二个是软件工程方面,即“时间和其他程序员”的方面。bug并不是随机出现的。在任何给定的程序中,某些错误比其他错误更有可能发生。因此,如果你犯了一次这个错误,你或其他人很可能在将来再次犯同样的错误。如果没有测试来阻止它们,bug就会重新出现。

现在,这个特定的测试很难编写,因为输入范围非常大,但即使测试很难编写,这个建议仍然成立。实际上,在这种情况下,这个建议通常更为正确。

为了测试这种情况,一种可能性是编写一个仅在32位系统上运行的测试,对两千兆字节的uint8进行二分查找。但这需要大量的内存,并且我们现在已经没有多少32位系统了。对于测试这种难以找到的bug,通常还有更巧妙的解决方案。我们可以创建一个空结构体的切片,无论它有多长,都不会占用内存。这个测试在一个包含MaxInt个空结构体的切片上调用Find函数,寻找一个空结构体作为目标,但是它传入了一个总是返回-1的比较函数,声称切片元素小于目标。这将使二分查找探索越来越大的切片索引,从而导致溢出问题。如果我们撤销我们的修复并运行这个测试,那么测试肯定会失败。

而使用了我们的修复后,测试通过了。现在bug已经修复了。

建议8:并非所有东西都适合放在表中

这个特殊情况不适合放在表中,但这没关系。但是很多东西确实适合放在表中。

这是我最喜欢的一个测试表之一。它来自fmt.Printf的测试用例。每一行都是一个printf格式、一个值和预期的字符串。真实的表太大了,无法放在幻灯片上,但这里摘录了一些表中的代码行。

如果你仔细阅读整个表,你会看到其中一些明显是修复bug的内容。记住建议7:如果你没有添加测试,那就没有修复bug。表格使得添加这些测试变得非常简单,并且添加这些测试可以确保这些bug不会再次出现。

表格是将测试用例与测试逻辑分离并且方便添加新的测试用例的一种方法,但有时你会有很多测试,甚至写Go语法的开销也是不必要的。例如,这里是strconv包的一个测试文件,用于测试字符串与浮点数之间的转换。你可能认为编写解析器来处理这个输入太麻烦了,但一旦你知道了如何处理,其实并不需要太多工作,而且定义测试专用的小型语言实际上非常有用。

因此,我将快速介绍一下解析器,以展示它并不复杂。我们读取文件,然后将其分割成行。对于每一行,我们计算错误消息的行号。切片元素0表示第1行。我们去掉行尾的任何注释。如果行为空白行,我们跳过它。到目前为止,这是相当标准的样板代码。现在是重点。我们将行分割为字段,并提取出四个字段。

然后根据类型字段在float32或float64的数学运算中进行转换。myatof64基本上是strconv.ParseFloat64的变体,不同之处在于它处理允许我们按照从论文中复制的方式编写测试用例的十进制p格式。

最后,如果结果不是我们想要的,我们打印错误。这非常类似于基于表格的测试。我们只是解析文件,而不是遍历表格。它无法放在一个幻灯片上,但在开发时它可以放在一个屏幕上。

建议9:测试用例可以放在testdata文件中

测试不必都要放在源代码中。

作为另一个例子,Go正则表达式包包含了一些从AT&T POSIX正则表达式库复制过来的testdata文件。我不会在这里详细介绍,但我很感激他们选择为该库使用基于文件的测试,因为这意味着我可以重用testdata文件,将其用于Go。这是另一种ad-hoc格式,但它易于解析和编辑。

建议10:与其他实现进行比较

与AT&T正则表达式的测试用例进行比较有助于确保Go的包以完全相同的方式处理各种边缘情况。我们还将Go的包与C++的RE2库进行比较。为了避免需要编译C++代码,我们以记录所有测试用例的方式运行它,并将该文件作为testdata提交到Go中。

在文件中存储测试用例的另一种方法是使用成对的文件,一个用于输入,一个用于输出。为了实现go test -json,有一个名为test2json的程序,它读取测试输出并将其转换为JSON输出。测试数据是成对的文件:测试输出和JSON输出。

这是最简短的文件。测试输出位于顶部,它是test2json的输入,应该生成底部的JSON输出。以下是实现,展示了从文件中读取测试数据的惯用方法。

我们首先使用filepath.Glob查找所有的testdata。如果失败或找不到任何文件,我们会报错。否则,我们循环遍历所有文件。对于每个文件,我们通过获取基本文件名(不包括testdata/目录名和文件后缀)来创建子测试名称。然后我们用该名称运行一个子测试。如果你的测试用例足够复杂,每个文件一个子测试通常是有意义的。这样,当一个测试用例失败时,你可以使用go test -run只运行特定的文件。

对于实际的测试用例,我们只需要读取文件,运行转换器,并检查结果是否匹配。对于检查,我最开始使用了bytes.Equal,但随着时间的推移,编写一个自定义的diffJSON函数来解析两个JSON结果并打印实际差异的详细说明变得更有价值。

建议11:使测试失败易读

回顾一下,我们已经在二分查找中看到了这一点。

我认为我们都同意粉色框不是一个好的失败。但是黄色框中有两个细节使得这些失败尤为出色。首先,我们在单个if语句中检查了两个返回值,然后在简洁的单行中打印了完整的输入和输出。其次,我们不会在第一个失败处停止。我们使用t.Error而不是t.Fatal,以便执行更多的测试用例。结合起来,这两个选择让我们可以看到每个失败的完整细节,并在多个失败中寻找模式。

回到test2json,这是它的测试失败的情况。它计算出哪些事件是不同的,并清晰地标记它们。重要的是,在你编写测试时,你不必写这种复杂的代码。bytes.Equal在开始时是可以的,并且可以专注于代码。但是随着失败变得更加微妙,并且你发现自己花费太多时间只是阅读失败输出,这是一个好的信号,它告诉你是时候花一些时间使其更易读了。此外,如果确切的输出发生更改并且你需要更正所有的测试数据文件,这种类型的测试可能会有点麻烦。

建议12:如果答案可能会改变,编写代码来更新它们

通常的做法是在测试中添加一个“-update”标志。这是test2json的更新代码示例。

测试定义了一个新的“-update标志”。当标志为true时,测试将计算的答案写入答案文件,而不是调用diffJSON。现在,当我们对JSON格式进行有意的更改时,“go test -update”会更新所有答案。你还可以使用版本控制工具如“git diff”来审查更改,并在看起来不正确时撤销更改。在谈论测试文件的主题上,有时将一个测试用例分割成多个文件会很烦人。如果我今天编写这个测试,我就不会这样做。

建议13: 使用txtar进行多文件测试用例

注:导入txtar:import “golang.org/x/tools/txtar”

Txtar是我们几年前专门为解决多文件测试用例问题而设计的一种新的存档格式。其Go解析器位于golang.org/x/tools/txtar中,我还找到了用Ruby、Rust和Swift编写的解析器。

Txtar的设计有三个目标。首先,足够简单,可以手动创建、编辑和阅读。其次,能够存储文本文件的树形结构,因为我们在go命令中需要这个功能。第三,能够在git历史记录和代码审查中进行良好的差异比较。其他的包括成为完全通用的存档格式、存储二进制数据、存储文件模式(file mode)、存储符号链接等都不是目标,因为存档文件(archived file)格式往往变得十分复杂,而复杂性与第一个目标直接相矛盾。这些目标和非目标导致了一个非常简单的格式。下面是一个示例:txtar文件以注释开头。

本例中为”Here are some greetings.”,然后通常会有零个或多个文件,每个文件由形如”– 文件名 –”的行引入。这个存档包含两个单行文件,hello和g’day。就是这样,这就是整个格式。没有转义,没有引用,没有对二进制数据的支持,没有符号链接,没有可能的语法错误,没有复杂之处。下面是一个在测试数据中使用txtar文件的真实示例。

该测试数据用于计算差异的包:在这种情况下,注释对于人们来说很有用,用于记录正在进行的测试,然后在这个测试中,每个用例由两个文件和它们的差异后面跟随的两个文件组成。

使用txtar文件几乎和编写它们一样简单。下面是我们之前查看的diff包的测试。

这是通常的基于文件的循环,但我们在文件上调用了txtar.ParseFile。然后我们坚持认为存档包含三个文件,第三个文件的名称为diff。然后我们对两个输入文件进行差异比较,并检查结果是否与预期的差异匹配。

这就是整个测试。你可能已经注意到,在使用之前,文件数据会被传递给”clean”函数进行清理。clean函数允许我们在不使txtar格式本身复杂化的情况下添加一些特定于diff的扩展。

第一个扩展处理以空格结尾的行,在差异中确实会出现这种情况。许多编辑器希望去除这些尾随空格,因此测试允许在txtar的数据行末尾放置$,并且clean函数会删除该$。在这个示例中,标记的行需要以一个空格结尾。

此外,txtar要求文件中的每一行都以换行符结尾,但我们希望测试diff在不以换行符结尾的文件上的行为。因此,测试允许在结尾处放置一个字面意义上的“尖号D”。clean函数会删除“尖号D”和其后的换行符。在这种情况下,’new’文件最终没有最后的换行符,而diff正确报告了这一点。因此,尽管txtar非常简单,你也可以轻松地在其上添加自己的格式调整。当然,重要的是要记录这些调整,以便下一个参与测试的人能够理解它们。

建议14:对现有格式进行注解(annotation)来创建测试迷你语言

对现有格式进行注释,比如在txtar中添加$和尖号D,是一个强大的工具。

这里是对现有格式进行注释的一个示例。这是Go类型检查器(type checker)的一个测试。这是一个普通的Go输入文件,但是期望的类型错误已经以/*ERROR*/注释的形式添加了进去。我们使用/*注释,这样我们就可以将它们放置在错误报告的确切位置上。测试运行类型检查器,并检查它是否在预期位置产生了预期的消息,并且没有产生任何意外的消息。下面是类型检查器的另一个示例。

在这个测试中,我们在通常的Go语法之上添加了一个assert注释。这使我们能够编写常量算术的测试,就像这个例子一样。类型检查器已经计算了每个常量表达式的布尔值,所以检查assert其实只是检查常量是否被求值为true。下面是另一个带有注释的格式示例。

Ivy是一个交互式计算器。你输入程序,通常是简单的表达式,它会打印出答案。测试用例是看起来像这样的文件:未缩进的行是Ivy的输入,缩进的行是注释,指示Ivy应该打印出预期的输出。编写新的测试用例再也没有比这更简单的了。这些带注释的格式扩展了现有的解析器和打印器(printer)。有时编写自己的解析器和打印器是有帮助的。毕竟,大多数测试涉及创建或检查数据,当你可以使用方便的形式处理数据时,这些测试总是可以更好。

建议15:编写解析器和打印器来简化测试

这些解析器和打印器不一定是用于testdata中数据文件的独立脚本。你也可以在常规的Go代码中使用它们。

这是一个运行deps.dev代码的一个测试片段。这个测试设置了一些数据库表行。它调用了一个使用数据库并正在进行测试的函数。然后它检查数据库是否包含了预期的结果。Insert和Want调用使用了一个专门为这些测试编写的用于数据库内容的迷你语言。解析器就像它看起来的那样简单:它将输入分割成行,然后将每行分割成字段。第一行给出了列名。就是这样。这些字符串中的确切间距并不重要,但是如果它们都对齐,当然看起来更美观。

因此,为了支持这个测试,deps.dev团队还有一个专门为这些测试编写的代码格式化程序。它使用Go标准库解析测试源代码文件。然后它遍历Go语法树,查找Insert或Want的调用。它提取字符串参数并将它们解析为表格。然后它将表格重新打印为字符串,将字符串重新插入语法树中,并重新打印语法树为Go源代码。这只是gofmt的一个扩展版本,使用了与gofmt相同的包。我这里不会展示这些代码,但代码量其实不多。

解析器和打印器需要花费了一些时间来编写。但现在,每当有人编写一个测试时,编写测试就更容易了。每当一个测试失败或需要更新时,调试也更容易了。如果你正在进行软件工程,收益将随着程序员数量和项目生命周期的增加而扩大。对于deps.dev来说,已经花费在这个解析器和打印器上的时间已经多次节省了。或许更重要的是,因为测试更容易编写,你可能会写更多的测试,这将导致更高质量的代码。

建议16:代码质量受测试质量限制

如果你不能编写高质量的测试,你将无法编写足够的测试,并且最终无法得到高质量的代码。

现在我想向你展示一些我曾经参与的最高质量的测试,这些测试是针对go命令的测试。它们将我们到目前为止看到的许多思想汇集在一起。这是一个简单但真实的go命令测试。这是一个txtar输入,其中包含一个名为hello.go的文件。archive comment是一个逐行简单命令语言编写的脚本。在脚本中,”env”设置一个环境变量来关闭Go module机制。井号引入注释。而”go”运行go命令,它应该运行hello world。该程序应该将hello world打印到标准错误中。”stderr”命令检查前一个命令打印的标准错误流是否与正则表达式匹配。因此,这个测试运行”go run hello.go”并检查它是否将hello world打印到标准错误中。

这里是另一个真实的测试。请注意底部的a.go是一个无效的程序,因为它导入了一个空字符串。第一行开头的感叹号是一个”非”操作符。NOT go list a.go意味着go list a.go应该失败。下一行的”NOT stdout .”表示标准输出不应该有与正则表达式”.”匹配的内容,也就是不应该打印任何文本。接下来,标准错误流应该有一个无效的导入路径的消息。最后,不应该发生panic。

建议17:使用脚本可以编写很好的测试

这些脚本使添加新的测试用例变得非常容易。

这是我们最小的测试用例:两行代码。最近我在破坏了unknown command的错误消息后添加了这个测试用例。总共,我们有超过700个这样的脚本测试,从两行到500多行不等。

这些测试脚本取代了一个更传统的使用方法(method)的测试框架。这张幻灯片展示了其中一个真实的测试,前面是脚本编写的测试用例,后面是等价的Go编写的传统测试代码。细节并不重要,只需注意脚本要比传统测试方法更容易编写和理解。

建议18:尝试使用rsc.io/script来创建基于脚本的测试用例

距离我们创建go脚本测试已经过去了大约五年时间,我们对这个特定的脚本引擎非常满意。Bryan Mills花了很多时间为它提供了一个非常好的API,早在11月份,我将其发布到了rsc.io/script以供导入使用。现在我说”尝试”是因为它还比较新,并且具有讽刺意味的是,它本身的测试还不够多,因为可导入的包只有几周的历史,但你仍然可能会发现它很有用。当我们对其有更多经验时,我们可能会将其放在更官方的位置上。如果你尝试了它,请告诉我结果如何。

提取脚本引擎的动机是为了在go命令测试的不同部分中重用它。这个脚本正在准备一个包含我们想要在常规go命令脚本测试中导入的模块的Git存储库(repo)。你可以看到它设置了一些环境变量,运行了真正的git init,设置了时间,在存储库中运行了更多的git命令来添加一个hello world文件,然后检查我们得到了我们想要的存储库。再一次,测试并不是从一开始就是这样的,这引出了下一个实用建议。

建议19:随着时间的推移改进你的测试

最初,我们没有这些存储库脚本。我们手工创建小型测试存储库,并将它们发布到GitHub、Bitbucket和其他托管服务器,具体取决于我们所需的版本控制系统。这种方法还算可以,但这意味着如果这些服务器中的任何一个宕机,测试就会失败。最终,我们花时间构建了自己的云服务器,可以为每个版本控制系统提供存储库服务。现在,我们手工创建存储库,将其压缩并复制到服务器上。这样做更好,因为现在只有一个服务器可能会使我们的测试失败,但有时也会出现网络问题。测试存储库本身也没有进行版本控制,并且与使用它们的测试不在一起,这也是一个问题。作为测试的一部分,基于脚本的版本完全可以在本地构建和提供这些存储库。而且现在很容易找到、更改和审查存储库的描述。这需要很多基础设施,但也测试了很多代码。如果你只有10行代码,你完全不需要拥有数千行的测试框架。但是如果你有十万行代码,这大约是go命令的规模,那么开发几千行代码来改进测试,甚至是一万行代码,几乎可以肯定是一个不错的投资。

建议20:追求持续部署

也许出于策略原因,你无法每次都实际部署那些通过了所有测试的代码提交,但无论如何都要追求这一目标。正如我在演讲开始时提到的,对于持续部署的任何疑问都是有益的小声音,它们告诉你需要更好的测试。而更好的测试的关键当然是让添加新测试变得容易。即使你从未实际启用持续部署,追求这一目标也可以帮助你保持诚实,提高测试的质量和代码的质量。

我之前提到过Go官方网站使用了持续部署。在每次提交时,我们运行测试来决定是否可以部署最新版本的代码并将流量路由到它。此时,你不会感到惊讶,我们为这些测试编写了一个测试脚本语言。上图是它们的样子。每个测试以一个HTTP请求开始。这里我们GET主页go.dev。然后对响应进行断言。每个断言的形式为”字段(field),运算符(operator),值(value)”。这里字段(field)是body,运算符(operator是contains,值(value)是body中必须包含的字面值。这个测试检查页面是否渲染过了,因此它检查基本文本以及一个副标题。为了更容易编写测试,根本没有引号。值就是运算符后面的其余部分。接下来是另一个测试用例。出于历史原因,/about需要重定向到pkg.go.dev。

这是另一个案例。这里没有什么特别的,只是检查案例研究页面是否渲染(rendering)了,因为它是由许多其他文件合成的。测试可以检查的另一个字段是HTTP响应代码,这是一个错误修复。我们错误地在Go存储库根目录中提供了这些文件,就好像它们是Go网站页面一样。我们希望改为返回404。你还可以测试标头foo的值,其中foo是某个标头。在这种情况下,标头Content-Type需要正确设置为主博客页面及其JSON feed。

这是另一个示例。这个示例使用正则表达式匹配运算符tilde和“\s+”语法,以确保页面具有正确的文本,无论单词之间有多少空格。这变得有点老套了,所以我们添加了一个名为trimbody的新字段,它是将所有空格序列替换为单个空格后的body。这个示例还显示了值可以作为多个缩进的行提供,以便更容易进行多行匹配。

我们还有一些无法在本地运行但在生产环境中仍值得运行的测试,因为我们将实时流量迁移到服务器之前需要进行这些测试。下面是其中两个。这些依赖于对生产环境playground后端的网络访问。这些案例除了URL不同之外都是相同的。这不是一个非常易读的测试,因为这些是我们唯一的POST测试。如果我们添加了更多这样的测试,我可能会花时间使它们看起来更好,以随着时间推移改进你的测试。但是现在它们还可以,它们起到了重要的作用。

最后,和往常一样,添加错误修复很容易。在问题51989中,live web站点根本没有呈现。因此,这个测试检查页面确实呈现并包含一个独特的文本片段。问题51989不会再次发生,至少不会在实际的网站上。肯定会有其他错误,但那个问题已经彻底解决了,这就是进步。以上这些是我有时间向你展示的这些例子。

小结

最后一个想法。我相信你经历过追踪错误并最终发现一个重要的代码片段是错误的情况。但不知何故,这个代码片段的错误大部分时间都无关紧要,或者错误被其他错误的代码抵消了。你可能会想:“这段代码以前是怎么工作的?”如果是你自己编写的代码,你可能会认为自己很幸运。如果是别人编写的代码,你可能会对他们的能力产生质疑,然后又认为他们很幸运。但是,大多数时候,答案并不是运气。对于这段代码为什么会工作的问题的答案几乎总是:因为它有一个测试。当然,代码是错误的,但测试检查了它足够正确,使系统的其他部分可以正常工作,这才是最重要的。也许编写这段代码的人确实是一个糟糕的程序员,但他们是一个优秀的软件工程师,因为他们编写了一个测试,这就是为什么包含该代码的整个系统能够工作的原因。

我希望你从这次演讲中得出的结论不是任何特定测试的具体细节,尽管我希望你可以留意对小型解析器和打印机的良好使用带来的好处。任何人都可以学会编写它们,并且有效地使用它们可以成为软件工程的超能力。最终,这对这些软件包来说是好测试。对于你的软件包,好测试可能看起来会有所不同。这没关系。但要使添加新的测试用例变得容易,并确保你拥有良好、清晰、高质量的测试。请记住,代码质量受测试质量的限制,因此逐步投入改进测试。你在项目上工作的时间越长,你的测试就应该变得越好。并且要追求持续部署,至少作为一种思想实验,以了解哪些方面的测试还不够充分。

总的来说,要像编写优秀的非测试代码一样,思考并投入同样的思想、关心和努力来编写优秀的测试代码,这绝对是值得的


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

2023年Go语言盘点:稳中求新,稳中求变

本文永久链接 – https://tonybai.com/2023/12/31/the-2023-review-of-go-programming-language

时光荏苒,转眼间已经是2023年的最后一天了。《2022年Go语言盘点:泛型落地,无趣很好,稳定为王》仿佛就写在昨天。

回首这一年,全球彻底从新冠大流行中得以复苏,Go语言也不例外,最直观的表现就是全球各地的GopherCon技术大会或小型Meetup都纷纷从停办/线上的状态来到了线下,并获得Gopher们的热烈欢迎和踊跃参与,比如下图中的GopherConGopherCon UKGopherCon EuropeGopherCon AustraliaGolab等。

尤其值得一提的是我们本土最大的Gopher技术大会GopherChina 2023,今年为了满足不同地域Gopher的需求,GoCN社区在6月和11月分别在北京和上海举办了两次GopherChina大会,这也是历史首次。

Go语言团队的大神们也开始重新“乐此不疲”地参与到上述这些大会中,以推进全球Go社区与生态的建设。就连已经退居二线的Go语言之父Rob Pike也亲自“现身说法”,在年底的GopherCon Australia 2023上发表了“What We Got Right, What We Got Wrong”的主题演讲来回顾Go诞生以来的得与失。

大神回顾一生,我们盘点一年。在这篇文章中,我就和大家一起聊聊Go在2023年的状态、所处的位置以及Go未来演进的机制与策略。

1. Go的2023

1.1 稳

一如往年,Go在2023年发布了两个大版本,分别是2023年2月份的Go 1.20和8月份的Go 1.21

在这两个版本中,Go语法特性一如既往的求稳,除了支持切片类型到数组类型(或数组类型的指针)的类型转换,其余更是像语法的修修补补,比如:comparable“放宽”了对泛型实参的限制、unsafe包继续添加“语法糖”、增加min、max和clear预定义函数、增强type inference能力等。

这些并不会让Gopher感到“意外”,因为这与Russ Cox在2022年宣称的“Go is boring”的精神是一脉相承的。

不过,除了Go语法特性变化方面的“寡淡”之外,Go在其他方面还是求新和求变的,接下来我们先来看看Go是如何求新的。

注:求新与求变可能存在交集的地方,边界可能也有一定模糊性,也存在相互促进的情况,希望大家阅读下面内容时不要吹毛求疵:)。

1.2 求新

Go在语法特性求稳的同时,在编译器、工具链、运行时以及标准库等方面都在努力优化和打磨,旨在进一步提升Go兼具的生产力与运行时效率,其中很多优化和打磨的措施不乏新颖。

Go 1.20版本中首次引入的PGO(profile-guided optimization)技术预览版,到Go 1.21版本变为默认开启,Go官方给出的PGO优化的效果数据是:PGO优化带来的性能提升一般是2%~7%,而在最新的Go 1.22rc1中,这个数字已经变为2%~14%了。

在内存管理方面,Go 1.20引入了试验特性arena包,虽然它没能在Go 1.21中按时转正,如今处于proposal-hold状态,但这也算是一次在内存管理机制上的求新。

Go是一门面向软件工程的编程语言,在这一年中,Go在软件工程领域的求新例子也是不少。比如:可用于大幅简化Go项目创建的gonew工具,它支持基于go project template clone并创建一个属于你的Go项目;再比如对应用执行时的代码覆盖率的采集,可以帮助开发者更进一步了解最终可执行程序代码执行路径上的测试覆盖情况;而govulncheck工具则是Go在软件工程与供应链安全领域的求新尝试,该工具丰富了我们对Go项目进行安全漏洞检查的手段。

注:关于供应链安全问题,Russ Cox近期有一个专门的Talk:Open Source Supply Chain Security at Google,感兴趣的童鞋可以学习一下。

Go始终对IT界出现的新技术、新趋势以及Go社区的新想法保持open。在WASM出现早期,Go就提供了对wasm的porting支持,如今在Go 1.21中,Go还对尚未形成最终规范的WASI(WebAssembly System Interface)提供了支持。

Go社区的反馈也是Go团队求新的来源,比如一个典型例子就是log/slog加入标准库,让Go标准库原生支持了结构化日志输出,且日志性能不输像zap这样的第三方开源log包

Go社区也跟随Go团队的节奏,走在求新的道路上。2023年,IT界最大的事件就是以ChatGPT为代表的大语言模型的横空出世,这很可能是一个百年不遇的、对人类文明进步有着重要里程碑意义的事件。各行各业,言必称大模型,言必称AI。在传统机器学习、深度学习以及神经网络方面生态并不丰富的Go,也在尝试与大模型对接,比如:支持快速在本地启动和运行llama2、mistral 7B、codellama、vicuna等大模型的ollama开源项目在短短几个月就收获近30k个小星星的关注;再比如Gemini大模型推出后,Google一并开源了支持与Google各种大模型项目对接的Google AI Go SDK开源项目,并提供了详细的教程指导Gopher如何通过该SDK与大模型交互

注:Google把Gemini Pro的API免费提供给个人用户了,该模型具备GPT 3.5 级别的能力,32k 上下文,38 种语言支持以及多模态支持,唯一的约束是每分钟60个请求。

2023年第二次Go用户调查报告中,Go 开发者表示,他们对改善其编写代码的质量、可靠性和性能的人工智能/机器学习工具感兴趣,而不是编写代码的工具。一位时刻警醒、从不忙碌的专家“审阅者”可能是一种更有帮助的AI开发者辅助形式。Go官方表示了对该调查结果的重视,也许在后续的Go工具链中“AI加持”会成为常态。

1.3 求变

2023年8月,在Go 1.21版本刚刚发布后,Go官博就发布了Russ Cox编写的两篇文章:《Backward Compatibility, Go 1.21, and Go 2》和《Forward Compatibility and Toolchain Management in Go 1.21》,进一步明确了Go承诺的向后兼容的范围和方案,并第一次阐述了向前兼容性的具体方案,这两篇文章为Go语言后续的“求变”奠定了理论基础。

在向后兼容方面,从Go 1.21开始Russ Cox提出一些举措,比如:Go将扩展和规范化了GODEBUG的使用,其大致思路如下:

  • 对于每个在Go1兼容性承诺范围内的且可能会破坏(break)现有代码的新特性/新改变(比如:panic(nil)语义的改变)加入时,Go会向GODEBUG设置
    中添加一个新选项(比如GODEBUG=panicnil=1),以保留采用原语义进行编译的兼容能力;
  • GODEBUG中新增的选项将至少保留两年(4个Go release版本),对于一些影响重大的GODEBUG选项(比如http2client和http2server),保留的时间可能更长,甚至一直保留;
  • GODEBUG的选项设置与go.mod的go version是匹配的。例如,即便你现在的工具链是Go 1.21,如果go.mod中的go version为1.20,那么GODEBUG控制的新特性语义将不起作用,依旧保持Go 1.20时的行为。除非你将go.mod中的go version升级为go 1.21.0;
  • 在Go 1.21及以后版本中,除了可以使用像GODEBUG=panicnil=1的环境变量恢复原先语义外,还可以在main包中使用//go:debug指示符。

在向前兼容方面,Russ Cox提出的方案有些复杂难懂,这里就不赘述了,感兴趣的童鞋可以阅读一下我之前的文章《聊聊Go语言的向前兼容性和toolchain规则》了解更多细节。

1.3.1 语法填坑

在Go的诸多“求变”中,影响最大的还是对已有语法坑的“修正”,这些“填坑”工作或多或少都会对存量代码带去影响,甚至是break change,Go社区的反对声音也是不少。但无论怎样,这些工作已经在Go 1.21版本拉开帷幕了。比如:改变panic(nil)的语义以及对循环变量语义的变更,大家可以在《Go 1.21中值得关注的几个变化》一文中了解更多细节。

对现有语法坑的修正也进一步促进了“求新”,比如在修正loopvar语义的同时,for range支持对更多类型表达式的迭代也在进行中,比如Go 1.22中,for range将支持迭代整型表达式,并以试验特性提供了对函数迭代器的支持。

1.3.2 标准库v2示范

Go号称是“自带电池”的语言,其高质量的标准库得到了广大Gopher的欢迎。Go团队也一直努力推进Go标准库功能的丰富性,比如:Go 1.22中对http.ServeMux功能进行了增强,使其像第三方的gorilla/mux那样增加对带有通配符路由的匹配。

Go 1.22中,标准库还首次出现了v2版本包:math/rand/v2,这为后续标准库的vN方式演进提供了示范,从Go团队的官方issue、discussion中了解到,后续如sync/v2、encoding/json/v2等已经列上日程了。

2. Go所处的位置

很多人关注Go当前的状态:国内大厂用的多么?小厂是不是也在广泛采纳。这些问题我在往年的Go语言盘点时也都做过梳理,今年就不再提了。没有哪个大厂在广泛采用一门语言后,会在一年内全部推翻重写的;小厂对Go的采纳也是有惯性的。

今年先从我的两个意外“收获”开始。

2.1 两个意外的“收获”

2023年10月中旬,世界知名电动车厂商Tesla发布了新版fleet APIvehicle command SDK,鉴于本人也在智能网联汽车行业内打拼,于是对Tesla的此次发布做了一些深入了解。在Tesla的github主页上我赫然发现:Go是目前Tesla开源项目的第二大语言。

相对于传统的主机厂(车厂),Telsa算是比较开放的了。开放包含两个含义,一是将车端能力的开放,二是项目的开源。就目前了解到,国内主机厂还鲜有将车端能力开放出来的,开源就更是鲜见。但Tesla在这两方面都做到了,既开放了车端API,又做了针对性的开源,虽然目前其开源项目并不多。以前Tesla涉及到云端服务的项目多用Ruby,但从2022年开始,Go语言的使用逐渐增多,包括前面提到的Fleet API的Fleet Telemetry的参考server实现以及Tesla车辆远控SDK

我们再来看看Apache基金会。众所周知,Apache基金会的开源项目多以Java语言为主,但一次偶然的机会翻看Apache基金会的github项目主页,我发现Go语言在Apache开源项目中已经悄悄地跻身到第五名,如果仅算后端语言的话,Go排名第三,仅次于Java和Python。

并且,Apache基金会下面的Go项目实际也不少,大家可以通过https://github.com/orgs/apache/repositories?language=go&type=all查询。其中还不乏优秀之作,比如:构建Q&A知识系统的answerApache Dubbo的go实现dubbo-goCDN实现trafficcontrolKubernetes原生的轻量级企业应用集成框架Camel KApache Arrow的Go实现以及针对开发过程的聚合数据平台devlake等。

我们知道:Apache项目在企业级应用和平台方面具有广泛的应用,从Go语言在Apache基金会项目中的使用比例的提升现象来看,Go在企业应用市场中的普及度和受欢迎程度确实有所增长。

2.2 Go语言排名

编程语言之间的竞争与争议,通常被称为“编程语言战争”(programming language war),它其实反映了不同技术群体和范式之间的碰撞。这些“火药味”比较浓的语言之争通常比较主观。近10年来,业界出现了一些被广泛接受的编程语言排行榜,它们基于一些相对客观的数据来反映不同编程语言在现实开发中的真实状态。但不同编程语言排行榜都有不同的数据来源和数据模型,单一的排行榜往往是“盲人摸象”,无法反映全貌。但目前又没有一个可以让我们一窥全貌的权威排行榜。因此,要想更客观地、更全面的反映一门编程语言的实际情况,我们需要将多个排行榜参照着看。

下面我们就来看看在目前世界上著名的编程语言排行榜上,Go语言在其中的最新排名情况(请注意:各个榜单的发布时间不同,导致各榜单的数据会有一定时间差)。

2.2.1 PYPL编程语言排行榜

PYPL编程语言流行指数是通过分析语言教程在谷歌上的搜索频率而创建的。语言教程被搜索的次数越多,说明该语言越受欢迎,原始数据来自Google Trends:


PYPL编程语言排行榜,数据时间:2023.12

2.2.2 IEEE Spectrum排行榜

IEEE Spectrum排行榜是通过调查来自全球软件工程师和招聘网站的数据,统计各语言的流行度的:


IEEE Spectrum排行榜,数据时间:2023.8

2.2.3 RedMonk编程语言排行榜

RedMonk排行榜是根据GitHub和Stack Overflow这两个开发者社区上的讨论数量来推算语言的受关注度。


RedMonk编程语言排行榜,数据时间:2023.5

2.3.4 Github Octoverse

GitHub Octoverse排行榜直观反映了过去一年GitHub上各编程语言的实际使用和流行趋势,是从开源项目量的维度来衡量编程语言活跃度的。在Top 10语言榜单上,2023年Go超越Ruby第一次跻身Github Top10语言:


Github Octoverse编程语言排行榜,数据时间:2023.11


Github Octoverse编程语言排行榜,数据时间:2023.11

2.3.5 Github Language Stats(githut)

Github Language Stats是一个个人项目,它基于github公开数据,按时间、pr数量、star数量等维度对各个语言在github上的使用情况进行分析:


Githut按PR数量,数据时间:2023第三季度


Githut按Star数量,数据时间:2023第三季度

2.3.6 TIOBE编程语言排行榜

TIOBE编程语言排行榜理论上来说,是世界上最知名的编程语言排行榜,它根据各大搜索引擎编程语言相关的搜索查询量来计算一个综合指数。但这些年TIOBE榜单数据的“上蹿下跳”,让开发者对该榜单是“又爱又恨”。下面是TIOBE index 2023年12月份的榜单:

当你看到Fortran排在Go的前面,你就get到该榜单的抽风式的“不靠谱”了:)。

综合上述6个榜单,我们可以看到Go语言的2023基本处于稳定发展状态,没有“大踏步”的前进,也没有意想不到的大幅退步。

今年在国内某乎上总有一些有关“Go在国内是否已凉”的话题,从上面实际情况来看,话题中那些抹黑Go的观点可以不攻自破了。有人会说Rust的强势上升对Go会有一定冲击,这的确不可否认,就像Go当年火速蹿升给Java带去一定冲击一样,这是一门编程语言在演进阶段必会经历的过程,没有什么值得大惊小怪的。5年后,Rust可能同样也会受到来自其他语言的冲击。

Go语言未来会变得如何,关键还要看Go团队对Go未来演进方向的把握是否得当以及Go社区与生态是否给力。2023年,Go团队也明确了未来的演进机制和策略,接下来我们就来看看。

3. Go的未来演进

2023年是Go语言开源的第14个年头,Go语言早已蜕下了少年期的青涩,进入到了青年期。这意味着它拥有了越来越成熟稳定的语言特性,同时生态系统也日益丰富完善。作为一门青壮年语言,Go语言在系统设计方面展现出的高度工程化思想,使其轻松应对复杂系统的构建。以go module为主的模块化支持帮助大规模程序更加清晰化,丰富的并发控制手段使其可以处理海量请求。与此同时,Go语言生态也在蓬勃成长——各种高质量框架应运而生,无数module可复用,大量的云原生组件可供选择。这为开发者极大减轻了从零开始搭建系统的工作量。

和我们人类一样,一门语言进入青年期后的成熟特征并不能完全掩饰其未来演进的迷茫!在Ken Thompson、Rob Pike相继退休后,Russ Cox成为了Go这艘大船的“掌舵者”,Russ Cox与Go团队对编程语言的思考,对Go语言价值观的判断将直接决定Go未来的航向。

好在,在2023年的GopherCon大会上,我们得到了Russ Cox的答案:那就是基于共同目标和数据驱动的决策。这里借用Russ Cox在演讲中给出的结论来看看具体的演进驱动机制:

  • 首先,Go需要不断变化,特别是随着计算世界的变化。
  • 其次,任何改变的目标都是为了使Go在软件工程中变得更好,尤其是在规模化(scaling)方面。
  • 第三,一旦我们确定了目标,达成共识的下一个最重要的部分是拥有共享数据来做出决策。
  • 第四,Go工具链遥测是增补我们现有调查和代码分析数据的重要数据来源。

综上来看,Go团队要“拥抱变化”,但不能“无头苍蝇”一样的胡乱改变,而是严谨地基于广泛的数据反馈,包括来自用户调查、vscode插件运行的用户反馈、全年进行的研究访谈和用户体验研究等,以及来自即将加入Go工具链的可选遥测(opt-in Telemetry)功能获取到的更多真实的Go使用数据。

相信在Go工具链的可选遥测(opt-in Telemetry)功能加入后,Go团队能基于这些用户数据拿到更准确地决策依据,继续让Go这艘大船行驶在正确、光明的航向上!

4. 小结

在2023年,Go语言继续保持了其稳定性和可靠性的特点。发布了两个大版本,Go 1.20和Go 1.21,其中语法特性的改变相对较少,注重修复和优化。然而,Go语言在其他方面仍然保持着求新和求变的态势。

Go语言团队致力于优化编译器、工具链、运行时和标准库,以提升生产力和运行时效率。引入了一些新的特性和优化措施,例如PGO(profile-guided optimization)技术的引入和优化、内存管理方面的改进等。同时,Go语言在软件工程领域也进行了一些创新,如简化项目创建的gonew工具、代码覆盖率的采集工具、供应链安全领域的govulncheck工具等。

Go语言始终保持对新技术、新趋势和社区的开放姿态。在2023年,Go语言对WASM和WASI的支持得到了进一步加强。同时,Go社区也积极响应并跟随Go团队的步伐,面对IT界出现的大语言模型等新兴技术,Go社区也在不断探索和应用。

总体而言,2023年对于Go语言来说是一个稳中求新、稳中求变的年份。Go语言保持着其简洁、高效和易用的特点,同时积极适应和采纳新的技术和需求,为开发者提供更好的开发体验和工具支持。

展望未来,Go团队已经明确了更加以共识和用户数据为驱动的演进机制,保证Go的发展方向与实际需求保持同步。随着可选的工具链遥测功能加入,相信他们能基于更丰富的用户数据做出更正确、更具预见性的正确决策。

我个人依旧坚持我之前的判断:Go将进入或已处于自己的黄金5-10年


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats