取代泛型,錯誤處理成為新挑戰,Go開發者Q2報告出爐!

【CSDN 編者按】泛型一直是Go語言社區的焦點問題,在Go 1.18正式支持泛型開始,官方一直在推廣該功能。據Go官方團隊近日發佈的2022年Q2 Go語言開發者調查報告顯示,已有86%的開發者開始用泛型,比官方預期的要多一些。然而對於Go團隊來說,挑戰從未終止,該報告還揭示了他們面臨的新挑戰,不妨一起看下。

作者 | Todd Kulesza 編譯 | 夢依丹

Go團隊發佈了Q2開發者調查報告,並感謝5752名使用者參與對Go 1.18新功能的反饋,包括泛型、安全工具和工作區等。該報告的重點結論有:

  • 泛型(Generics)已被迅速採用,絕大多數受訪者都知道Go 1.18中引入了泛型功能,大約有四分之一的受訪者開始使用該功能,但很明顯,開發人員已經遇到了初始泛型實現的一些限制。

  • 對於大多數Go開發者來說,模糊測試(Fuzzing testing)還是新事物。受訪者對Go的內建模糊測試的認識遠低於泛型測試,他們對為何或何時考慮使用模糊測試有更多的不確定性。

  • 第三方依賴關係是一個最重要的安全問題。避免依賴已知的漏洞是受訪者面臨的最大安全相關挑戰,更廣泛地說,安全工作往往是無計劃和無回報的,這意味著工具需要尊重開發者的時間和注意力。

  • 官方的新功能宣傳還可以做的更好,與通過Go部落格找到此次調查的人來比,隨機抽樣的參與者還不太知道最近的Go工具發佈。這表明我們應該在部落格文章之外尋找機會來交流Go生態系統的變化,或者擴大努力來更廣泛地分享這些文章。

  • 錯誤處理仍然是一個挑戰。在泛型的發佈之後,受訪者在使用Go時面臨的最大挑戰轉為錯誤處理。總體來說,受訪者對Go的滿意度仍然很高,受訪者使用Go的方式沒有發生明顯變化。

開發者對泛型的反饋

開發者對泛型的反饋

在Go 1.18添加泛型支持以後,我們想了解一下大家對該功能的使用情況以及遇到的常見問題與挑戰有哪些。

調查顯示,有86%的使用者知道Go已經支持泛型,這比官方預期的人數要多的多。26%的受訪者已經在Go程式碼中使用泛型,這包括14%的人已經在生產或者發佈版本中添加泛型程式碼;54%的人不反對使用泛型,但目前沒有該方面的需求,此外,還有8%的使用者希望在Go中使用泛型,但目前遇到了一些阻礙。

阻礙開發者使用泛型的因素有哪些呢?大多數受訪者屬於如下兩類中的一類。

首先,30%的受訪者表示,他們遇到了當前泛型實現的限制,例如想要參數化的方法、改進的類型推理,或者在類型上進行切換。受訪者說,這些問題限制了泛型的潛在用例,或者認為它們使泛型程式碼變得不必要地冗長。第二類是依賴於不支持泛型的東西——linters是最常見的阻礙採用泛型的工具,但這個列表也包括一些東西,如組織仍在使用早期的Go版本或依賴於尚未提供Go 1.18軟體包的Linux發行版(26%)。

12%的受訪者提到了學習曲線過長或缺乏有用的文件。除了這些最重要的問題之外,受訪者還表達了一系列不太常見的(但仍有意義的)挑戰,如下圖所示。為了避免關注假設,本分析只包括那些說他們已經在使用泛型的人,或者那些試圖使用泛型但被某些東西阻撓的人。

與此同時,我們也關注使用泛型開發者的實際體驗與反饋,令人興奮的是,有十分之一的受訪者表示,泛型簡化了他們的程式碼,或者減少了程式碼的重複。最常見的反饋 “謝謝你!”或一般的還不錯(43%);相比之下,只有6%的受訪者表現出消極的反應或情緒。與上述 “最大的挑戰 “問題的發現相呼應,近三分之一的受訪者討論了Go實現泛型的限制。Go團隊正在使用這組結果來幫助決定是否或如何放寬其中的一些限制。

安全問題很重要,但往往是開發者無計劃和無回報的工作

繼2020年發生SolarWinds漏洞事件之後,安全軟體開發方法再次收到關注。Go團隊已把安全相關的工作列為優先事項,包括創建軟體材料清單(SBOM)工具、模糊測試,以及最近的漏洞掃描。為了支持這些工作,本次調查提出了幾個關於軟體開發安全實踐和挑戰方面的問題。

  • Go開發人員目前使用哪些類型的安全工具?

  • Go開發人員是如何發現和解決漏洞的?

  • 編寫安全Go軟體的最大挑戰是什麼?

