Go语言“十诫”[译]

最新推荐文章于 2024-11-09 12:43:52 发布

Tony Bai

最新推荐文章于 2024-11-09 12:43:52 发布

阅读量4.5k

点赞数 1

分类专栏：技术前沿文章标签： java python 编程语言 go 数据库

本文链接：https://blog.csdn.net/bigwhite20xx/article/details/115562167

版权

技术前沿专栏收录该内容

2 篇文章 0 订阅

订阅专栏

本文翻译自John Arundel的《Ten commandments of Go》[1]。全文如下：

作为一名全职的Go语言作家[2]和老师[3]，我花了很多时间和学生们一起，帮助他们写出更清晰、更好、更有用的Go程序。我发现，我给他们的建议可以归纳总结为一套通用原则，在这里我将这些原则分享给大家。

1. 你应该是无聊的

Go社区喜欢共识(consensus)。比如：Go源代码有一个由gofmt强制执行的统一的代码格式规范。同样，无论你要解决什么问题，通常都有一个标准的、类似于Go行事风格的方法来解决。有时它是标准的方式，因为它是最好的方式，但通常它只是最好的方式，因为它是标准的方式。

要抵制住创意、时尚或（最糟糕的是）聪明的诱惑，这些不是Go的行事风格。Go行事风格的代码简单、无聊，通常相当啰嗦，而且最重要的是显式的风格(由于这个原因，有些人把Go称为面向显式(obviousness-oriented)风格的编程语言)。

当有疑问时，请遵循最小惊喜原则[4]。争取做到一目了然[5]。要直截了当，要简单，要显式，要无聊。

这并不是说在软件工程层面没有展示令人叹为观止的优雅和风格的空间了；当然有。但那是在设计层面上，而不是单个代码行。代码并不重要，它应该以被随时替换。重要的是程序。

2. 你应该以测试为先

在Go中，一个常见的错误是先写了一些函数(比如：GetDataFromAPI)，然后在考虑如何测试它时不知所措。函数通过网络进行了真正的API调用，它向终端打印东西，它写磁盘文件了，这是一个可怕的的不可测试性的坑。

不要先写那个函数，而是先写一个测试(比如：TestGetDataFromAPI)。如何写这样一个测试呢？它必须为函数的调用提供一个本地的TLS测试服务器，所以你需要一种方法来注入这种依赖。它要写数据到io.Writer，你同样需要为此注入一个模拟外部世界的本地依赖，比如：bytes.Buffer。

现在，当你开始编写GetDataFromAPI函数时，一切都将变得很容易了。它的所有依赖关系都被注入，所以它的业务逻辑与它与外部世界的交互和监听方式完全脱钩。

HTTP handler也是如此。一个HTTP handler的唯一工作是解析请求中的数据，将其传递给某个业务逻辑函数来计算结果，并将结果格式化到ResponseWriter。这几乎不需要测试，所以你的大部分测试将在业务逻辑函数本身，而不是handler。我们知道HTTP的工作原理。

3. 你应该测试行为，而不是函数

如果你想知道如何在不实际调用API的情况下测试这个函数，那么答案很简单："不要测试这个函数"。

你需要测试的不是一些函数，而是一些行为。例如，一个可能是"给定一些用户输入，我可以正确地组合URL并以正确的参数调用API。" 另一个可能是"给定API返回的一些JSON数据，我可以正确地将其解包到某个Go结构体中。"

当你沿着这样的思路考量问题的解决方法的时候，写测试就容易多了：你可以想象一些这类函数，它们每个函数都会接受一些输入，并产生一些输出，并且很容易给它们编写单元测试。有些事情它们是不会做的，例如进行任何HTTP调用。

同样，当你试图实现"数据可以持久地存储在数据库中并从数据库中检索"这样的行为时，你可以将其分解成更小的、更可测试的行为。例如，"给定一个Go结构体，我可以正确地生成SQL查询，并将其内容存储到Postgres表中"，或者 "给定一个对象，我可以正确地将结果解析到Go结构体切片中"。不需要mock数据库，不需要真正的数据库！

4. 你不应制造文书工作

所有的程序都会在某一点上涉及到一些繁琐的、不可避免的数据倒换重组活动；我们可以把所有这类活动归入文书工作的范畴。对程序员来说，唯一的问题是，这些文书工作在API边界的哪一边？

