Go官方2022年开发者调查报告解读

点击上方蓝色“飞雪无情”关注我的公众号，设个星标，第一时间看文章

2022年9月8日，Go发布了他们的第2季度开发者调查报告，在这次报告中，他们调研了5752名开发者，主要采访他们关于泛型、安全工具和工作区这些Go语言新功能的感受。

主要发现

泛型已经被快速接纳。这一点应该在预料之中，因为Go泛型这个事情已经讨论了数年，并且也在Go 1.18之前发布了两个预览版本，大家都很期待。据调查显示，约有四分之一的受访者已经在实际代码中使用泛型。
Fuzzing对大家来说还比较新奇。模糊测试虽然也发布了，但是知名度远远不及泛型，这一点也很正常，开发者们只对「对自己有用」的更关心。
安全问题依然是第三方依赖中最大的问题。受访者担心的是如何避免那些含有安全漏洞的第三方依赖。这个的确是，我也有这种担心，毕竟一层层的依赖引入了太多的库，而且还有很旧的版本。所以受访者也希望工具能够尽可能的把安全问题检查出来，帮助开发者节省时间和精力。
发布工作还可以做的更好。这个其实就是好多开发者不知道Go发布了新版本，或者知道但是不知道新版本有哪些新特性，也不知道修复了哪些问题。所以Go社区表示会开拓新的Go取到，让大家更多的了解新版本的内容。其实就是多宣传Go
错误处理仍然是个难题。随着泛型的发布，受访者使用Go时面临的最大问题是如何处理错误。其实我觉得这从Go语言诞生就是个问题。

如何看这份调查结果

Go 社区是通过图表来解读这次调查的。这些图表格式都相同，标题部分是向受访者提出的具体问题。大部分问题都是单选题，也就是只能选一个，除非另有说明。图表的副标题部分是标注该问题是多选题还是开放性问题。对于开放性问题，回答各式各样，所以Go团队会挑选最具共性的前十大主题，其余主题会被归类为「其他」。

Go团队还使用了误差线让大家了解每条结论的证据权重，条形越窄，则表示信心越强。每个图表右下角还有个受访者人数，用"n=受访者人数"这样的形式表示。

泛型

泛型是Go 1.18发布的，在这次调查中，有86%的人都知道在这次发布中引入了泛型。有26%的受访者已经开始在代码中使用泛型，其中14%表示已经在生产中使用。54%的受访者并不抵触泛型，但是目前还没开始使用。还有8%的受访者想用但是还未付诸行动。

是什么阻止开发者使用泛型呢？大多数受访者表示就两个原因：

30%的受访者表示Go泛型有不少限制，比如不支持参数化方法、类型推断以及类型切换。
另一个原因是某些依赖还不支持泛型，比如linter，还有一些是在使用早期的Go版本。
还有26%的受访者说他们使用的Linux发行版还没提供Go 1.18，12%的说学习有点难度，文档也不充分就放弃了。当然，还有一些其他不太常见的原因，如下图所示。

Go团队进一步对使用泛型的受访者做更深的调查发现，有10%的受访者明确表示泛型的确可以简化代码，降低代码重复率。除了这些点赞的外，还有43%的受访者给予泛型积极评价，但是也有6%的受访者对泛型就没那么积极了，甚至是负面的。

安全

自从经历了2020年的SolarWinds漏洞后，安全软件开发再次受到关注。Go团队也在安全方面做了不少努力，包括建立配套的工具、模糊测试还有最近退出的漏洞扫描等。为了达成目标，本次调查特别问了关于软件开发安全实践相关问题，尤其是：

Go开发者目前使用哪些安全工具
Go开发者怎样发现和解决漏洞
如果要编写安全的Go软件，最大的挑战是什么？
调查显示，有65%的受访者使用静态分析工具，但是只有35%在使用这些工具发现了漏洞，还有33%的受访者以其他方式提升代码安全。

84%的受访者表示，这些安全工具会在CI/CD时使用，只有22%的受访者会在开发期间使用这些工具。

