概覽

本文分享 2022 年 6 月份 Go 開發者調查的結果。Go 團隊在此感謝 5,752 位受訪者分享了他們在使用 Go 1.18 中引入的新功能（包括泛型、安全工具和工作區）的體驗。你們幫助我們更好地瞭解開發者如何發現和使用這些功能，正如本文將要討論的，也為進一步改進提供了有價值的見解。謝謝！💙

主要發現

• 泛型得到快速採納。絕大多數受訪者都知曉 Go 1.18 版本已包含泛型，約四分之一的受訪者表示已開始在 Go 程式碼中使用泛型。關於泛型最常見的單一反饋是“謝謝！”，但很明顯，開發者已經遇到了一些初始泛型實現上的侷限性。
• 模糊測試對大多數 Go 開發者而言是新事物。與泛型相比，內建的模糊測試的知曉度要低得多，受訪者對何時或為何考慮使用模糊測試存在更多不確定性。
• 第三方依賴是首要安全顧慮。避免存在已知漏洞的依賴是受訪者最關心的安全相關挑戰。更廣泛地說，安全工作通常是計劃外且不被獎勵的，這暗示著工具需要尊重開發者的時間和注意力。
• 我們可以更好地宣佈新功能。隨機抽樣的參與者對近期 Go 工具釋出的瞭解程度低於透過 Go 部落格找到此調查的人。這表明我們應該超越部落格文章來傳達 Go 生態系統的變化，或擴大這些文章的傳播範圍。
• 錯誤處理仍然是挑戰。繼泛型釋出後，受訪者在使用 Go 時面臨的首要挑戰轉向了錯誤處理。總的來說，對 Go 的滿意度仍然很高，我們沒有發現受訪者使用 Go 的方式有任何顯著變化。

如何解讀這些結果

在本文中，我們使用調查回覆的圖表來支援我們的發現。所有這些圖表都採用類似的格式。標題是調查受訪者看到的實際問題。除非另有說明，問題是單選題，參與者只能選擇一個答案；每個圖表的副標題會告知您該問題是否允許選擇多個答案，或者是一個開放式文字框而不是選擇題。對於開放式文本回復的圖表，Go 團隊成員閱讀並手動分類了所有回覆。許多開放式問題引出了各種各樣的回答；為使圖表大小合理，我們將它們精簡為最多前 10 個主題，其餘主題都歸類在“其他”項下。

為了幫助讀者理解每項發現背後的證據力度，我們包含了誤差條，顯示了回覆的 95% 置信區間；誤差條越窄，置信度越高。有時兩個或多個回覆的誤差條會重疊，這意味著這些回覆的相對順序在統計學上沒有意義（即，這些回覆實際上是並列的）。每個圖表的右下角顯示了包含在圖表中的回覆人數，格式為“n = [受訪者人數]”。

方法論說明

大多數調查受訪者是“自願”參加調查的，意味著他們是在 Go 部落格、Twitter 上的 @golang 或其他 Go 社交渠道上找到的。這種方法潛在的問題是，不關注這些渠道的人可能不太會了解到此調查，並且他們的回答可能與那些密切關注這些渠道的人不同。約三分之一的受訪者是隨機抽樣的，意味著他們在 VS Code 中看到提示後回應了調查（在 2022 年 6 月 1 日至 6 月 21 日之間使用 VS Code Go 外掛的每個人都有 10% 的機率收到此隨機提示）。這個隨機抽樣組幫助我們將這些發現推廣到更廣泛的 Go 開發者社群。大多數調查問題在這些組之間沒有顯示出有意義的差異，但在少數有重要差異的情況下，讀者將看到將回復細分為“隨機樣本”和“自選”組的圖表。

泛型

在 Go 1.18 釋出並支援型別引數（更常被稱為泛型）之後，我們想了解泛型的初始認知度和採納情況，以及使用泛型的常見挑戰或障礙。

絕大多數調查受訪者（86%）已經知道泛型作為 Go 1.18 版本的一部分已釋出。我們曾希望看到一個簡單多數，所以這個知曉率遠超我們的預期。我們還發現，約四分之一的受訪者已開始在 Go 程式碼中使用泛型（26%），其中包括 14% 表示已在生產環境或已釋出的程式碼中使用泛型。大多數受訪者（54%）不反對使用泛型，但目前沒有此需求。我們還發現，8% 的受訪者希望在 Go 中使用泛型，但目前被某事阻礙了。

