取代泛型，错误处理成为新挑战，Go开发者Q2报告出炉

【CSDN 编者按】泛型一直是Go语言社区的焦点问题，在Go 1.18正式支持泛型开始，官方一直在推广该功能。据Go官方团队近日发布的2022年Q2 Go语言开发者调查报告显示，已有86%的开发者开始用泛型，比官方预期的要多一些。然而对于Go团队来说，挑战从未终止，该报告还揭示了他们面临的新挑战，不妨一起看下。

作者 | Todd Kulesza 编译 | 梦依丹

出品 | CSDN（ID：CSDNnews）

Go团队发布了Q2开发者调查报告，并感谢5752名用户参与对Go 1.18新功能的反馈，包括泛型、安全工具和工作区等。该报告的重点结论有：

泛型（Generics）已被迅速采用，绝大多数受访者都知道Go 1.18中引入了泛型功能，大约有四分之一的受访者开始使用该功能，但很明显，开发人员已经遇到了初始泛型实现的一些限制。对于大多数Go开发者来说，模糊测试（Fuzzing testing）还是新事物。受访者对Go的内置模糊测试的认识远低于泛型测试，他们对为何或何时考虑使用模糊测试有更多的不确定性。第三方依赖关系是一个最重要的安全问题。避免依赖已知的漏洞是受访者面临的最大安全相关挑战，更广泛地说，安全工作往往是无计划和无回报的，这意味着工具需要尊重开发者的时间和注意力。官方的新功能宣传还可以做的更好，与通过Go博客找到此次调查的人来比，随机抽样的参与者还不太知道最近的Go工具发布。这表明我们应该在博客文章之外寻找机会来交流Go生态系统的变化，或者扩大努力来更广泛地分享这些文章。错误处理仍然是一个挑战。在泛型的发布之后，受访者在使用Go时面临的最大挑战转为错误处理。总体来说，受访者对Go的满意度仍然很高，受访者使用Go的方式没有发生明显变化。

开发者对泛型的反馈

在Go 1.18添加泛型支持以后，我们想了解一下大家对该功能的使用情况以及遇到的常见问题与挑战有哪些。

调查显示，有86%的用户知道Go已经支持泛型，这比官方预期的人数要多的多。26%的受访者已经在Go代码中使用泛型，这包括14%的人已经在生产或者发布版本中添加泛型代码；54%的人不反对使用泛型，但目前没有该方面的需求，此外，还有8%的用户希望在Go中使用泛型，但目前遇到了一些阻碍。

阻碍开发者使用泛型的因素有哪些呢？大多数受访者属于如下两类中的一类。

首先，30%的受访者表示，他们遇到了当前泛型实现的限制，例如想要参数化的方法、改进的类型推理，或者在类型上进行切换。受访者说，这些问题限制了泛型的潜在用例，或者认为它们使泛型代码变得不必要地冗长。第二类是依赖于不支持泛型的东西——linters是最常见的阻碍采用泛型的工具，但这个列表也包括一些东西，如组织仍在使用早期的Go版本或依赖于尚未提供Go 1.18软件包的Linux发行版（26%）。

12%的受访者提到了学习曲线过长或缺乏有用的文档。除了这些最重要的问题之外，受访者还表达了一系列不太常见的（但仍有意义的）挑战，如下图所示。为了避免关注假设，本分析只包括那些说他们已经在使用泛型的人，或者那些试图使用泛型但被某些东西阻挠的人。

与此同时，我们也关注使用泛型开发者的实际体验与反馈，令人兴奋的是，有十分之一的受访者表示，泛型简化了他们的代码，或者减少了代码的重复。最常见的反馈 "谢谢你！"或一般的还不错（43%）；相比之下，只有6%的受访者表现出消极的反应或情绪。与上述 "最大的挑战 "问题的发现相呼应，近三分之一的受访者讨论了Go实现泛型的限制。Go团队正在使用这组结果来帮助决定是否或如何放宽其中的一些限制。

安全问题很重要，但往往是开发者无计划和无回报的工作

继2020年发生SolarWinds漏洞事件之后，安全软件开发方法再次收到关注。Go团队已把安全相关的工作列为优先事项，包括创建软件材料清单（SBOM）工具、模糊测试，以及最近的漏洞扫描。为了支持这些工作，本次调查提出了几个关于软件开发安全实践和挑战方面的问题。

Go开发人员目前使用哪些类型的安全工具？Go开发人员是如何发现和解决漏洞的？编写安全Go软件的最大挑战是什么？结果表明，虽然静态分析工具被广泛使用（65%的受访者），但只有少数受访者使用它来寻找漏洞（35%）或以其他方式提高代码安全性（33%）。受访者表示，安全工具主要运行在CI/CD时间。只有少数人会在开发者期间在本地运行这些工具（22%）。这与官方团队进行的其他安全研究相一致，在CI/CD时间进行安全扫描为软件安全提供了一个后盾作用，但其实来说，这已经太晚了。开发者更希望在构建依赖关系之前就做好漏洞扫描、可能存在的漏洞，或者验证一个版本的更新解决了一个漏洞，而不用等待CI对他们的PR运行一整套额外的测试。

