9 月 8 日，Go 語言社區(qū)發(fā)布 2022 年第二季度開發(fā)者調(diào)查報告，本次調(diào)研覆蓋 5752 位受訪開發(fā)者，主題涉及他們在使用 Go 1.18 全新功能特性（包括泛型、安全工具和工作區(qū)）時的真實感受，以下是本次報告的重要內(nèi)容。

泛型已經(jīng)得到迅速接納。大多數(shù)受訪者都知道 Go 1.18 版本中引入了泛型，約四分之一受訪者稱已經(jīng)在實際代碼中使用泛型。大多數(shù)開發(fā)者對泛型的發(fā)布贊賞有加，但也有部分受訪者發(fā)現(xiàn)目前的泛型設(shè)計限制太多。

Fuzzing 對大多數(shù) Go 開發(fā)者來說仍是新鮮事物。Go 新版本內(nèi)置的模糊測試在知名度上遠(yuǎn)遠(yuǎn)不及泛型，受訪者也不確定為什么或者何時需要使用模糊測試。

第三方依賴項成為最重要的安全問題。目前，受訪者稱如何避免包含已知漏洞的依賴項成為安全工作中的最大挑戰(zhàn)。總體而言，安全工作往往缺乏計劃、也沒有明確的回報，所以工具開發(fā)者應(yīng)當(dāng)盡可能自審自查，幫助開發(fā)者節(jié)約時間和精力。

我們的新功能發(fā)布工作還可以做得更好。關(guān)注 Go 官方博客的開發(fā)者一般對新版本的變化比較熟悉，但隨機(jī)抽樣的受訪者則不太了解最新版本的情況。因此我們要么應(yīng)該在博文以外再開拓新的 Go 生態(tài)消息渠道，要么更努力地廣泛分享博文內(nèi)容。

錯誤處理仍是個難題。隨著泛型的發(fā)布，受訪者在使用 Go 時面臨的最大難題變成了如何處理錯誤。總體來看，大家對 Go 語言的滿意度仍然很高，我們發(fā)現(xiàn)受訪者使用 Go 語言的方式并沒有明顯變化。

調(diào)查結(jié)果解讀

在本文中，我們將通過一系列圖表來解讀此番調(diào)查。所有圖表均采用相同格式，標(biāo)題部分是向受訪者們提出的具體問題。除非另有說明，否則各問題均為單選形式，受訪者只能選擇其一。圖表的副標(biāo)題部分，會標(biāo)注是否為多選問題或開放性問題。

對于開放性問題，Go 團(tuán)隊成員認(rèn)真閱讀并手動整理了受訪者們的意見。大家對于這類問題的回應(yīng)多種多樣，因此我們挑選了最具共性的前十大主題，其余主題則被歸類為“其他”。

為了幫助大家了解每條結(jié)論的證據(jù)權(quán)重，我們使用誤差線來表示響應(yīng)意見的 95% 置信區(qū)間：條形較窄，則表示信心越強。有時，可能有多條響應(yīng)意見的誤差線彼此重疊，意味著這些響應(yīng)的相對順序并不具備統(tǒng)計學(xué)意義（或者說這些意見之間相互綁定）。各圖表的右下角為圖表中受訪者者人數(shù)，形式為“n= 受訪者人數(shù)”。

泛型

支持類型參數(shù)（即泛型）的 Go 1.18 發(fā)布之后，我們希望大家如何看待和采用這項新功能，并確定使用泛型時的常見挑戰(zhàn)或障礙。

絕大多數(shù)受訪者（86%）都知道 Go 1.18 版本引入了泛型。雖然我們預(yù)計這個比例會超過一半，但沒想到有這么高。我們還發(fā)現(xiàn)，約四分之一受訪者已經(jīng)開始在 Go 代碼中使用泛型（26%），其中 14% 表示是在生產(chǎn)或已發(fā)布的代碼中使用。大多數(shù)受訪者（54%）并不抵觸泛型，只是目前還沒開始使用。** 另有 8% 的受訪者有意在 Go 中使用泛型，但出于種種原因而暫未行動。

