2021 年Solidity開發者報告：大多數受訪者認為自己是Solidity 專家

原文標題：Solidity Developer Survey 2021 Results

原文編譯：楊樹

編譯標題：2021 年Solidity開發者報告：概覽加密世界最龐大的開發者群體

這是由Solidity 官方開展的第二次結構化的年度大型Solidity 開發人員調查（2020 年調查報告可點擊此處查看），以Solidity 語言的開發者使用情況為主題，圍繞開發者數量、開發者簡介、開發者屬性、開發者開發經驗、即將推出的功能和語言設計、社區Solidity 等多個維度展開調查。

這篇文章中，我們將總結和分析2021 年Solidity 開發者調查的結果。

摘要

• 調查對象：總共有來自73 個不同國家/地區的435 名開發人員參與了此次調查，與2020 年相比，這一數字增加了100% 以上。覆蓋的國家和地區也從2020 年的48 個急劇增加到2021 年的73 個。超過20% 的用戶表示居住在美國，其次是印度（9%）和德國（4%），大約9% 的人更願意不分享其位置的詳細信息。

• 開發人員簡介：編程經驗水平中等偏高，大多數受訪者從事專業編程工作3 年或以上，36.6% 甚至超過6 年。

• Solidity 體驗：超過一半的受訪者使用Solidity 不到一年，而15.5% 的受訪者使用它超過3 年，幾乎80% 的人每天或每週都使用Solidity。

• Solidity 專業知識：大多數受訪者認為自己是Solidity 專家，他們的專業知識自我評價為7 或更高（滿分10 分）。 4.2% 的人將他們的專業知識評為10。80% 的受訪者將Solidity 用於他們的個人項目，大約60% 的人也在工作中使用它，超過一半的受訪者使用Solidity 的時間不到一年。

• 開發者體驗：大多數(大於70%) 認為Solidity 開發者體驗在去年有所改善，只有1.6% 的人認為情況變得更糟。

• 語言準確性：60% 的開發者希望Solidity 能夠增加更多檢查點，減少由於判例不足引起的錯誤，提升智能合約開發的準確性。 26% 的人更願意保持現狀。

• 未來功能：更高效的優化器和捕獲自定義錯誤的能力被列為正在討論的最重要的未來功能。此外，對小數的支持、更好的陣列管理和解決堆棧太深錯誤等都是最受期待的功能。

• 喜歡和害怕的功能：受訪者最喜歡Solidity 的簡單性、「易於學習」的方面、默認的SafeMath 和修飾符，可怕的話題是調試、堆棧太深的錯誤以及缺少對小數的支持。

• 社區：不到三分之一的受訪者曾參與過與Solidity 語言設計相關的工作。

調查對象

請注意，此調查僅以英語進行這一事實是在解釋有關居住國分佈和語言偏好的結果時需要考慮的重要因素。

首先，讓我們看看參與本次調查的開發人員，我們將詳細介紹位置和語言等一般信息，並詳細了解他們的專業經驗、編程偏好等。

2021 年的調查總共收到了來自73 個不同國家/地區的開發人員的435 份回复，與2020 年相比，這一數字增加了100% 以上。

國家和地區的數量也從2020 年的48 個攀升至2021 年的73 個，似乎也覆蓋了地理上更加多樣化的受眾。

居住位

超過20% 的人表示居住在美國，其次是印度（9%）和德國（4%），大約9% 的人更願意不分享其位置的詳細信息。

語言

受訪者使用他們的母語涵蓋多種語言，總共提到了50 種不同的語言作為母語。

其中35% 的受訪者的母語是英語，其次是西班牙語（9.4%）、法語（5.9%）、俄語（5.9%）、葡萄牙語（4.9%）和德語（4.9%）。

超過80% 的受訪者在工作中主要使用英語。一些受訪者還在工作中說西班牙語（2.8%）、法語（2.1%）、俄語（1.6%）或葡萄牙語（1.6%）。

在母語非英語的受訪者中，超過90% 的人可以閱讀英文版的Solidity 文檔，8.6% 的人更願意用他們的母語閱讀，其中最常被提及的是普通話和繁體中文、西班牙語和葡萄牙語。

請記住，此調查僅以英語進行，這可能會影響此問題的結果。我們仍然相信Solidity 文檔等資源的國際化是降低進入門檻的關鍵因素，我們的目標是支持社區努力通過新的、更清晰的結構化翻譯指南進行翻譯。

開發者簡介

工作經驗和就業

77.1% 的受訪者目前有工作，大約10% 是學生，12.5% 目前沒有全職工作。

受訪者主要在科技（62.8%）和金融服務（15.5%）領域工作，除此以外教育、媒體以及遊戲等領域的佔比也相對較高。