对于开发者来说，进行软件安全开发最大的挑战是什么？目前最广泛的回答是评估第三方库的安全性（57%），该问题通过漏洞扫描器（如GitHub的dependabot或Go团队的govulncheck）就可以很好地解决。其它回答则为新的安全工具提供了机会，受访者表示，他们在编写代码和验证时，很难找到有什么最佳应用能监测出代码是否有漏洞。

模糊测试是提供应用程序安全性另一种方法，但对大多数受访者来说仍然相当陌生。只有12%的人表示，他们在工作中使用它，5%的人说他们已经采用了Go的内置模糊测试工具。

模糊测试为何会如此难以使用，通过开放性的问题发现，主要原因并不是技术问题：前三个回答讨论了不了解如何使用模糊测试（23%），缺乏时间用于模糊测试或更广泛的安全（22%），以及了解为什么和何时开发人员可能想要使用模糊测试（14%）。这些发现表明，在宣传模糊测试的价值、模糊测试应该应用在哪些地方以及如何将其应用于各种不同的代码库方面，我们仍有工作要做。

为了更好地了解有关漏洞检测和解决的常见任务，我们询问受访者在过去一年中是否了解到他们的Go代码或其依赖的任何漏洞。漏洞是如何被发现的，他们是如何调查和解决这些问题的，以及整个过程中的挑战是什么？

首先，有证据表明漏洞扫描是有效的。有四分之一的受访者在第三方依赖中发现了漏洞，但只有三分之一的人在使用漏洞扫描，所以，在该群体中再统计使用漏洞扫描器时，该比例就从25%上升到了46%。除了依赖关系或Go本身的漏洞，12%的受访者说他们从自己的代码中了解到了漏洞。

有65%的受访者表示，他们是通过安全扫描器了解到漏洞，受访者最常引用的工具是GitHub的dependabot（38%）。除此以外，最常见的了解漏洞的方法是公共报告，如发行说明和CVEs（22%）。

当知道有漏洞之后，开发者都是怎么解决的呢？调查显示，最常见的解决方法是升级有漏洞的依赖关系（67%），在使用漏洞扫描器群体中，该比例提高到了85%。不到三分之一的受访者会阅读CVE或查看漏洞报告（31%）。

只有12%的受访者谈到，要深入调查漏洞的背后，以了解他们的软件是否（以及如何）受到漏洞或者对服务器会产生潜在的影响。为了深入理解，我们还研究了受访者应对漏洞安全的最大挑战是什么？

他们的回答可以概况为几个不同的主题，从确保依赖性更新不会破坏任何东西，到了解如何通过go.mod文件更新间接依赖性。还有了解漏洞的影响或根本原因所需的调查类型。然而，当我们关注哪些调查研究漏洞产生的具体原因的那个群体时，我们看到了一个明显的关联性。70%的受访者说他们对漏洞的潜在影响进行了调查，他们认为这是这个过程中最具挑战性的部分。原因不仅包括任务的难度，还包括这往往是既无计划又无回报的工作。

Go团队认为，对程序漏洞进行深入的调查的行为，将直接决定漏洞对团队带来的实际影响，包括是否发生了数据泄露或其他安全等。因此，我们设计了govulncheck，只在漏洞被调用时提醒开发者，并指出开发者在其代码中使用漏洞函数的确切位置。我们的希望是，这将使开发人员更容易快速调查应用程序的真正的重要漏洞所在，从而减少这一领域的整体非计划性工作的数量。

工具篇：随机受访者更喜欢VS Code

接下来又调查了工具方面的问题：

自我们上次调查以来，编辑器环境是否发生了变化？开发人员是否使用了工作空间？如果用了，他们在入手时，遇到了哪些挑战？开发者是如何处理内部包文件的？VS Code使用者比例还在增长。自2021年以来，受访者的首选Go代码编辑器的比例从42%增加到45%。VS Code和GoLand这两个最受欢迎的编辑器，两者在小型和大型组织之间的受欢迎程度没有差异，但业余开发者更倾向于VS Code。这项分析不包括随机抽样的VS Code受访者——我们期望邀请的人对用于分发邀请的工具表现出偏好，这正是我们看到的（91%的随机抽样受访者更喜欢VS Code）。

在2021年通过gopls语言服务器为VS Code的Go支持提供动力之后，Go团队一直想了解与gopls有关的开发者痛点。虽然我们从目前使用gopls的开发者那里收到了大量的反馈，但我们想知道是否有很大一部分开发者在发布后不久就禁用了它，这可能意味着我们没有听到关于特别有问题的用例的反馈。为了回答这个问题，我们询问了那些说他们更喜欢支持gopls的编辑器的受访者是否使用gopls，发现只有2%的人说他们禁用了gopls；具体到VS Code，这个比例下降到1%。这增加了我们的信心，我们听到的是一群有代表性的开发者的反馈。对于那些对gopls仍有未解决的问题的读者，请在GitHub提交反馈，好让我们知道（https://github.com/golang/go/issues）。