如果是放在用户侧，那就意味着用户必须编写大量的代码来为你的库准备文书工作，然后再编写大量的代码来将结果解压成有用的格式。

相反(将文书工作放在API实现侧)，写零文书工作的库，可以在一行中调用：

game.Run()

不要让用户调用一个构造函数来获取某个对象，然后再基于这个对象进行方法调用。那就是文书工作。只要让一切在他们直接调用时发生就可以了。如果有可配置的设置，请设置合理的默认值，这样用户根本不用考虑，除非他们因为某些原因需要覆盖默认值。功能选项(functional option)[6]是一个很好的模式。

这是另一个先写测试的好理由，如果你写的API中创造了文书工作，那么在测试时你将不得不自己做所有的文书工作，以便使用你自己的库。如果这被证明是笨拙、啰嗦和耗时的，可以考虑将这些文书工作移到API边界内。

5. 你不应该杀死程序

你的库没有权利终止用户的程序。不要在你的包中调用像os.Exit、log.Fatal、panic这样的函数，这不是你能决定的。相反，如果你遇到了不可恢复(recover)的错误，将它们返回给调用者。

为什么不呢？因为它迫使任何想使用你的库的人去写代码，不管panic是否真的被触发。出于同样的原因，你永远不应该使用会引起panic的第三方库，因为一旦你用了，你就需要recover它们。

所以你千万不要显式调用(这些可以杀死程序的函数)，但是隐式调用呢？你所做的任何操作，在某些情况下可能会panic（比如：索引一个空的片断，写入一个空map，类型断言失败）都应该先检查一下是否正常，如果不正常就返回一个错误。

6. 你不要泄露资源

对于一个打算永远运行而不崩溃或出错的程序来说，对其的要求要比对单次命令行工具要严格一些。例如，想想太空探测器：在关键时刻意外重启制导系统，可能会让价值数十亿美元的飞行器驶向星系间的虚空。对于负责的软件工程师来说，这很可能会导致一场没有咖啡的面谈，让人有些不舒服。

我们不是都在为太空器写软件，但我们应该像太空工程师一样思考。自然，我们的程序应该永远不会崩溃（最坏的情况下，它们应该优雅地退化，并提出退出过程的详实信息），但它们也需要是可持续的。这意味着不能泄露内存、goroutines、文件句柄或任何其他稀缺资源。

每当你有一些可泄漏的资源时，当你知道你已经成功获得它的那一刻，你应该想着释放它。无论函数如何退出或何时退出，保证将其清理掉，我们可以用Go带给我们的礼物：defer[7]。

任何时候启动一个goroutine，你都应该知道它是如何结束的。启动它的同一个函数应该负责停止它。使用waitgroups或者errgroups，并且总是向一个可能被取消的函数传递一个context.Context。

7. 你不应该限制用户的选择

我们如何编写友好、灵活、强大、易用的库呢？一种方法是避免不必要地限制用户对库的操作。一个常见的Gopherism(Go主义)是 "接受接口，返回结构"。但为什么这是个好建议呢？

假设你有一个函数，接受类似于一个*os.File的参数，并向其写入数据。也许被写入的东西是一个文件并不重要，具体来说，它只需要是一个 "你可以写入的东西"（这个想法由标准库接口，如io.Writer表达）。有很多这样的东西：网络连接、HTTP response writer、bytes.Buffer等等。

通过强迫用户传递给你一个文件，你限制了他们对你的库的使用。通过接受一个接口(如 io.Writer)来代替，你将打开新的可能性，包括尚未被创造的类型，后续它们仍然可以满足(接口) ，可以与你的代码io.Writer一起工作。

为什么要 "返回结构体"？好吧，假设你返回一些接口类型。这极大地限制了用户对该值的操作（他们能做的就是调用其上的方法）。即使他们事实上可以用底层的具体类型做他们需要做的事情，他们也必须先用类型断言来解包它。换句话说，这就是额外的文书工作(应该避免)。

另一种避免限制用户选择的方法是不要使用只有当前Go版本才有的功能。相反，考虑至少支持最近两个主要的Go版本：有些人不能立即升级。