是什麼阻礙了一些開發者使用泛型？大多數受訪者屬於以下兩類之一。首先，30% 的受訪者表示遇到了當前泛型實現的一個限制，例如想要引數化方法、改進型別推斷或對型別進行開關。受訪者表示，這些問題限制了泛型的潛在用例，或者感覺它們使泛型程式碼不必要地冗長。第二類涉及依賴尚未支援泛型的內容——linter 是最常見的阻止採納的工具，但此列表還包括組織仍在使用早期 Go 版本，或依賴尚未提供 Go 1.18 軟體包的 Linux 發行版（26%）。12% 的受訪者表示學習曲線陡峭或缺乏有用的文件。除了這些主要問題之外，受訪者還告訴我們了各種不太常見（但仍然有意義）的挑戰，如下面的圖表所示。為了避免關注假設，本分析僅包括那些表示已在使用泛型，或嘗試使用泛型但被某事阻礙的受訪者。

我們還詢問嘗試使用泛型的受訪者是否願意分享任何其他反饋。令人鼓舞的是，十分之一的受訪者表示泛型已經簡化了他們的程式碼，或減少了程式碼重複。最常見的回覆是“謝謝！”的變體或普遍的積極情緒（43%）；相比之下，只有 6% 的受訪者表現出負面反應或情緒。與上述“最大挑戰”問題的發現相呼應，近三分之一的受訪者討論了 Go 泛型實現的侷限性。Go 團隊正在利用這一系列結果來幫助決定是否以及如何放寬其中一些限制。

安全

繼 2020 年 SolarWinds 洩露事件 之後，安全開發軟體的做法受到了新的關注。Go 團隊已將此領域的工作列為優先事項，包括用於建立 軟體物料清單 (SBOM)、模糊測試，以及最近的 漏洞掃描。為支援這些工作，本次調查提出了一些關於軟體開發安全實踐和挑戰的問題。我們特別想了解：

• Go 開發者目前使用哪些型別的安全工具？
• Go 開發者如何發現和解決漏洞？
• 編寫安全 Go 軟體面臨的最大挑戰是什麼？

我們的結果表明，儘管靜態分析工具得到了廣泛使用（65% 的受訪者），但只有少數受訪者目前使用它來查詢漏洞（35%）或以其他方式改進程式碼安全性（33%）。受訪者表示，安全工具最常在 CI/CD 時間執行（84%），少數人表示開發者在本地開發過程中執行這些工具（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%），其引用頻率高於所有其他漏洞掃描器總和（27%）。在掃描工具之後，發現漏洞的最常見方法是公開報告，如發行說明和 CVE（22%）。

一旦受訪者瞭解到漏洞，最常見的解決方法是升級有漏洞的依賴項（67%）。在也討論使用漏洞掃描器的受訪者中（作為討論第三方依賴項漏洞的參與者的代理），這一比例增加到 85%。不到三分之一的受訪者討論了閱讀 CVE 或漏洞報告（31%），只有 12% 的人提到了更深入的調查以瞭解他們的軟體是否（以及如何）受到漏洞的影響。

只有 12% 的受訪者表示他們調查了漏洞是否可以在其程式碼中觸及，或者它可能對服務產生的影響，這令人驚訝。為了更好地理解這一點，我們還查看了受訪者認為在響應安全漏洞方面最具挑戰性的是什麼。他們以大致相等的比例描述了幾個不同的主題，從確保依賴項更新不會中斷任何內容，到理解如何透過 go.mod 檔案更新間接依賴項。此列表中還包括理解漏洞影響或根本原因所需的調查型別。但是，當我們僅關注表示進行過這些調查的受訪者時，我們會看到一個清晰的相關性：70% 表示調查過漏洞潛在影響的受訪者認為這是此過程中最具挑戰性的部分。原因不僅在於任務的難度，還在於這項工作通常是計劃外且不被獎勵的。

Go 團隊認為，這些需要理解應用程式如何使用有漏洞的依賴項的深入調查，對於理解漏洞可能給組織帶來的風險，以及瞭解是否發生了資料洩露或其他安全事故至關重要。因此，我們設計了 govulncheck，使其僅在漏洞被呼叫時才提醒開發者，並指向他們程式碼中正在使用有漏洞函式的具體位置。我們希望這能使開發者更容易快速調查真正重要的漏洞，從而減少該領域的計劃外工作總量。

