go语言设计模式案例分析 go语言设计模式pdf( 六 )


Gofmt 是一个很棒的命令行实用程序,内置在 Go 编译器中,用于格式化代码 。就功能而言,它与 Python 的 autopep8 非常相似 。我们大多数人并不真正喜欢争论制表符与空格 。格式的一致性很重要,但实际的格式标准并不那么重要 。Gofmt 通过使用一种正式的方式来格式化您的代码来避免所有这些讨论 。
Go 对协议缓冲区和 gRPC 具有一流的支持 。这两个工具非常适合构建需要通过 RPC 通信的微服务 。您只需要编写一个清单,在其中定义可以进行的 RPC 调用以及它们采用的参数 。然后从这个清单中自动生成服务器和客户端代码 。生成的代码既快速又具有非常小的网络占用空间并且易于使用 。从同一个清单中 , 您甚至可以为许多不同的语言生成客户端代码,例如 C++、Java、Python 和 Ruby 。因此,内部流量不再有模棱两可的 REST 端点,您每次都必须编写几乎相同的客户端和服务器代码 。.
Go 没有像 Rails 用于 Ruby、Django 用于 Python 或 Laravel 用于 PHP 那样的单一主导框架 。这是 Go 社区内激烈争论的话题,因为许多人主张你不应该一开始就使用框架 。我完全同意这对于某些用例是正确的 。但是,如果有人想构建一个简单的 CRUD API , 他们将更容易使用 Django/DJRF、Rails Laravel 或Phoenix 。对于 Stream 的用例 , 我们更喜欢不使用框架 。然而,对于许多希望提供简单 CRUD API 的新项目来说,缺乏主导框架将是一个严重的劣势 。
Go 通过简单地从函数返回错误并期望调用代码来处理错误(或将其返回到调用堆栈)来处理错误 。虽然这种方法有效,但很容易失去问题的范围 , 以确保您可以向用户提供有意义的错误 。错误包通过允许您向错误添加上下文和堆栈跟踪来解决此问题 。另一个问题是很容易忘记处理错误 。像 errcheck 和 megacheck 这样的静态分析工具可以方便地避免犯这些错误 。虽然这些变通办法效果很好,但感觉不太对劲 。您希望该语言支持正确的错误处理 。
Go 的包管理绝不是完美的 。默认情况下,它无法指定特定版本的依赖项,也无法创建可重现的构建 。Python、Node 和 Ruby 都有更好的包管理系统 。但是,使用正确的工具,Go 的包管理工作得很好 。您可以使用Dep来管理您的依赖项,以允许指定和固定版本 。除此之外,我们还贡献了一个名为的开源工具VirtualGo , 它可以更轻松地处理用 Go 编写的多个项目 。
我们进行的一个有趣的实验是在 Python 中使用我们的排名提要功能并在 Go 中重写它 。看看这个排名方法的例子:
Python 和 Go 代码都需要执行以下操作来支持这种排名方法:
开发 Python 版本的排名代码大约花了 3 天时间 。这包括编写代码、单元测试和文档 。接下来,我们花了大约 2 周的时间优化代码 。其中一项优化是将分数表达式 (simple_gauss(time)*popularity) 转换为抽象语法树. 我们还实现了缓存逻辑,可以在未来的特定时间预先计算分数 。相比之下,开发此代码的 Go 版本大约需要 4 天时间 。性能不需要任何进一步的优化 。因此,虽然 Python 的最初开发速度更快,但基于 Go 的版本最终需要我们团队的工作量大大减少 。另外一个好处是,Go 代码的执行速度比我们高度优化的 Python 代码快大约 40 倍 。现在,这只是我们通过切换到 Go 体验到的性能提升的一个示例 。
与 Python 相比,我们系统的其他一些组件在 Go 中构建所需的时间要多得多 。作为一个总体趋势,我们看到开发Go 代码需要更多的努力 。但是,我们花更少的时间优化代码以提高性能 。
我们评估的另一种语言是Elixir. 。Elixir 建立在 Erlang 虚拟机之上 。这是一种迷人的语言,我们之所以考虑它,是因为我们的一名团队成员在 Erlang 方面拥有丰富的经验 。对于我们的用例,我们注意到 Go 的原始性能要好得多 。Go 和 Elixir 都可以很好地服务数千个并发请求 。但是,如果您查看单个请求的性能,Go 对于我们的用例来说要快得多 。我们选择 Go 而不是 Elixir 的另一个原因是生态系统 。对于我们需要的组件,Go 有更成熟的库,而在许多情况下,Elixir 库还没有准备好用于生产环境 。培训/寻找开发人员使用 Elixir 也更加困难 。这些原因使天平向 Go 倾斜 。Elixir 的 Phoenix 框架看起来很棒,绝对值得一看 。

推荐阅读