是什么阻止了一些開發(fā)人員使用泛型？困擾大多數(shù)受訪者的其實就兩個理由：首先，30% 的受訪者表示他們發(fā)現(xiàn)現(xiàn)有泛型實現(xiàn)仍有諸多限制，例如不支持參數(shù)化方法、類型推斷和類型切換等。受訪者表示，這些問題限制了泛型的可用空間，或者導(dǎo)致泛型代碼過于冗長。

第二個理由則是某些依賴項尚不支持泛型——其中最典型的例子是 linter，此外還有仍在使用的早期 Go 版本，或者尚不提供 Go 1.18 包（26%）的 Linux 發(fā)行版等。12% 的受訪者則是因為學(xué)習(xí)曲線陡峭或說明文檔不充分而選擇放棄。

除了這些重要因素，受訪者還反饋了一些相對不太常見、但仍有意見的阻礙，如下圖所示。這里，我們僅列出已經(jīng)在使用泛型，或者曾嘗試使用泛型但未能成功的受訪者。

我們還詢問了嘗試用過泛型的受訪者，希望了解他們的感受。令人振奮的是，10% 的受訪者表示泛型確實簡化了自己的代碼、降低了代碼重復(fù)度。除了高度贊賞之外，其他受訪者也普遍（43%）對泛型給予積極評價；相比之下，只有 6% 的受訪者對泛型表達(dá)了負(fù)面評價或感受。

與之前提到的使用挑戰(zhàn)相似，近三分之一受訪者表示 Go 的泛型實現(xiàn)限制太多。

Go 團(tuán)隊正參考這些結(jié)果，研究是否或如何放寬這些限制。

? 安全性

經(jīng)歷了 2020 年的 SolarWinds 漏洞之后，安全軟件開發(fā)實踐再次受到關(guān)注。Go 團(tuán)隊也在優(yōu)先考慮安全保障問題，包括建立軟件物料清單（SBOM）的配套工具、模糊測試以及最近推出的漏洞掃描。為了達(dá)成目標(biāo)，本次調(diào)查特別詢問了關(guān)于軟件開發(fā)安全實踐和挑戰(zhàn)的問題，特別是：

Go 開發(fā)者目前在使用哪些類型的安全工具？

Go 開發(fā)者如何發(fā)現(xiàn)和解決漏洞？

要編寫出安全的 Go 軟件，最大的挑戰(zhàn)是什么？

調(diào)查結(jié)果表明，雖然靜態(tài)分析工具得到了廣泛應(yīng)用（65%），但只有少數(shù)受訪者在使用這些工具發(fā)現(xiàn)漏洞（35%），或者以其他方式提高代碼安全性（33%）。受訪者們表示，安全工具主要運行在 CI/CD 過程（84%），只有少數(shù)開發(fā)者會在開發(fā)期間運行這些工具（22%）。

這與我們團(tuán)隊進(jìn)行的其他安全研究一致，即安全掃描大多集中在 CI/CD 期間，而這時才關(guān)注安全問題其實為時已晚。更理想的方法，應(yīng)該是在構(gòu)建之前就知曉依賴項是否存在漏洞、驗證版本更新是否解決了這些漏洞。等到 CI 針對 PR 運行完整測試時，隱患往往已經(jīng)難以剔除。

我們還向受訪者詢問了他們在安全開發(fā)軟件時的最大挑戰(zhàn)。目前最常見的難題是如何評估第三方庫的安全性（57%）， 其實主題漏洞掃描器（例如 GitHub 的 dependabot 或者 Go 團(tuán)隊的 govulncheck）就能很好地完成任務(wù)。

其他反饋意見則為新工具提供了發(fā)展空間：受訪者們表示，他們在編寫代碼并驗證成果是否存在漏洞時，往往很難全流程遵循最佳實踐。

模糊測試是提高應(yīng)用程序安全性的另一種好辦法，但大多數(shù)受訪者似乎對此還不熟悉。只有 12% 的受訪者在實際工作中用過模糊測試，5% 的受訪者稱已經(jīng)在使用 Go 內(nèi)置模糊測試工具。