大約10% 的人是編程新手，並且只從事專業編程不到一年。不過值得一提的是，擁有超過15年編程經驗的資深開發者佔比也達到了這一數字。而約有30%的受訪者擁有3-5年編程經驗。參與本次調查的受訪者編程經驗年限基本呈現正態分佈。

總體而言，編程經驗水平處於中高水平，大多數受訪者專業編程3 年或以上，36.6% 甚至超過6 年。

有趣的是，大多數受訪者（80.4%）將Solidity 用於他們的個人項目，大約60% 的受訪者在工作中使用Solidity，而40% 的受訪者主要在工作中使用另一種編程語言編寫代碼。

超過20% 的人表示他們正在領導一個編程團隊。

在開源貢獻方面，60% 的受訪者表示他們從未或很少為使用Solidity 編寫的開源項目做出貢獻。

不過也有約30% 的受訪者表示每天或每週都會這樣做。

編程語言首選項

JavaScript 和Solidity 在最常用的編程語言中排名第一（均為27%），其次是TypeScript（14.7%）和Python（10.9%）。

在「最喜愛的編程語言」票選中，Python 成功擊敗Solidity 「反客為主」，獲得了22.7% 的受訪者青睞，其次是Solidity（19.4%）、JavaScript（14.5%）、TypeScript（10.8%）和Rust（8.4%）。

操作系統

與2020 年的調查類似，macOS 和Linux 似乎同樣受歡迎。

大約40% 使用macOS，緊隨其後的是Linux（36.6%），22% 的受訪者使用Windows，其中大多數人表示除了Windows 之外還使用macOS 或Linux，也有一些開發人員同時使用Linux 和macOS，甚至同時使用這三個操作系統。

Solidity 經驗和Solidity 開發人員簡介

大多數受訪者認為自己是Solidity 專家，他們的專業知識自我評價為7 或更高（滿分10 分）。

4.2% 的人將他們的專業知識評為10，大約23% 可以被認為是初學者或自評專業水平為4 或更低的低頻用戶。

與去年相比，初學者的比例略有增加，超過一半的受訪者使用Solidity 的時間不到一年。

15.5% 的人使用Solidity 超過3 年，因此可以被視為Solidity 老年人。

Solidity 仍然看起來相當容易學習，26.7% 的受訪者在不到一個月的時間內感到高效，30.7% 的受訪者在不到半年的時間內感到高效，7.7% 的人需要一年多的時間才能適應這種語言。

23.3% 的人感覺還沒有效率，其中超過75% 的人是初學者，並且使用Solidity 的時間不超過6 個月。

Solidity 開發人員簡介

大多數（大約80%）受訪者每天或每週都使用Solidity，8% 的人表示「很少」或「從不」使用Solidity，其中幾乎所有主要使用另一種編程語言的代碼都在工作中，大多數人表示他們使用Solidity 的時間還不到3 個月。

超過50% 的人使用VSCode 作為編輯器來編寫Solidity，其次是Visual Studio（14%）和Remix（11%），7% 的受訪者使用Vim，其次是IntelliJ（5.8%）和Atom（3%）。

與2020 年相比，2021 年IntelliJ、Atom、Vim 和Sublime 的使用量減少了。

Hardhat 成為最受歡迎的以太坊專用開發環境，近45% 的受訪者使用它，Truffle 和Remix 緊隨其後，各自的用戶份額約為17%。

相對較少份額的以太坊專用開發環境是Brownie（7.2%）、Dapptools（5.6%）、Scaffold-ETH（3.2%）、Foundry/Forge（1.1%）和Embark（0.5%）。

與2020 年相比，Truffle (2020: 34.6% -> 2021: 17.9%) 和Remix (2020: 29.3% -> 2021: 17%) 份額大幅下降，而Hardhat、Brownie、Dapptools 和Foundry 等新來者的用戶份額增加。

0.8.x Solidity（86.3%）版本是迄今為止最常用的版本，0.7.x（23%）和0.6.x（18.3%）版本系列仍有待使用，而比這更舊的版本幾乎不再被使用。

與2020 年相比，這是一個很大的發展，當時大多數用戶仍在使用0.6.x 版本系列，幸運的是，只有少數人仍在使用0.4.x 或0.5.x 系列的非常舊的版本。

提醒：請確保經常更新您的代碼。自0.4.x 以來添加了幾個重要的錯誤修復和安全改進！

Solidity 用戶體驗

大多數人（大於70%）認為Solidity 開發人員的體驗在去年有所改善，只有1.6% 的人認為情況變得更糟。

