Go 部落格

Go 開發者調查 2023 年 Q1 結果

艾莉絲梅利克
2023 年 5 月 11 日

感謝受訪者提供這些見解!

很高興與您分享 Go 開發者調查 2023 年 1 月的結果。感謝 5,844 位受訪者分享他們如何使用 Go、使用 Go 時面臨的最大挑戰,以及未來改進的優先事項。這些結果有助於 Go 團隊集中我們的精力在社群最重視的領域,我們也希望這些見解對其他為 Go 生態系統做出貢獻和提供協助的人有所幫助。

主要發現

  • Go 新手開發人員有興趣於網頁開發。今年我們根據自認的經驗等級引入了一個新的區分。新手與其他經驗等級之間表現出一些有趣的差異。最顯著的是,他們表明對使用 Go 進行網頁開發有更大的興趣。
  • 錯誤處理和學習是受訪問者的最大挑戰。在過去,缺少泛型是使用 Go 最大的挑戰,但自從泛型引進以來,我們已看到關於泛型的留言減少了。關於錯誤處理(涉及可讀性和冗長性)和難以學習最佳實務的留言現在是最常報告的挑戰。
  • 最佳化指南是改善 Go 效能最受重視的方式。當被問到他們將如何花費資源在各種 Go 編譯和執行時期的改善時,受訪者花費最多在最佳化指南,而非特定效能改善上,這說明了這方面的文件有多麼受重視。
  • 管理相依性和版本控管是開源 Go 模組維護人員的最大挑戰。開源模組維護人員面臨使相依性保持最新並避免因版本控管和重大變更造成的干擾的挑戰。這是我們將進一步探索的領域,以幫助維護人員提供一個穩定且良好的生態系。

如何解讀這些結果

在本文中,我們使用調查回應的圖表提供我們的研究結果的佐證。所有這些圖表都使用相似的格式。標題是受訪者在調查中看到的確切問題。除非另有註明,否則問題都是單選,參與者只能選出一個回應選項;每個圖表的副標題會告訴您該問題是否允許多個回應選項,或是一個開放式文字方框,而非多選題。對於開放式文字回應的圖表,Go 團隊成員會閱讀並手動分類所有回應。許多開放式問題引發了各式各樣的回應;為了保持圖表大小在合理範圍內,我們將其濃縮成 10 至 15 個主題,其他主題全部分組在「其他」之下。如有需要,我們也會納入「無」的類別。

為了幫助閱讀者了解支撐每項研究結果的證據份量,我們納入誤差線條,顯示回應的 95% 信賴區間;線條越窄,表示信心越高。有時兩個或更多回應的誤差線條重疊,表示這些回應的相對順序在統計上沒有意義(也就是說這些回應本質上是平手的)。每個圖表的右下角顯示圖表中包含的回應者人數,格式為「n = [受訪者人數]」。

方法備註

大部分問卷受訪者都是「自行選擇」透過某個連結存取來參與這項問卷調查,這些連結分享在Go 部落格@golang 在推特上或其他 Go 社群頻道上。並不追蹤這些頻道的人們可能會給出有別於密切追蹤這些頻道之人士的不同回應。約有四分之一的受訪者是隨機抽樣的,意指他們在 VS Code 中看到提示訊息後才參與問卷調查(2023 年 1 月 18 日至 2 月 8 日期間使用 VS Code Go 外掛程式的所有使用者都擁有 10% 機率會收到此隨機提示)。這種隨機抽樣的群組有助於我們將這些發現推廣到 Go 開發人員的廣大社群。大部分問卷問題在這兩個群組中都未顯示出有意義的差異,不過在少數存在重大差異的情況下,讀者會看到將回應區分為「隨機樣本」和「自行選擇」群組的圖表。

深入瞭解不同群組的受訪者

我們的受訪者人口統計資料與上次的問卷調查相比沒有顯著變化。與前幾個週期一致,Go 主要用於科技產業,約有 80% 的受訪者表示他們在工作中會使用 Go 進行編寫程式。總體而言,受訪者在過去一年 cenderung滿意 Go,有 92% 的人表示他們有些滿意或非常滿意。

