Go 部落格
Go 開發者調查 2022 年第二季度結果
概述
本文分享了 2022 年 6 月 Go 開發者調查的結果。我謹代表 Go 團隊，感謝 5,752 位參與調查並分享他們在 Go 1.18 中使用新功能（包括泛型、安全工具和工作區）的經驗的人。你們幫助我們更好地理解開發者如何發現和使用這些功能，正如本文將討論的那樣，提供了有用的見解，以便進一步改進。謝謝大家！ 💙
主要發現
- 泛型已迅速普及。絕大多數受訪者都知道 Go 1.18 版本中包含了泛型，大約四分之一的受訪者表示他們已經開始在 Go 程式碼中使用泛型。與泛型相關的最常見的反饋是“謝謝！”，但顯然開發者已經遇到了初始泛型實現的一些限制。
- 模糊測試對大多數 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% 的受訪者表示他們遇到了當前泛型實現的限制，例如希望有引數化方法、改進的型別推斷或基於型別的 switch。受訪者表示這些問題限制了泛型的潛在用例，或覺得它們使泛型程式碼過於冗長。第二類涉及依賴尚不支援泛型的工具——linters 是最常見的阻礙採用的工具，但此列表也包括諸如組織仍在使用較早的 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 在受訪者中的受歡迎程度似乎持續增長，表示它是 Go 程式碼首選編輯器的受訪者比例從 2021 年的 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%，自願參與的受訪者中有 33%），我們在對泛型的認知上也觀察到了類似的趨勢（儘管這兩個群體中的認知度都更高，自願參與的受訪者中有 93% 知道 Go 1.18 中包含了泛型，而隨機抽樣的受訪者中有 68%）。一種解釋是，目前我們無法透過 Go 部落格或現有社交媒體渠道觸及大量 Go 開發者，而這些渠道傳統上是我們分享新功能的主要機制。
我們發現 9% 的受訪者表示他們嘗試過工作區，另有 5% 的受訪者表示想使用但受到阻礙。受訪者討論了在使用 Go 工作區時遇到的各種挑戰。缺乏文件和 go work 命令沒有提供有用的錯誤訊息排在首位（21%），其次是技術挑戰，例如重構現有倉庫（13%）。與安全性部分討論的挑戰類似，我們再次看到列表中的“缺乏時間/非優先順序”——我們將其解讀為，相對於工作區提供的優勢而言，理解和設定工作區的門檻仍然有點高，這可能是因為開發者已經有了替代解決方案。
在 Go modules 釋出之前，組織可以執行內部文件伺服器（例如為 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 的時長與他們用 Go 構建的專案型別之間是否存在關係。我們發現，Go 經驗少於 1 年的受訪者更有可能構建此圖表下半部分的專案（GUI、IoT、遊戲、ML/AI 或移動應用），這表明在這些領域中使用 Go 存在興趣，但一年經驗後出現的下降也意味著開發者在這些領域使用 Go 時遇到了重大障礙。
大多數受訪者在使用 Go 進行開發時使用 Linux (59%) 或 macOS (52%)，絕大多數部署到 Linux 系統 (93%)。本輪調查我們新增了在適用於 Linux 的 Windows 子系統 (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 生態系統，造福所有人。謹代表全球所有的 Gopher，我們感謝您！ 🎉
下一篇文章：Go 執行時：4 年後
上一篇文章：Go 的漏洞管理
部落格索引