Go 部落格
Go 開發人員調查 2022 年第 2 季結果
概觀
這篇文章分享 2022 年 6 月版 Go 開發人員調查的結果。感謝代表 Go 團隊，感謝 5,752 位告訴我們他們使用 Go 1.18 新功能的體驗，包括泛型、安全性工具及工作空間。你們幫助我們更了解開發人員如何發現和使用此功能，而且正如本文將討論的，提供有用的見解以進行額外的改進。謝謝！ 💙
主要發現
- 泛型已快速導入。絕大多數受訪者都知道泛型已包含在 Go 1.18 發行版本中，而約有 1/4 的受訪者表示他們已開始在 Go 程式碼中使用泛型。泛型相關的反饋中最常見的部分是「謝謝！」，但顯然開發人員已遇到泛型初始實作的一些限制。
- 模糊測試對多數 Go 開發人員來說是陌生的。Go 內建模糊測試的認知度遠低於泛型，而且受訪者對於在何時或為何使用模糊測試很沒有把握。
- 第三方相依性是首要的安全性疑慮。避免已知有弱點的相依性是受訪者在安全性上面臨的首要挑戰。廣泛而言，安全性工作通常是沒有計畫且得不到回報的，這表示工具需要尊重開發人員的時間和注意力。
- 我們可以在宣告新功能時做得更好。隨機抽取的參與者較不知悉 Go 最近發布的工具，相比之下，透過 Go 部落格找到這項調查的人就比較知道。這表示我們應該透過部落格文章以外的方式傳達 Go 生態系統的變更，或是擴大宣傳這些文章的努力，讓更多人知道。
- 錯誤處理仍是一項挑戰。泛型發布後，受訪者在使用 Go 時面臨的首要挑戰轉變為錯誤處理。不過大致上而言，對 Go 的滿意度仍非常高，而且我們沒有發現受訪者使用 Go 的方式有什麼顯著變化。
如何閱讀這些結果
在本文中，我們會使用調查問卷的回覆圖表，作為發現佐證。這些圖表全部採用類似的格式。標題是問卷受訪者所看到的確切問題。除非另有註明，否則問題都是選擇題，而且參與者只能選擇單一答覆選擇；每個圖表的副標題會說明該問題是否允許多個答覆選擇，或者是非多選題的開放式文字方塊。對於開放式文字回覆的圖表，Go 團隊成員會閱讀並手動分類所有回覆。很多開放式問題會引發各種不同的回覆；為了保持圖表尺寸在合理範圍內，我們將其濃縮在最多前 10 項主題，所有其他主題都統整在「其他」類別下。
為了幫助讀者了解每個發現背後的證據重量，我們加入誤差線，顯示回覆的 95% 信賴區間；較窄的線代表較高的信心。有時候，兩個或多個回覆的誤差線會重疊，這表示那些回覆之間的相對順序沒有統計意義（亦即回覆基本上是並列的）。每個圖表的右下方會顯示圖表中包含的所有回覆人數，格式類似於「n = [受訪者人數]」。
關於方法的說明
大部分的受訪者是以「自選」的方式參與問卷，這表示他們是在Go 部落格、@golang Twitter 或其他與 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 上提交問題 讓我們知道。
關於工作區的部分，許多人表示第一次嘗試 Go 工作區的支援功能是透過這份調查。 特別是透過 VS Code 隨機提示得知調查的受訪者極有可能表示之前未聽過工作區這個概念（隨機抽樣受訪者中 53%，自選受訪者中 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 的時間長短與他們使用 Go 建置的專案類型之間是否存在關係。我們發現，使用 Go 不滿一年的受訪者更有可能建立此圖表下半部顯示的專案（GUI、IoT、遊戲、機器學習/人工智慧或行動應用程式），這表示有意使用 Go 從事這些領域，但使用滿一年後突然降低也暗示了開發人員在使用 Go 從事這些領域時遇到了重大障礙。
大部份受訪者在使用 Go 開發時會使用 Linux（59%）或 macOS（52%），而絕大部份受訪者會部署到 Linux 系統（93%）。本週期我們新增一個回應選項，供在 Windows 子系統用於 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 公開宣布這項調查。我們也透過 Go 外掛在 6 月 1 日至 21 日間隨機提示 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，我們由衷感謝您！
下一篇：Go 執行時間：4 年後
上一篇：Go 漏洞管理
部落格索引