Bar chart
showing where respondents use Go Bar chart showing proportion of satisfied
respondents

與其他語言相比,我們的受訪者在 Go 中花費大量時間編寫程式。約有三分之一的受訪者甚至維護開源的 Go 模組。我們知道我們的問卷對象組成是成功採用 Go、經常使用 Go 且使用 Go 時多半覺得滿意的人。為了找出滿足社群需求時潛在的差距,我們會觀察受訪者的不同子群組,瞭解他們可能如何以不同的方式使用 Go,或者擁有不同的優先事項。例如,我們今年觀察到,不同樣本來源(例如 Go 部落格或透過 VS Code 外掛程式)的回應之間有何差異,以及不同工作職務、組織規模和 Go 經驗層級之間有何差異。最有趣的差異在於經驗層級之間。

新手受訪者的見解

Bar chart of years of experience using
Go

以前,我們使用受訪者使用 Go 已有(月數/年數)作為一個指標,深入瞭解經驗層級之間的結果如何有所不同。今年,我們嘗試了一個新的區隔問題:「你的 Go 經驗層級為何?」,看看自我認同是否可能是比將各種時間間隔歸納在一起更有效的方式來驗證 Go 經驗。由於「新手」或「專家」等類別術語因人而異,我們提供了一段說明,以協助讓這些區隔更加客觀。選項如下

  • 知曉:我知道 Go,但是無法在未經協助的情況下撰寫一個簡單的 Go 程式。
  • 新手:我可以使用 Go 完成簡單的程式設計專案,有可能在協助之下完成。
  • 中階:我可以使用 Go 在一些協助之下完成大型程式設計專案。
  • 進階:我可以自己在未經協助的情況下完成大型程式設計專案。
  • 專家:我可以為其他工程師提供 Go 相關的指導、疑難排解以及回答他們的問題。

Bar chart of levels of experience
using Go

我們發現受訪者使用 Go 的時間長度,與其自我認定的經驗等級之間存在中等相關性(⍴ = .66)。這表示經驗等級量表雖然類似於時間量表,但可能讓我們深入了解受訪者如何在經驗上有所不同。例如,受訪者花在 Go 上的寫作時間,相較於花在其他語言上的寫作時間,更能與其自我認定的經驗等級相關聯,而非他們使用 Go 已有多久時間。

在我們使用此區隔進行分析時,通常會排除認知類別,因為他們不會被視為具有回答問題所需的經驗,而且只代表了約 1% 的受訪者。

新手受訪者比經驗較豐富的受訪者更傾向偏好 Windows。

我們的隨機取樣群組中有較高比例的新手受訪者,而非自我選擇的群組,這表示外面還有更多我們未常聽聞的新手 Gopher。由於他們是透過 Go VS Code 外掛程式進行取樣,我們可能會認為,此群組更有可能偏好使用 VS Code,或更可能使用 Windows 進行開發,而非其他經驗等級。儘管如此,新手也比其他經驗等級更可能使用 Windows 進行開發,無關他們是否透過 VS Code 外掛程式回應。

Bar chart of levels of experience
using Go for self-selected and random samples Bar chart of editor
preference broken down by experience levels for self-selected group only Bar chart of
levels of experience using Go

我們沒有看到更高經驗等級的使用者中,有較高比例的 Windows 使用者,可能有多種原因。例如,Windows 使用者可能會更常遇到困難並停止使用 Go,或是有與 Go 無關的其他作業系統使用狀況趨勢。無論如何,我們都應該在有關 Go 入門的未來研究中納入更多 Windows 使用者,以確保我們提供一個包容性的入門體驗。

不同經驗等級目前如何使用 Go(以及他們想要使用的其他領域)。

Bar chart of use cases Bar chart of use
cases broken down by experience level