关于工作区，似乎很多人是通过这次调查第一次了解到Go对多模块工作区的支持。对VS Code的随机调查显示，大部分受访者没有听说过工作区，在随机抽样的受访者中占比53%，自荐受访者占比33%。对于泛型的认识趋势，两个群体的认知趋势都比较高，随机抽样占68%，自荐受访者占93%。

至于原因，可行的解释是，我们目前的Go博客或现有的社交媒体渠道还不足以接触到所有的Go开发者，导致许多新功能无法及时让用户知道。

我们发现，9%的受访者表示他们已经尝试过工作区，还有5%的受访者想尝试，但没有成功。受访者讨论了在尝试使用Go工作区时遇到的各种挑战。缺乏文档和go work命令的有用错误信息位居榜首（21%），其次是技术上的挑战，如重构现有的资源库（13%）。与安全部分所讨论的挑战类似，也有人给出了"缺乏时间/不是优先事项"，我们将其理解为，与工作区提供的好处相比，理解和设置工作区的门槛仍然有点太高，可能是因为开发人员已经有了变通办法。

在Go模块发布之前，组织能够运行内部文档服务器（例如支持 godoc.org 的服务器），为员工提供内部Go包的文档。pkg.go.dev依然如此，但建立这样的服务器比以前更复杂了。

为了解开发者是否希望官方团队对这方面进行更多投资时，我们询问了受访者如何看待内部Go模块文档，以及他们首选的工作方式。

结果显示，最常见的查看内部Go文档的方式是阅读代码（81%），虽然约有一半的受访者对此感到满意，但有很大一部分人希望有一个内部文档服务器（39%）。

谁最有可能配置和维护这样一个服务器：软件工程师以2比1的结果胜出，而不是专门的IT支持或运营团队的人。这强烈地表明，文档服务器应该是一个交钥匙的解决方案，或者至少对单个开发人员来说容易快速运行，不会带来额外的工作负担。

一半用户有两年以上Go开发经验

整体而言，自2021年调查以来，受访者的用户画像没有太多变化。

部分受访者（53%）有至少两年的Go使用经验，其余受访者则是Go社区的新成员。约三分之一的受访者在小型企业（<100名员工）工作，四分之一的受访者在中型企业（100-1000名员工）工作，四分之一在大型企业（>1000名员工）工作。与去年类似，我们发现VS Code上的调查弹窗更容易吸引北美和欧洲以外的开发者参与。

开发者如何使用Go语言

调查发现，开发者使用Go语言的方式与以往统计没有什么同比变化，最常见的依然是构建API/RPC服务（73%）和编写CLI（60%）。我们使用线性模型来研究受访者使用Go的时间长短与用Go构建的事物类型之间是否存在关系。结果发现，拥有<1年Go经验的受访者更有可能正在构建该图表下半部分的东西（GUI、IoT、游戏、ML/AI或移动应用程序），这表明人们对在这些领域使用Go有兴趣，但一年经验后的下降也意味着开发人员在这些领域使用Go时遇到重大障碍。

感受与挑战

最后，我们访问了受访者在过去一年对Go的总体满意程度以及他们在使用Go语言时的最大挑战，93%的受访者表示还行（30%）或者非常满意（63%），与2021年的92%的受访者表示满意没有差异。

多年以来，泛型一直是Go最常讨论的话题，目前在Go 1.18中提供了泛型支持。与此同时，又迎来的一个新的挑战，错误处理。可以肯定的是，错误处理与其它挑战是并列的，如库缺失或不够成熟、帮助开发者学习或实施的最佳实践、对类型系统的其他修订，如支持枚举或更多的函数式编程语法。在泛型之后，Go开发者面临的挑战依然还有一段路要走。

总结

本次Go开发者调查的重点是Go 1.18版本的新功能。泛型采用要比官方预期好的多，模糊测试和工作区采用进展较慢，但与技术原因无关。慢的主要原因是开发者不知何时以及如何使用它们，另一个挑战是开发者没有时间专注在这些主题上，该挑战也提现在安全工具上。这些发现正在帮助Go团队确定下一步工作的优先次序，并将影响我们对未来工具设计的态度。

最后，感谢大家加入Go开发者之旅，感谢对本次调查做出回应的每个人。您的反馈帮助我们了解Go开发者在工作中受到的限制，并确定他们面临的挑战。通过分享，将有助于为每位开发者改善Go语言生态，仅此代表世界各地的Goer们，谢谢你！

报告原文：https://go.dev/blog/survey2022-q2-results