9月8日，Go语言社区发布了2022年第二季度的开发者调查报告。本次调查涵盖了5,752名受访开发者，主题涉及他们对Go1.18新特性的使用情况当涉及到功能时，包括泛型、安全工具和工作区，这是一个真实的感受，以下是这份报告的主要内容。主要发现是仿制药得到了迅速采用。大多数受访者都知道Go1.18中引入了泛型，大约四分之一的受访者表示在他们的实际代码中使用了泛型。大多数开发人员对泛型的发布表示赞赏，但一些受访者发现当前的泛型设计限制太多。模糊测试对于大多数Go开发人员来说仍然是新事物。较新版本的Go中内置的模糊测试远不如泛型广为人知，受访者不确定为什么或何时需要模糊测试。第三方依赖成为最重要的安全问题。目前，受访者将如何避免包含已知漏洞的依赖项列为最大的安全挑战。总的来说，安全工作往往缺乏计划，也没有明确的回报，所以工具开发者应该尽量自查自查，帮助开发者节省时间和精力。我们的新功能发布可以做得更好。关注Go官方博客的开发者普遍更熟悉新版本的变化，但随机抽取的受访者对最新版本的了解程度较低。因此，我们要么在博文之外开辟新的围棋生态新闻频道，要么更加努力地广泛分享博文内容。错误处理仍然是一个挑战。随着泛型的发布，受访者在使用Go时面临的最大挑战变成了如何处理错误。总体而言，对Go语言的满意度仍然很高，我们发现受访者使用Go的方式没有显着变化。解释调查结果在本文中，我们将通过一系列图表来解释调查。所有图表都遵循相同的格式，标题指向向受访者提出的具体问题。如无特殊说明，每题均为单选题，受访者只能选择其中一项。在图表的副标题部分，会标注是选择题还是开放题。对于开放性问题，Go团队成员仔细阅读并手动整理了受访者的回答。对这些类型问题的回答各不相同，因此我们选择了最共性的前十个主题，其余归类为“其他”。为帮助您了解每个结论的证据权重，我们使用误差条表示响应的95%置信区间：条越窄表示置信度越高。有时，多个响应意见的误差条可能相互重叠，这意味着响应的相对顺序在统计上不显着（或者意见相互绑定）。每个图表的右下角是图表中的受访者人数，形式为“n=受访者人数”。随着支持类型参数（即泛型）的Go1.18的发布，对于泛型，我们想看看这个新特性是如何被感知和采用的，并找出使用泛型时常见的挑战或障碍。绝大多数受访者(86%)都知道Go1.18版本引入了泛型。虽然我们预计这个百分比会超过一半，但我们没想到会这么高。我们还发现，大约四分之一的受访者已经开始在Go代码中使用泛型(26%)，其中14%的人表示他们在生产或发布的代码中使用它们。大多数受访者(54%)并不反对仿制药，他们只是还没有开始使用仿制药。**另有8%的受访者对在Go中使用泛型感兴趣，但由于各种原因推迟了。是什么阻止了一些开发人员使用泛型？困扰大多数受访者的原因其实有两个：首先，30%的受访者表示，他们发现现有的泛型实现仍然存在很多局限性，例如不支持参数化方法、类型推断和类型切换。受访者指出，这些问题限制了泛型的可用空间或导致泛型代码过于冗长。第二个原因是某些依赖项尚不支持泛型——最显着的是linters，还有仍在使用的早期Go版本，或尚未提供Go1.18包(26%)版本等的Linux发行版等。12%的受访者选择放弃是因为学习曲线陡峭或文档不足。除了这些重要因素外，受访者还报告了一些相对不常见的障碍，但仍有意见，如下图所示。在这里，我们只列出已经在使用仿制药，或尝试使用仿制药但未成功的受访者。我们还询问了尝试过仿制药的受访者，了解他们的感受。令人鼓舞的是，10%的受访者表示泛型确实简化了他们的代码并减少了代码重复。除了高度赞赏之外，其他受访者也普遍(43%)对仿制药给予正面评价；相比之下，只有6%的人表达了对仿制药的负面评论或感受。与前面提到的使用挑战类似，近三分之一的受访者表示Go对泛型的实现限制太多。Go团队正在参考这些结果研究是否以及如何放宽这些限制。安全性在2020年发生SolarWinds漏洞之后，安全的软件开发实践再次成为人们关注的焦点。Go团队还优先考虑安全性，包括用于构建软件物料清单(SBOM)、模糊测试以及最近的漏洞扫描的工具。为了实现其目标，该调查特别询问了有关软件开发安全实践和挑战的问题，特别是：Go开发人员目前使用哪些类型的安全工具？Go开发者如何发现和修复bug？编写安全的Go软件的最大挑战是什么？调查结果表明，虽然静态分析工具被广泛使用(65%)，但只有少数受访者使用它们来查找漏洞(35%)或以其他方式提高代码安全性(33%)。受访者表示安全工具主要在CI/CD过程中运行(84%)，只有少数开发人员在开发过程中运行这些工具(22%)。这与我们团队所做的其他安全研究一致，其中安全扫描主要集中在CI/CD期间，此时关注安全问题为时已晚。更理想的做法应该是在构建之前知道依赖是否存在漏洞，并验证版本更新是否解决了这些漏洞。等到CI对PR进行全测时，隐患往往很难消除。我们还向受访者询问了他们在安全开发软件方面面临的最大挑战。迄今为止最常见的挑战是如何评估第三方库的安全性(57%)，而GitHub的dependabot或Go团队的govulncheck等局部漏洞扫描器可以很好地完成这项工作。其他反馈为新工具提供了空间：受访者表示，他们在编写代码和验证错误结果时，常常难以始终遵循最佳实践。模糊测试是提高应用程序安全性的另一种好方法，但大多数受访者似乎并不熟悉它。只有12%的受访者实际在工作中使用过模糊测试，5%的人表示他们已经在使用Go内置的模糊测试工具。在“为什么觉得fuzzing难用”这一开放式问题中，我们发现影响最大的非技术因素：前三位的回答分别是“我不知道如何使用fuzzing”（23%）、“我没有时间进行模糊测试或其他安全工作”（22%），“未能以预期的方式和时间进行模糊测试”（14%）。这些发现表明我们仍然需要投资帮助开发人员了解价值模糊测试，测试什么，以及如何将其应用于不同的代码库。为了更好地了解人们如何检测漏洞和解决常见的安全任务，我们询问了受访者在过去一年中是否在他们的Go代码或依赖项中发现了漏洞。对于回答是的受访者，我们进一步询问了漏洞当时是如何发现的，如何调查和/或解决的，过??程中哪些部分最困难等问题。首先，我们发现漏洞扫描确实有效。四分之一的受访者报告发现了来自第三方依赖项的漏洞。但是只有三分之一的受访者实际使用了漏洞扫描，所以当我们将依赖漏洞添加到这一组时，我们发现结果翻了一番，从25%到46%。除了Go本身的依赖和漏洞，12%的受访者表示他们在自己的代码中发现了漏洞。大多数受访者(65%)表示他们发现的漏洞源自安全扫描程序。受访者最常用的工具是GitHub的dependabot(38%)，使用次数超过所有其他漏洞扫描程序的总和(27%)。除了扫描之外，受访者了解漏洞的其他常见方式包括发布说明和CVE(22%)等公开报告。在意识到漏洞后，受访者中最常见的修复(67%)是升级相应的依赖项。在那些使用专门设计用于检测第三方依赖项漏洞的漏洞扫描器的人中，选择升级依赖项的比例上升到85%。近三分之一的受访者阅读了CVE或漏洞报告(31%)，只有12%的受访者进一步调查以了解他们的软件是否受到影响以及如何受到影响。只有12%的受访者表示他们会进一步调查代码漏洞的潜在影响，这一比例低得惊人。为了获得更多细节，我们还询问了受访者他们在处理漏洞时面临的挑战。几个主要答案的比例基本持平，包括担心依赖更新会影响代码执行，以及通过go.mod文件更新间接依赖的难度。我们还询问了一般使用哪种调查方法来了解漏洞的影响或探究根本原因，愿意进一步调查的12%的受访者给出了更积极的回答：其中70%调查了漏洞的潜在影响漏洞，并发现这是整个过程中最难的部分。除了调查本身的难度外，他们还提到，这项工作往往不在项目计划中，根本没有直接的回报。Go团队认为，这种深入调查应用程序中每个依赖项的安全态势的好习惯，将直接决定漏洞可能给组织带来的实际风险，甚至是否会发生数据泄露。因此，我们设计了govulncheck来在调用的函数存在漏洞时提醒开发者，并列出该函数在代码中的确切位置。希望该工具能够帮助开发者快速排查应用程序中的致命漏洞，减轻计划外安全工作的负担。工具体验接下来，我们又问了一个关于工具体验的问题：自上次调研以来，编辑环境有没有变化？开发人员愿意使用工作空间吗？如果有，您在刚上手时有哪些不便之处？开发人员如何处理内部包文档？VSCode似乎在受访者中越来越受欢迎。受访者将其评为自2021年以来最受欢迎的GO代码编辑器，今年的支持率从42%上升到45%。VSCode和GoLand这两个最受欢迎的编辑器，似乎不受组织规模的影响，在大公司和小公司都流行。但从统计结果来看，业余开发者似乎更喜欢VSCode。在2021年通过gopls语言服务器加强了VSCode的Go支持能力后，Go团队一直想了解gopls存在哪些痛点。虽然我们收到了来自开发人员的大量反馈，但尚不清楚是否有许多开发人员只是简单地禁用了该功能。为了收集对gopls的负面意见，我们专门统计了其编辑支持gopls的受访者（无论他们是否实际使用gopls），发现其中只有2%的人禁用。在VSCode上，禁用率下降到1%。这让我们对gopls的性能更有信心，也期待在GitHub上提交更多关于gopls的问题。在工作空间方面，许多受访者似乎只是在本次调查中才了解到Go对多模块工作空间的支持。一项针对VSCode用户的随机调查显示，大多数受访者从未听说过Workspaces（53%的随机样本受访者和33%的自荐受访者）。事实上，两组受访者对仿制药的认知和接受度差异也非常明显，分别为93%和68%。也许是因为我们目前的Go博客或社交媒体渠道没有覆盖足够多的Go开发者，所以很多新特性并没有有效地交付给用户。我们还发现，9%的受访者曾尝试过Workspace，另有5%的受访者表示他们想尝试但无法尝试。gowork命令缺乏文档和有意义的错误消息是使用Go工作区的首要障碍(21%)，其次是重构现有repo的要求(13%)。与安全部分的讨论类似，不少受访者也给出了“没时间/不优先考虑”等理由。根据我们的理解，这意味着与实际收益相比，了解和设置工作空间的门槛仍然很高，也可能是之前开发者已经找到了自己的解决方案。在Go模块发布之前，许多组织已经通过内部文档服务器（例如支持godoc.org的服务器）为员工提供内部Go包文档。但是现在，设置这些服务器的过程比以往任何时候都更加复杂，我们正在考虑是否投资让它变得更容易。因此，我们询问了受访者他们如何看待内部Go模块文档，看看这是否是他们更喜欢的工作方式。结果显示，目前最常见的查看Go内部文档的方式是阅读代码（81%），大约一半的人认为这很好，但39%的人认为拥有内部文档服务器会更好.我们还询问了谁应该配置和维护这些服务器，三分之二的受访者表示应该是软件工程师，而其余三分之一认为可以指派专门的IT支持或运营人员。从这个角度来说，理想的文档服务器应该是那种交钥匙的解决方案，或者至少不会带来太多额外的工作负担（一个人可以在午休时间维护）。考虑到当前开发人才严重短缺的现实，这样的要求是完全合理的。调查受访者总体而言，自2021年调查以来，受访者群体的基本特征没有太大变化。一些受访者(53%)有两年或两年以上的Go经验，而其余的则是Go社区的新手。大约三分之一的受访者来自小型企业（少于100名员工），四分之一来自中型企业（100至1,000名员工），四分之一来自大型企业（超过1,000名员工）。与去年类似，我们发现VSCode的调查弹出窗口吸引了北美和欧洲以外的许多开发人员。受访者如何使用Go与上一年相比，受访者使用Go的方式在统计上也没有显着差异。最常见的两个用例仍然是构建API/RPC服务(73%)和编写CLI(60%)。我们使用线性模型来尝试查看受访者使用Go的时间长短与他们在哪里开发之间是否存在关系。我们发现，Go经验不足一年的受访者通常更关注GUI、IoT、游戏、机器学习/AI或移动应用程序等开发目标。受访时间超过一年的受访者明显很少使用Go语言进行这些方面的开发，说明他们在实践中可能遇到了较大的障碍。大多数受访者在Linux(59%)或macOS(52%)上开发Go，部署目的地绝大多数是Linux系统(93%)。对于本次调查，我们添加了在WindowsSubsystemforLinux(WSL)上进行Go开发的选项，发现有13%的受访者选择了这个选项。感受和挑战最后，我们询问了受访者在过去一年中对使用Go的总体感受，特别是他们在使用Go时遇到的最大挑战。我们发现，93%的受访者表示“还好”（30%）或非常满意（63%），与2021年调查中的92%大致一致。多年来，泛型一直是Go开发中争论的焦点。Go1.18对类型参数的支持，在缓解旧冲突的同时，引入了错误处理的新问题。可以肯定的是，错误处理不是孤立存在的，与缺失或不成熟的库、开发人员学习困难、最佳实践不易实施、类型系统的其他修订（例如支持枚举和更多函数式编程语法）有关与其他问题密切相关。总之，除了泛型之外，Go开发者还有一条崎岖不平的道路。总结本次Go开发人员调查重点关注Go1.18版本中的新功能。我们已经看到泛型的普及稳步推进，但开发人员在当前的实现中也遇到了很多限制。模糊测试和工作区的采用仍然有限，但核心原因不是技术：如果这两个功能要触及受众，首先需要解决何时以及如何使用它们的问题。另一个障碍是开发人员没有时间去关注这些新特性，这也体现在安全开发上。基于这些结论，Go团队将确定下一步的优先顺序，并影响未来的工具设计思路。感谢您对本次Go开发者研究的关注，我们希望我们发布的结果能够对您有所启发。非常感谢参与调查并积极回复我们的Go开发人员。这些反馈将帮助我们了解Go当前的局限性和现实挑战，并相应地改进整个生态系统。我们会继续努力，争取不断为大家交付更完整的Go版本！