根據受訪者目前使用 Go 的方式,較有經驗的 Gopher 傾向於將 Go 用於更多類型的應用程式。例如,專家平均使用 Go 於至少四個領域,而新手平均僅使用 Go 於兩個領域。因此,新手和專家在各個使用案例中使用 Go 的比例差異很大。然而,最主要的兩種用途,即 API/RPC 服務和命令列介面,則是所有經驗等級最常使用的案例。

針對圖形使用者介面和網站/網路服務(傳回 HTML),我們看到了更有趣的趨勢。所有經驗等級使用 Go 於桌面/圖形使用者介面應用程式的比率都差不多。這讓我們看到,想要使用圖形使用者介面的並非只限於正在尋找有趣入門專案的新手 Gopher,而是來自所有經驗範圍的使用者。

傳回 HTML 的網站/服務顯示出類似的趨勢。一個解釋可能是,這是某人 Go 學習旅程初期常見的使用案例(因為它是新手最常使用的 3 個案例之一),或新手更有可能從事於傳回 HTML 的網站或網路服務的工作。在調查中後段,我們詢問受訪者「在哪些領域(如果有)你沒有使用 Go,但最想要使用?」雖然許多受訪者 (29%) 表示他們已經在他們想要使用 Go 的地方使用 Go 了,但擴展使用領域的前兩個領域是 GUI/桌上型電腦和 AI/ML 應用程式。這在不同組織規模和職位扮演的不同群組是一致的,但對於經驗等級則不然。新手最想要使用 Go 的第一個領域是傳回 HTML 的網站/網路服務。

Bar chart of levels of
experience using Go

在一個開放式文字題目中,29 位表示他們想要使用 Go 開發傳回 HTML 的網站/網路服務的受訪者有 12 位表示他們被封鎖,因為其他語言有可更好地支援此使用案例的架構。當其他語言已經有符合這些需求的架構時,更有經驗的 Go 開發人員可能不會嘗試或期望使用 Go 來針對此使用案例。正如一位受訪者所言:

「在其他語言(例如 PHP 或 Ruby)中執行這項工作通常會比較容易,部分原因在於這些語言中有出色的架構。」

新手對網路開發有興趣的另一個原因可能是與他們使用 JavaScript/TypeScript 的情況有關。新手花較多時間撰寫 JavaScript/TypeScript,多於經驗比較豐富的受訪者。對網路比較有興趣可能有部分原因在於新手受訪者目前使用其他語言執行什麼工作,或可能表示對網路科技有興趣。我們在未來希望能進一步瞭解此使用案例,以及我們如何協助新的 Gopher 開始使用 Go 來開發對他們最有用的領域。

Bar chart of levels of
experience using Go

受訪者面臨到一大堆挑戰

每次調查週期,我們會詢問受訪者在使用 Go 時遇到的最大挑戰是什麼。過去,缺乏泛型是最常被提到的挑戰,例如,這是 2020 年最常見的回應,且約有 18% 的受訪者提到。自從推出泛型以來,錯誤處理 (12%)、學習/最佳實務/文件 (11%) 已經出現在一大堆問題的最前端,而不是某個問題變得更加頻繁。

Bar chart of
biggest challenges

為什麼錯誤處理是一個挑戰?

關於錯誤處理的回饋通常會將問題描述為冗長。表面上來看,這可能是因為撰寫重複的程式碼很無趣又惱人。不過,撰寫樣板程式碼並不僅僅是造成困擾,錯誤處理也可能會影響回應者除錯的能力。

一位回應者簡明扼要地說明了這個問題

「如果沒有正確處理(沒有堆疊追蹤),錯誤處理會造成混亂並輕鬆地隱藏問題」

學習最佳實務的挑戰

「有效地使用 Go。容易學習,難以精通。」

我們聽說過 Go 容易學習,而 先前的調查 顯示有超過 70% 的回應者覺得在他們的第一年使用 Go 就很有生產力,但學習 Go 最佳實務成為使用 Go 的最大挑戰之一。今年的回應者告訴我們,關於程式碼結構推薦的工具及函式庫的最佳實務都沒有寫好文件,為新手和團隊一致性地撰寫程式碼造成了挑戰。學習撰寫慣用語的 Go 程式碼對於使用其他程式設計範例的開發人員來說,特別具有挑戰性。對 Go 經驗豐富的回應者證明,當開發人員未遵循撰寫慣用語 Go 的最佳實務時,會損害共用專案的一致性與品質。