在“為什么會感覺模糊測試難以使用”的開放性問題中，我們發(fā)現(xiàn)影響最大的并非技術(shù)因素：占比最高的三個答案分別是“不了解如何使用模糊測試”（23%）、“沒時間進(jìn)行模糊測試或者其他安全保障工作”（22%）、“沒法以符合預(yù)期的方式和時間進(jìn)行模糊測試”（14%）。

這些發(fā)現(xiàn)表明，我們還需要投入精力幫助開發(fā)者了解模糊測試的價值、模糊測試要測什么，以及如何把它應(yīng)用在不同的代碼庫當(dāng)中。

為了更好地了解大家如何檢測漏洞、解決常見安全任務(wù)，我們詢問受訪者在過去一年中是否發(fā)現(xiàn)過自己的 Go 代碼或依賴項中存在漏洞。對于給出肯定答案的受訪者，我們又進(jìn)一步提出問題，例如當(dāng)時是怎么發(fā)現(xiàn)漏洞的、如何調(diào)查及 / 或解決，以及整個過程中哪些環(huán)節(jié)最為棘手。

首先，我們發(fā)現(xiàn)漏洞掃描確有成效。四分之一的受訪者表示從第三方依賴項中發(fā)現(xiàn)了漏洞。但實際使用漏洞掃描的受訪者只占三分之一，所以在這部分群體中再統(tǒng)計依賴項漏洞比例時，我們發(fā)現(xiàn)結(jié)果從 25% 倍增至 46%。除了依賴項和 Go 自身的漏洞外，有 12% 的受訪者表示發(fā)現(xiàn)的是自己代碼中的漏洞。

大多數(shù)受訪者（65%）表示，他們發(fā)現(xiàn)的漏洞源自安全掃描程序。受訪者最常用的工具是 GitHub 的 dependabot（38%），使用比例高于所有其他漏洞掃描程序的總和（27%）。除掃描之外，受訪者了解漏洞的其他常見方式還包括公共報告，例如發(fā)布說明和 CVE（22%）。

在意識到存在漏洞后，受訪者們最常見的解決方法（67%）是升級相應(yīng)依賴項。在使用漏洞掃描程序（專門用于檢測第三方依賴項中漏洞）的受訪者中，選擇升級依賴項的比例則上升至 85%。近三分之一的受訪者會閱讀 CVE 或漏洞報告（31%），只有 12% 的受訪者會進(jìn)一步做深入調(diào)查，了解自己的軟件是否受到影響、受到怎樣的影響。

只有 12% 的受訪者表示會對代碼漏洞造成的潛在影響做進(jìn)一步調(diào)查，這樣的比例確實低得令人吃驚。為了掌握更多細(xì)節(jié)，我們還詢問受訪者在應(yīng)對漏洞方面遇到過哪些挑戰(zhàn)。幾個主要答案的占比基本相當(dāng)，包括害怕依賴項更新會影響代碼執(zhí)行，以及通過 go.mod 文件更新間接依賴項的難度較高等。

我們也詢問了一般使用哪種調(diào)查方式了解漏洞影響或探究根本原因，這 12% 愿意做進(jìn)一步調(diào)查的受訪者們給出了更積極的答案：其中 70% 對漏洞的潛在影響進(jìn)行了調(diào)查，并發(fā)現(xiàn)這才是整個過程中最困難的部分。

除了調(diào)查本身的難度，他們還提到這項工作通常不在項目計劃之內(nèi)，而且完全沒有直接回報。

Go 團(tuán)隊認(rèn)為，這種深入調(diào)查應(yīng)用程序中各依賴項安全態(tài)勢的好習(xí)慣，將直接決定漏洞可能給組織帶來的實際風(fēng)險、甚至是否發(fā)生數(shù)據(jù)泄露。

因此，我們設(shè)計出 govulncheck，在調(diào)用的函數(shù)中存在漏洞時向開發(fā)者發(fā)出提醒，并列出該函數(shù)在代碼中的確切位置。希望這款工具能幫助開發(fā)者快速對應(yīng)用程序中的致命漏洞進(jìn)行調(diào)查，減少計劃外的安全工作負(fù)擔(dān)。

工具體驗

下面，我們又詢問了關(guān)于工具體驗的問題：