Go团队说这和他们进行的其他安全研究一致，也就是大多数安全扫描都在CI/CD阶段，但是这个时候有点晚了，应该在构建之前就知道依赖是否存在漏洞，新版本是否解决了这些漏洞，如果在CI阶段才做的话，隐患就很难清除了。

Go团队还问了受访者在开发安全软件的最大挑战是什么？有57%的受访者表示是第三方库，这个其实可以通过漏洞扫描器解决，比如dependabot或者Go自家的govulncheck。

模糊测试是一个提高程序安全的好办法，但是大家并不熟悉，也不怎么用。调查显示，只有12%的受访者在实际的工作中使用它们，5%的受访者已经在使用Go内置的模糊测试工具。

进一步问「为什么感觉模糊测试难以使用」时，有23%的受访者称不了解如何使用模糊测试，22%的受访者说没有时间进行模糊测试，14%的受访者说没法按计划进行模糊测试。这表明Go团队还需要投入更多的精力帮助开发者了解模糊测试的价值，模糊测试要做什么，以及如何使用它们。

为了更深的了解大家是如何检测漏洞，解决安全问题的，Go团队还询问受访者过去一年是否在自己的Go代码中发现过漏洞。如果发现的话，是如何发现的、怎么解决的，遇到的最大挑战是什么。

首先，Go团队发现，漏洞扫描的确很有用。四分之一的受访者表示从第三方库中发现了漏洞，但是实际使用漏洞扫描的只占三分之一。除了依赖和Go自身的漏洞外，有12%的受访者在自己的代码中发现了漏洞。

有65%的受访者表示，是通过安全扫描程序发现的漏洞。最常见的就是dependabot，占比38%，其他扫描程序加起来才有27%。除了扫描之外，发现漏洞的途径还有发布说明、CVE等。

在发现漏洞后，有67%是通过升级相关依赖解决漏洞。如果这些受访者使用了漏洞检测程序，那么升级依赖的比例则会上升到85%。此外，还有31%的受访者会阅读CVE或者漏洞报告，但是只有12%的受访者会进一步检查自己的软件是否会受影响，影响有多大。

深入调查程序各依赖安全问题是一个好的习惯，这会发现漏洞是否会带来风险，甚至数据泄露。所以Go团队设计了govulncheck这款工具，它能在检查代码，如果有漏洞会提醒开发者，并且会告诉开发者漏洞在代码中的位置。

工具

Go社区还调查了关于工具使用的相关问题，比如：

自上次调查依赖，编辑环境是否发生变化？
愿意使用工作区吗？如果愿意的话，在入门时会遇到哪些挑战？
开发如何处理内部包文档？
在受访者中，VS Code最受欢迎，今年的支持率已经从42%上升到了45%，并且还在继续上升。当然Goland也比较受欢迎，但是没有VS code多，而且这两款IDE在大企业、小公司都比较受欢迎，并没有受组织大小的影响，不过总的来说，VS Code更受业余开发者的偏爱。

此外，为了了解gopls的使用情况，Go团队专门统计了使用的编辑器支持gopls的受访者，发现只有2%的受访者禁用了这一功能，并且在VS Code中禁用比例更低，只有1%，这Go团队对gopls的表现信心更足。

在这次调查中，很多受访者并没有听说过工作区，甚至在这个调查的时候，才知道Go发布了工作区这项功能。使用VS Code的受访者中，有53%都没听说过工作区，Go团队把这个结果归结为他们宣传的还不充分，导致很多新功能不能传递给开发者。

在对工作区的使用做进一步调查时发现，有21%的受访者因为 go work 缺乏说明文档和有意义的错误提示消息不愿意使用它，排第一位；还有13%的受访者是因为要重构现有的项目才能使用工作区。其实就是工作区的使用门槛还是有点高，Go团队需要继续优化。

Go团队还调查了受访者在实际工作中使用Go文档的方式。结果显示，有81%的受访者是直接阅读代码，其中一半的人觉得这样挺好，但是也有39%的人认为如果有内部文档服务器会更好。

此外，Go团队还咨询了这类服务器应该由谁来维护，有三分之二的受访者表示应该是开发人员，剩下的三分之一认为需要专门的IT运维来维护。