模組維護者的最大挑戰

Go 模組維護者是 Go 社群的重要成員,有助於我們套件生態系的成長和發展。我們計畫在今年對模組維護者進行研究,以找出支援套件生態系穩定性和成長的機會,以及協助在組織內擴大 Go 採用率。為了讓這項研究獲得資料,我們在問卷調查中加入一個問題,希望了解目前開源維護者面臨的重大挑戰。

Bar chart of
challenges for open source module maintainers

維護者的首要挑戰是讓依賴關係保持最新以及版本控管的困難,包括如何避免、找出或確知何時引入重大變更。這些見解加上未來的研究結果,將有助於制定策略,以支援維護者維持 Go 生態系的穩定和安全性。

部署 Go 程式碼時最大的挑戰

我們在今年詢問回應者,在部署 Go 程式碼時他們面臨的最大挑戰是什麼。容易部署通常被視為使用 Go 的原因,但在近期的一項研究中,我們收到了相互矛盾的回饋,這促使我們探究在部署 Go 程式碼時潛在的問題。在我們的開放式回應文字中,迄今為止最常見的主題是難以使用 cgo 進行跨編譯(16%),而對 WebAssembly 或 WASI 的支援則名列第二(7%)。

Bar chart of challenges
for open source module maintainers

社群的優先事項:回應者最需要的

今年我們使用買功能優先級法中的優先級問題,此方式在先前的調查中已使用過。受訪者獲得 10 個「地鼠幣」,並要求他們分配此幣給希望看到改進的領域。受訪者會隨機指定三個可能的問題之一,每個問題包含七個與工具、安全性或編譯器相關的項目 & 執行時間。這種方法讓我們可以詢問與每個焦點領域相關的項目,而不會用三組認知要求高的優先級問題造成受訪者負擔。

演練結束時,我們給受訪者一個開放式文字提示,請他們告訴我們任何他們認為應為 Go 團隊在明年首要任務的領域,不論他們用幣買什麼項目。例如,如果受訪者看到安全性區段,但他們不太重視安全性,他們仍可以在開放文字區域告訴我們。

安全性

我們選擇這些項目來測試我們對社群中安全慣例相對重要性所做的假設。以下是說明給參與者的七個項目

  • pkg.go.dev 指出維護不佳的套件 (例如對問題沒有反應、無法更新相依性、長時間具有漏洞)
  • pkg.go.dev 指出進行破壞性 API 變更的套件 (例如更新那些套件到較新版本時,需要修復其 API 用法)
  • 支援在 govulncheck 中抑制漏洞
  • 追蹤敏感資料如何在 Go 程式中流動的工具 (偵測 PII 外洩)
  • 安全最佳實務範例指南 (例如,如何選擇和更新相依性;如何設定模糊化、漏洞檢查和執行緒 sanitiser;如何使用加密)
  • 預設安全性 Web 和 SQL 程式庫,協助使用者避免在網頁伺服器程式碼中引進漏洞
  • 符合 FIPS-140 的密碼編譯程式庫

Bar chart of where
respondents spent the most on security issues

資金最多的安全性功能是預設安全性 Web 和 SQL 程式庫,以避免在網頁伺服器程式碼中引進漏洞,但前四項功能都與避免引進漏洞有關。對於安全預設值的需求與先前安全性研究一致,該研究顯示開發人員希望將安全性「左移」:開發團隊通常沒有時間或資源花在解決安全性問題上,因此重視能減少一開始就引進這些漏洞的工具。第二常見的項目是安全性最佳實務範例指南,這突顯了多數受訪者認為最佳實務文件比新工具或功能更有價值。

工具