自上次調(diào)查以來，編輯環(huán)境是否發(fā)生了變化？

開發(fā)者愿意使用工作區(qū)嗎？如果愿意，在初上手時感覺有哪些不便？

開發(fā)者如何處理內(nèi)部包文檔？

VS Code 在受訪者中的人氣似乎還在持續(xù)增長。自 2021 年以來，受訪者就將其選為最受歡迎的 GO 代碼編輯器，今年的支持比例更是從 42% 上升至 45%。VS Code 和 GoLand 兩大高人氣編輯器似乎不受組織規(guī)模的影響，在大企業(yè)和小公司里都很受歡迎。但從統(tǒng)計結(jié)果來看，業(yè)余開發(fā)者似乎更偏愛 VS Code。

在 2021 年通過 gopls 語言服務(wù)器強化 VS Code 的 Go 支持能力之后，Go 團(tuán)隊一直想了解 gopls 中存在哪些使用痛點。雖然我們已經(jīng)從開發(fā)者那邊收到了不少反饋，但不清楚會不會有很多開發(fā)者直接禁用掉了這項功能。

為了收集關(guān)于 gopls 的負(fù)面意見，我們專門統(tǒng)計了那些所使用的編輯器能夠支持 gopls 的受訪者（無論他們是否實際使用 gopls），并發(fā)現(xiàn)禁用比例只有 2%。而且在 VS Code 上，禁用比例更是下降至 1%。這讓我們對 gopls 的表現(xiàn)更具信心，也期待大家在 GitHub 上提交更多關(guān)于 gopls 的問題。

在工作區(qū)這邊，很多受訪者似乎是在本次調(diào)查中才知道 Go 能夠支持多模塊工作區(qū)。對 VS Code 用戶的隨機(jī)調(diào)查顯示，大多數(shù)受訪者從來就沒聽說過工作區(qū)（在隨機(jī)抽樣受訪者中占比 53%，在自薦受訪者中占比 33%）。

其實對泛型的認(rèn)知和接納差異在這兩個受訪者群體間也體現(xiàn)得非常明顯，分別為 93% 和 68%。也許是因為我們目前的 Go 博客或社交媒體渠道還不足以涵蓋足夠的 Go 開發(fā)者，所以很多新功能并不能有效傳遞至用戶耳中。

我們還發(fā)現(xiàn)，有 9% 的受訪者曾經(jīng)試用過工作區(qū)，另有 5% 表示想要嘗試但最終未能進(jìn)行。關(guān)于使用 Go 工作區(qū)的阻礙，位居榜首的是 go work 命令缺乏說明文檔和有意義的錯誤消息（21%），其次則是要求重構(gòu)現(xiàn)有 repo（13%）。

與安全部分的討論類似，同樣有不少受訪者給出了“沒時間 / 不是優(yōu)先事項”之類的理由。按照我們的理解，這意味著跟實際帶來的收益相比，工作區(qū)的理解和設(shè)置門檻仍然偏高，也可能是開發(fā)者之前就已經(jīng)找到了自己的解決辦法。

在 Go 模塊發(fā)布之前，不少組織已經(jīng)在通過內(nèi)部文檔服務(wù)器（例如支持 godoc.org 的服務(wù)器）為員工提供內(nèi)部 Go 包文檔。但現(xiàn)在，這類服務(wù)器的設(shè)置流程比以往更為復(fù)雜，我們也在考慮要不要投資來簡化這個過程。因此，我們詢問受訪者如何查看內(nèi)部 Go 模塊文檔，想了解這是不是他們的首選工作方式。

結(jié)果顯示，目前最常見的內(nèi)部 Go 文檔查看方式是閱讀代碼（81%），其中約半數(shù)覺得這樣就挺好，但也有 39% 認(rèn)為能有內(nèi)部文檔服務(wù)器就更好了。

我們還詢問了這類服務(wù)器應(yīng)該由誰配置和維護(hù)，有三分之二的受訪者認(rèn)為應(yīng)該是軟件工程師，余下三分之一覺得可以指派專門的 IT 支持或運營人員。