結果表明,雖然靜態分析工具被廣泛使用(65%的受訪者),但只有少數受訪者使用它來尋找漏洞(35%)或以其他方式提高程式碼安全性(33%)。受訪者表示,安全工具主要運行在CI/CD時間。只有少數人會在開發者期間在本地運行這些工具(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%)。除此以外,最常見的了解漏洞的方法是公共報告,如發行說明和CVEs(22%)。

當知道有漏洞之後,開發者都是怎麼解決的呢?調查顯示,最常見的解決方法是升級有漏洞的依賴關係(67%),在使用漏洞掃描器群體中,該比例提高到了85%。不到三分之一的受訪者會閱讀CVE或查看漏洞報告(31%)。

只有12%的受訪者談到,要深入調查漏洞的背後,以了解他們的軟體是否(以及如何)受到漏洞或者對伺服器會產生潛在的影響。為了深入理解,我們還研究了受訪者應對漏洞安全的最大挑戰是什麼?

他們的回答可以概況為幾個不同的主題,從確保依賴性更新不會破壞任何東西,到了解如何通過go.mod檔案更新間接依賴性。還有了解漏洞的影響或根本原因所需的調查類型。然而,當我們關注哪些調查研究漏洞產生的具體原因的那個群體時,我們看到了一個明顯的關聯性。70%的受訪者說他們對漏洞的潛在影響進行了調查,他們認為這是這個過程中最具挑戰性的部分。原因不僅包括任務的難度,還包括這往往是既無計劃又無回報的工作。

Go團隊認為,對程序漏洞進行深入的調查的行為,將直接決定漏洞對團隊帶來的實際影響,包括是否發生了資料洩露或其他安全等。因此,我們設計了govulncheck,只在漏洞被調用時提醒開發者,並指出開發者在其程式碼中使用漏洞函數的確切位置。我們的希望是,這將使開發人員更容易快速調查應用程序的真正的重要漏洞所在,從而減少這一領域的整體非計劃性工作的數量。

工具篇:隨機受訪者更喜歡VS Code

接下來又調查了工具方面的問題:

  • 自我們上次調查以來,編輯器環境是否發生了變化?

  • 開發人員是否使用了工作空間?如果用了,他們在入手時,遇到了哪些挑戰?

  • 開發者是如何處理內部包檔案的?

VS Code使用者比例還在增長。自2021年以來,受訪者的首選Go程式碼編輯器的比例從42%增加到45%。VS Code和GoLand這兩個最受歡迎的編輯器,兩者在小型和大型組織之間的受歡迎程度沒有差異,但業餘開發者更傾向於VS Code。這項分析不包括隨機抽樣的VS Code受訪者——我們期望邀請的人對用於分發邀請的工具表現出偏好,這正是我們看到的(91%的隨機抽樣受訪者更喜歡VS Code)。