當陷入Solidity 問題時，80% 的人會嘗試在以太坊StackExchange 或StackOverflow 上尋找解決方案，許多人還向他們的同事尋求幫助（32.9%）或觀看教程（38.1%），暫時擱置問題去做其他工作，稍後再嘗試解決也很受歡迎（29.2%）。

反復出現的問題

30% 的受訪者在使用Solidity 開發時不會多次遇到相同或相似的問題。其中堆棧太深、字節碼大小限制、調試問題、優化器的不確定性和陣列處理是最常被提及的問題。

特點

未來功

更高效的優化器和捕獲自定義錯誤的能力被列為正在討論的最重要的未來功能。

此外，對小數的支持、更好的陣列管理和修復堆棧太深是最受期待的功能。

我們注意到受訪者使用了各種不同的術語，例如「floats」、「floating point arithmetic」、「floating point number」、「fixed point numbers」、「fixed point math」，我們將這些歸類為「factional numbers」，並假設以上所有內容最終旨在描述「fixed point math」。

最常提到的預期功能按降序排列：

• 「floats」

• 更好的陣列管理/更多的陣列和映射功能

• 修復堆棧太深

• Gas 優化/優化器改進

• 更好的調試

• 更好地支持字符串

• 建設/開發時更容易/更好的Gas 計量

• console.log()

• require() 的自定義錯誤

• generics

• 更好的文檔（尤其是內聯彙編、Yul 等高級內容）

• 通過Yul 的代碼生成

• 自定義值類型

• fixed point mat

• 語言服務提供商

最喜歡和最害怕

受訪者最喜歡Solidity 的簡單性、「易於學習」的方面、默認的SafeMath 和修飾符。

最常提到的喜歡的功能按降序排列：

• 簡單

• 簡單易學

• 特定領域的語言/工作的正確工具/「它有效」

• 默認情況下的SafeMath /over- & underflow 檢查

• 修飾符

• 映射

• 乾淨的語法

• 接口

• 靜態類型

• 可讀性

• inheritance

• 好的工具

• 結構

• 內聯彙編

• delegate call

• require and assertions

• 自定義錯誤

• 內存管理

• 事件

• libraries

• 編譯器安全

• ABIEncoderV2

• 明確性

• 靈活性

• 不變性

• 語言安全

• 面向對象

吐槽最多的關鍵字是是調試、堆棧太深錯誤和缺少對小數的支持。

被吐槽頻次降序排列：

• 調試

• 堆棧太深

• 缺少浮點數/定點數

• 內聯彙編

• 模棱兩可/通用（還原）錯誤消息

• 數組

• 字符串

• 文檔難以閱讀和導航

• 次要版本的重大更改/缺乏兼容性

• 安全

• Gas 成本/部署成本

• inheritance

• 測試

• Gas 優化

• 修飾符

• 社區資源中的過時資源/教程

• 越來越複雜

• returns

• 顯式轉換

• 缺少關於內聯彙編/yul 的文檔

• 缺少console.log

• 內存分配

• 缺少標準庫

• reentrancy

• 類型系統

限制性

60% 的開發者希望Solidity 能夠增加更多檢查點，減少由於判例不足引起的錯誤，提升智能合約開發的準確性，只有約26% 的受訪者對現狀足夠滿意。

Solidity 社區

語言設計

不到20% 的受訪者曾參與過與Solidity 語言設計相關的工作,6.2% 參加了Solidity 論壇的討論，5.1% 參加了語言設計電話會議，6.4% 在Solidity 存儲庫中打開或貢獻了Github 問題。

在大約80% 的未參與語言設計的人中，幾乎8% 的人表示不感興趣，而35% 的人工作太忙，40% 的人不知道如何參與。

隨時了解情況

大多數人喜歡通過在Twitter 或Mastodon 上關注Solidity 來了解Solidity 版本、安全警報和公告的最新信息，其他常用的信息獲取方式是Solidity 博客和Solidity GitHub 發布頁面。

與其他Solidity 開發人員的互動

超過一半的受訪者與其他Solidity 開發人員互動，有趣的是，仍有近45% 的人表示他們很少或從不與其他Solidity 開發人員聯繫。

作為調查的最後一部分，我們想知道有多少參與者同意或不同意關於Solidity 社區和Solidity 團隊工作的一些陳述。

• 75% 的受訪者在Solidity 開發者社區中感到受歡迎。

• 大約80% 的人同意或有點同意他們對Solidity 團隊的工作充滿信心。

• 超過一半的人覺得歡迎為Solidity 做出貢獻，但只有不到一半的人表示他們知道如何為Solidity 貢獻想法或反饋。

• 大約25% 的人相信Solidity 團隊了解他們作為開發人員的需求，另有40% 的人有些同意，而只有一小部分人不同意或強烈不同意。