我們將這個問題中的項目靈感來自於 VS Code 外掛程式使用者的回饋。我們想知道哪些工具組和 IDE 改進對可能使用其他 IDE 或編輯器的更廣泛的受眾最有幫助。

  • 更好的重構工具(例如,支援自動程式碼轉換:重新命名、函式提取、API 遷移等)
  • 在你的程式碼編輯器/IDE 中更好地支援測試(例如,強大且可擴充的 Test Explorer UI、第三方測試架構、子測試支援、程式碼覆蓋率)
  • 在你的程式碼編輯器/IDE 中更好地支援多個模組的工作(例如,編輯模組 A 和 B,其中模組 A 相依於模組 B)
  • pkg.go.dev 中的相依洞察力(例如,弱點、重大變更、評分卡)
  • 你的程式碼編輯器/IDE 中的相依洞察力(例如,弱點、重大變更、評分卡)
  • 支援發布具有新模組路徑的模組(例如,儲存庫所有權移交)
  • 在你的程式碼編輯器/IDE 中支援尋找實作介面的類型和類型實作的介面

Bar chart of where
respondents spent the most on tooling

獲得最多資金的編輯器功能是實作介面的類型尋找支援和介面實作類型重構工具。我們還根據首選編輯器用法看到受訪者如何花費他們的 gophercoin 有趣的差異。最值得注意的是,VS Code 使用者比 GoLand 使用者在重構上花費了更多 gophercoin,這表明 GoLand 目前比 VS Code 更能支援自動程式碼轉換。

編譯器和執行時間

此區段的主要問題是確定受訪者是希望透過預設獲得更好的效能、更好的最佳化工具,還是僅希望更了解如何撰寫效能良好的 Go 程式碼。

  • 降低運算成本
  • 降低記憶體使用量
  • 降低二進位大小
  • 降低建置時間
  • 更佳的效能除錯工具
  • 最佳化指南(如何改善效能和降低成本,涵蓋 Go 的實作和效能除錯工具)
  • 在交叉編譯時使用 cgo 的更好支援

Bar chart of where
respondents spent the most on compiler and runtime improvements

此清單中獲得最多資金的項目是最佳化指南。這在整個組織規模、工作職務和經驗等級中都是一致的。我們詢問了另一個問題,關於受訪者是否有資源成本方面的考量。大多數受訪者 (55%) 表示他們沒有任何成本方面的考量,但對於資源成本有疑慮的人比沒有疑慮的人在降低運算成本和記憶體成本上花了更多的 gophercoin(平均 2.0)。然而,即使是那些對於資源成本有疑慮的人,在最佳化指南上花的錢還是差不多(平均 1.9 個 gophercoin)。這是一個強烈的訊號,表示為 Go 開發人員提供了解和最佳化 Go 效能的指南目前比其他編譯器和執行時間效能改善更有價值。

結論

感謝您加入我們,檢閱我們 2023 年首份開發者問卷調查結果!了解開發者的經驗與挑戰有助於我們優先處理如何 best serve Go 社群。以下是我們發現一些特別有用的結論

  • 新手 Go 開發者比其他經驗等級的受訪者更偏好網站開發。這是我們想要深入探索的領域,以確保我們滿足新手 Go 開發者的需求。
  • 在 IDE 裡提供安全的預設值、關於安全性與最佳化的最佳實務指南,以及更多重構協助,將對社群非常有價值。
  • 錯誤處理是社群的首要優先議題,並在詳細程度與除錯能力方面製造挑戰。Go 小組目前尚未公開分享提案,但會持續探索改進錯誤處理的選項。
  • 新手入門與學習最佳實務是受訪者遇到的最大挑戰之一,並將列為未來研究的重點。
  • 對 Go 模組維護者而言,持續更新依賴關係、模組版本管理,以及找出或避免重大變更,是最大的挑戰。協助維護者提供穩定又健全的生態系統,是進一步 UX 研究的另一個主題。

再次感謝所有回應並貢獻這份問卷調查的人員,沒有你們我們無法完成它。我們希望今年稍後能看到您參與下一份問卷調查。

下一篇:Go 1.21 發行候選版本
前一篇:Go 程式碼整合測試的程式碼覆蓋率
部落格索引