工具

接下來，我們調查了三個關於工具的問題：

• 自上次調查以來，編輯器格局是否發生了變化？
• 開發者是否在使用工作區？如果使用，在入門過程中遇到了哪些挑戰？
• 開發者如何處理內部軟體包的文件？

VS Code 在調查受訪者中的受歡迎程度似乎在持續增長，從 2021 年以來，表示它是其首選 Go 程式碼編輯器的受訪者比例從 42% 增加到 45%。VS Code 和 GoLand 是最受歡迎的兩個編輯器，它們在小型和大型組織中的受歡迎程度沒有差異，但業餘開發者更傾向於選擇 VS Code 而不是 GoLand。此分析不包括隨機抽樣的 VS Code 受訪者——我們預計那些被邀請參加調查的人會偏好用於分發邀請的工具，這正是我們看到的（91% 的隨機抽樣受訪者偏好 VS Code）。

繼 2021 年切換到透過 gopls 語言伺服器為 VS Code 的 Go 支援提供支援後，Go 團隊一直熱衷於瞭解開發者在使用 gopls 方面的痛點。雖然我們從當前使用 gopls 的開發者那裡收到了大量反饋，但我們想知道是否有很大一部分開發者在釋出後不久就停用了它，這可能意味著我們沒有收到關於特別有問題的用例的反饋。為了回答這個問題，我們詢問了那些表示偏好支援 gopls 的編輯器但不使用 gopls 的受訪者，發現只有 2% 的人表示已停用它；對於 VS Code，這一比例降至 1%。這增強了我們聽到來自代表性開發者群體的反饋的信心。對於仍未解決 gopls 問題的讀者，請透過 在 GitHub 上提交 issue 告知我們。

關於工作區，似乎許多人是透過本次調查才首次瞭解到 Go 對多模組工作區的支援。透過 VS Code 隨機提示得知此調查的受訪者尤其有可能表示他們以前從未聽說過工作區（53% 的隨機抽樣受訪者 vs. 33% 的自選受訪者），這種趨勢我們也觀察到了對泛型的認知（儘管這兩類群體的認知度都更高，93% 的自選受訪者知道泛型已包含在 Go 1.18 中，而隨機抽樣受訪者為 68%）。一種解釋是，我們透過 Go 部落格或現有社交媒體渠道尚未觸及大量 Go 開發者受眾，而這些渠道一直是我們將新功能分享給大眾的主要機制。

我們發現 9% 的受訪者表示嘗試過工作區，另有 5% 的人希望嘗試但被某事阻礙了。受訪者在嘗試使用 Go 工作區時討論了各種挑戰。缺乏文件和 go work 命令的有用的錯誤訊息名列前茅（21%），其次是技術挑戰，如重構現有儲存庫（13%）。與安全部分討論的挑戰類似，我們再次在此列表中看到了“缺乏時間/非優先事項”——我們將其解釋為理解和設定工作區的門檻仍然有點太高，相比它們提供的收益，這可能是因為開發者已經有了替代方案。

在 Go 模組釋出之前，組織能夠執行內部文件伺服器（例如為 godoc.org 提供支援的 伺服器），為員工提供私有內部 Go 軟體包的文件。使用 pkg.go.dev 仍然是如此，但設定這樣的伺服器比以前要複雜。為了瞭解我們是否應該投入精力使這個過程更容易，我們詢問了受訪者他們今天如何看待內部 Go 模組的文件，以及這是否是他們偏好的工作方式。

結果顯示，今天檢視內部 Go 文件的最常見方式是閱讀程式碼（81%），並且儘管約有一半的受訪者對此感到滿意，但仍有很大一部分人希望擁有內部文件伺服器（39%）。我們還詢問了誰最有可能配置和維護這樣的伺服器：以 2:1 的比例，受訪者認為這將是軟體工程師而不是來自專門 IT 支援或運營團隊的人。這有力地表明，文件伺服器應該是一個即插即用解決方案，或者至少易於單個開發者快速執行（例如，在一個午休時間），理論上這種工作是開發者已經滿負荷的又一項職責。

我們聽取了誰的意見