從這個角度看，理想的文檔服務(wù)器應(yīng)該是那種交鑰匙解決方案，或者至少不會帶來過多的額外工作負(fù)擔(dān)（一個人在午休時間就能維護(hù)好）。考慮到目前開發(fā)人才嚴(yán)重短缺的現(xiàn)實，這樣的要求完全在情理之中。

調(diào)查對象

總體而言，自 2021 年的調(diào)查以來，受訪者群體的基本特征并沒有太大變化。部分受訪者（53%）擁有兩年及以上 Go 使用經(jīng)驗，其余受訪者則是 Go 社區(qū)中的新人。

約三分之一受訪者來自小型企業(yè)（員工少于 100 人），四分之一來自中型企業(yè)（100 至 1000 名員工），四分之一來自大型企業(yè)（員工超過 1000 人）。與去年類似，我們發(fā)現(xiàn) VS Code 上的調(diào)查彈窗吸引到了不少北美和歐洲以外地區(qū)的開發(fā)者。

受訪者們?nèi)绾问褂?Go 語言

受訪者使用 Go 語言的具體方式跟上年相比，同樣沒有出現(xiàn)什么統(tǒng)計意義上的差異。最常見的兩大用例仍然是構(gòu)建 API/RPC 服務(wù)（73%）和編寫 CLI（60%）。

我們使用線性模型，嘗試調(diào)查受訪者使用 Go 的時間與他們的開發(fā)方向之間是否存在關(guān)聯(lián)。我們發(fā)現(xiàn)，Go 經(jīng)驗不足一年的受訪者一般更關(guān)注 GUI、物聯(lián)網(wǎng)、游戲、機(jī)器學(xué)習(xí) /AI 或移動應(yīng)用等開發(fā)目標(biāo)。而一年以上受訪者則明顯較少用 Go 語言進(jìn)行這些領(lǐng)域的開發(fā)，說明他們可能是在實踐當(dāng)中遇到了重大障礙。

大多數(shù)受訪者會在 Linux（59%）或 macOS（52%）上進(jìn)行 Go 開發(fā)，而部署目的地則絕大多數(shù)是 Linux 系統(tǒng)（93%）。在本次調(diào)查中，我們新增了在 Windows Subsystem for Linux（WSL）上進(jìn)行 Go 開發(fā)的選項，并發(fā)現(xiàn)有 13% 的受訪者選擇了這種方式。

感受與挑戰(zhàn)

最后，我們詢問了受訪者過去一年來對 Go 的總體使用感受，特別是使用 Go 時遇到過的最大挑戰(zhàn)。我們發(fā)現(xiàn)，93% 的受訪者表示“還行”（30%）或非常滿意（63%），基本與 2021 年調(diào)查得到的 92% 持平。

多年以來，泛型一直是 Go 開發(fā)中的爭議焦點。Go 1.18 對類型參數(shù)的支持雖然緩和了舊矛盾，但又帶來了錯誤處理這個新問題。可以肯定的是，錯誤處理不是孤立存在的，與庫缺失或不夠成熟、開發(fā)者學(xué)習(xí)難度大、最佳實踐不易實施、對類型系統(tǒng)的其他修訂（例如支持枚舉及更多函數(shù)式編程語法）等其他問題密切相關(guān)。總之，除了泛型之外，Go 開發(fā)者還需要面對坎坷的前進(jìn)道路。

總結(jié)

本次 Go 開發(fā)者調(diào)查主要側(cè)重于 Go 1.18 版本中的新功能。我們發(fā)現(xiàn)泛型的普及正在穩(wěn)步推進(jìn)，但開發(fā)者也遇到了當(dāng)前實現(xiàn)中的不少限制。模糊測試和工作區(qū)的普及率仍然有限，但核心并非技術(shù)原因：要想擴(kuò)大受眾，這兩項功能首先需要解決什么時候用、怎么用的問題。

另一個阻礙則是開發(fā)者沒工夫關(guān)注這些新特性，這一點在安全開發(fā)方面也有體現(xiàn)。根據(jù)這些結(jié)論，Go 團(tuán)隊將確定下一步工作的優(yōu)先級，并影響到未來的工具設(shè)計思路。