在2021年通過gopls語言伺服器為VS Code的Go支持提供動力之後,Go團隊一直想了解與gopls有關的開發者痛點。雖然我們從目前使用gopls的開發者那裡收到了大量的反饋,但我們想知道是否有很大一部分開發者在發佈後不久就禁用了它,這可能意味著我們沒有聽到關於特別有問題的用例的反饋。為了回答這個問題,我們詢問了那些說他們更喜歡支持gopls的編輯器的受訪者是否使用gopls,發現只有2%的人說他們禁用了gopls;具體到VS Code,這個比例下降到1%。這增加了我們的信心,我們聽到的是一群有代表性的開發者的反饋。對於那些對gopls仍有未解決的問題的讀者,請在GitHub提交反饋,好讓我們知道(https://github.com/golang/go/issues)。

關於工作區,似乎很多人是通過這次調查第一次了解到Go對多模組工作區的支持。對VS Code的隨機調查顯示,大部分受訪者沒有聽說過工作區,在隨機抽樣的受訪者中佔比53%,自薦受訪者佔比33%。對於泛型的認識趨勢,兩個群體的認知趨勢都比較高,隨機抽樣佔68%,自薦受訪者佔93%。

至於原因,可行的解釋是,我們目前的Go部落格或現有的社交媒體渠道還不足以接觸到所有的Go開發者,導致許多新功能無法及時讓使用者知道。

我們發現,9%的受訪者表示他們已經嘗試過工作區,還有5%的受訪者想嘗試,但沒有成功。受訪者討論了在嘗試使用Go工作區時遇到的各種挑戰。缺乏文件和go work命令的有用錯誤資訊位居榜首(21%),其次是技術上的挑戰,如重構現有的資源庫(13%)。與安全部分所討論的挑戰類似,也有人給出了”缺乏時間/不是優先事項”,我們將其理解為,與工作區提供的好處相比,理解和設置工作區的門檻仍然有點太高,可能是因為開發人員已經有了變通辦法。

在Go模組發佈之前,組織能夠運行內部文件伺服器(例如支持 godoc.org 的伺服器),為員工提供內部Go包的文件。pkg.go.dev依然如此,但建立這樣的伺服器比以前更復雜了。

為了解開發者是否希望官方團隊對這方面進行更多投資時,我們詢問了受訪者如何看待內部Go模組文件,以及他們首選的工作方式。

結果顯示,最常見的查看內部Go文件的方式是閱讀程式碼(81%),雖然約有一半的受訪者對此感到滿意,但有很大一部分人希望有一個內部文件伺服器(39%)。

誰最有可能配置和維護這樣一個伺服器:軟體工程師以2比1的結果勝出,而不是專門的IT支持或運營團隊的人。這強烈地表明,文件伺服器應該是一個交鑰匙的解決方案,或者至少對單個開發人員來說容易快速運行,不會帶來額外的工作負擔。

一半使用者有兩年以上Go開發經驗

一半使用者有兩年以上Go開發經驗

整體而言,自2021年調查以來,受訪者的使用者畫像沒有太多變化。

部分受訪者(53%)有至少兩年的Go使用經驗,其餘受訪者則是Go社區的新成員。約三分之一的受訪者在小型企業(1000名員工)工作。與去年類似,我們發現VS Code上的調查彈窗更容易吸引北美和歐洲以外的開發者參與。

開發者如何使用Go語言

開發者如何使用Go語言

調查發現,開發者使用Go語言的方式與以往統計沒有什麼同比變化,最常見的依然是構建API/RPC服務(73%)和編寫CLI(60%)。我們使用線性模型來研究受訪者使用Go的時間長短與用Go構建的事物類型之間是否存在關係。結果發現,擁有<1年Go經驗的受訪者更有可能正在構建該圖表下半部分的東西(GUI、IoT、遊戲、ML/AI或移動應用程序),這表明人們對在這些領域使用Go有興趣,但一年經驗後的下降也意味著開發人員在這些領域使用Go時遇到重大障礙。

感受與挑戰

感受與挑戰

最後,我們訪問了受訪者在過去一年對Go的總體滿意程度以及他們在使用Go語言時的最大挑戰,93%的受訪者表示還行(30%)或者非常滿意(63%),與2021年的92%的受訪者表示滿意沒有差異。

多年以來,泛型一直是Go最常討論的話題,目前在Go 1.18中提供了泛型支持。與此同時,又迎來的一個新的挑戰,錯誤處理。可以肯定的是,錯誤處理與其它挑戰是並列的,如庫缺失或不夠成熟、幫助開發者學習或實施的最佳實踐、對類型系統的其他修訂,如支持列舉或更多的函數語言程式設計語法。在泛型之後,Go開發者面臨的挑戰依然還有一段路要走。

總結

總結

本次Go開發者調查的重點是Go 1.18版本的新功能。泛型採用要比官方預期好的多,模糊測試和工作區採用進展較慢,但與技術原因無關。慢的主要原因是開發者不知何時以及如何使用它們,另一個挑戰是開發者沒有時間專注在這些主題上,該挑戰也提現在安全工具上。這些發現正在幫助Go團隊確定下一步工作的優先次序,並將影響我們對未來工具設計的態度。

最後,感謝大家加入Go開發者之旅,感謝對本次調查做出回應的每個人。您的反饋幫助我們了解Go開發者在工作中受到的限制,並確定他們面臨的挑戰。通過分享,將有助於為每位開發者改善Go語言生態,僅此代表世界各地的Goer們,謝謝你!

報告原文:https://go.dev/blog/survey2022-q2-results

相關文章

最強 AI ChatGPT 真要取代程式設計師?

最強 AI ChatGPT 真要取代程式設計師?

【CSDN 編者按】ChatGPT 一出,「程式設計師要失業了」、「程式設計師要下崗了」之聲不絕於耳,引得程式設計師們不由得一陣驚慌,最強 ...

中國資料庫的諸神之戰

中國資料庫的諸神之戰

作者 | 唐小引 出品 | 《新程式設計師》編輯部 「現在的資料庫產品實在是太多了!」 前幾天,我和深耕資料庫/大資料近 30 年的盧東明老...

雲原生時代的DevOps平臺設計之道

雲原生時代的DevOps平臺設計之道

【CSDN 編者按】雲原生時代,開發和運維的分工愈加分明,運維人員通過建設並維護一套 IaaS 雲平臺,將計算資源進行池化。開發人員按需申請...