總的來說，受訪者的個人資訊和公司資訊與 2021 年調查相比沒有顯著變化。一小部分受訪者（53%）至少有兩年使用 Go 的經驗，其餘的則是 Go 社群的新成員。約 ⅓ 的受訪者在小型企業（< 100 名員工）工作，¼ 在中型企業（100 – 1,000 名員工）工作，¼ 在大型企業（> 1,000 名員工）工作。與去年類似，我們發現 VS Code 的提示有助於鼓勵北美和歐洲以外的調查參與。

受訪者如何使用 Go

與上一節類似，我們沒有發現受訪者使用 Go 的方式在年復一年之間有統計學上的顯著變化。最常見的兩種用途仍然是構建 API/RPC 服務（73%）和編寫 CLI（60%）。我們使用線性模型來調查受訪者使用 Go 的時間長短與他們構建的型別之間是否存在關聯。我們發現，有 < 1 年 Go 經驗的受訪者更有可能在圖表中較低的區域構建東西（GUI、IoT、遊戲、ML/AI 或移動應用），這表明在這些領域有使用 Go 的興趣，但一年經驗後的下降也暗示著開發者在這些領域使用 Go 時會遇到重大障礙。

大多數受訪者在使用 Go 開發時使用 Linux（59%）或 macOS（52%），並且絕大多數部署到 Linux 系統（93%）。本期我們為使用 Windows Subsystem for Linux (WSL) 開發添加了一個回覆選項，發現 13% 的受訪者在使用 Go 時使用它。

情緒和挑戰

最後，我們詢問了受訪者在過去一年中對 Go 的總體滿意度或不滿意度，以及他們在使用 Go 時面臨的最大挑戰。我們發現 93% 的受訪者表示“有點”（30%）或“非常”（63%）滿意，這與 2021 年 Go 開發者調查中表示滿意的 92% 的受訪者在統計學上沒有顯著差異。

多年來，泛型一直是使用 Go 時最常討論的挑戰，Go 1.18 對型別引數的支援最終帶來了新的首要挑戰：我們老朋友，錯誤處理。可以肯定的是，錯誤處理在統計學上與其他幾項挑戰並列，包括某些領域的庫缺失或不成熟、幫助開發者學習和實施最佳實踐，以及型別系統的其他修訂，例如對列舉的支援或更函數語言程式設計的語法。在泛型之後，Go 開發者似乎面臨著一系列長尾挑戰。

調查方法

我們於 2022 年 6 月 1 日透過 go.dev/blog 和 Twitter 上的 @golang 公佈了本次調查。我們還在 6 月 1 日至 21 日期間透過 Go 外掛隨機提示了 10% 的 VS Code 使用者。調查於 6 月 22 日結束，部分回覆（即開始但未完成調查的人）也被記錄下來。我們過濾掉了完成調查速度特別快（< 30 秒）或在多選問題中傾向於勾選所有選項的受訪者的資料。這留下了 5,752 個回覆。

約 ⅓ 的受訪者來自隨機的 VS Code 提示，與透過 Go 部落格或 Go 社交媒體渠道找到調查的人相比，這組人的 Go 經驗較少。我們使用線性和邏輯模型來調查這些群體之間明顯的差異是否可以透過這種經驗差異來更好地解釋，通常情況確實如此。例外情況已在文中註明。

今年我們非常希望能夠與社群分享原始資料集，類似於 Stack Overflow、JetBrains 等的開發者調查。最近的法律指導不幸阻止了我們現在這樣做，但我們正在努力，並有望在下一次 Go 開發者調查中分享原始資料集。

結論

本期 Go 開發者調查重點關注 Go 1.18 版本的新功能。我們發現泛型的採納進展順利，開發者已經遇到了一些當前實現上的侷限性。模糊測試和工作區的採納速度較慢，儘管原因主要不是技術性的：兩者面臨的主要挑戰是理解何時以及如何使用它們。開發者缺乏時間關注這些主題也是一個挑戰，這一主題也延續到了安全工具方面。這些發現正在幫助 Go 團隊確定下一階段工作的優先順序，並將影響我們如何處理未來工具的設計。

感謝您與我們一起遊覽 Go 開發者研究之旅——我們希望它有所啟發且有趣。最重要的是，感謝歷年來所有回覆我們調查的人。您的反饋幫助我們瞭解 Go 開發者工作的約束條件，並識別他們面臨的挑戰。透過分享這些經驗，您正在幫助改進 Go 生態系統，造福所有人。代表所有 Gophers，我們感謝您！