Google發布針對構建錯誤的研究洞見
英文原文:Google's Study Provides Insights into Programmers' Build Errors
Google 的工程師們最近發布了一份研究論文,針對過去九個月中,Google 內部數以千計的開發者所生成的兩千六百萬份構建進行了實證研究,并給出了一些洞見。這份論文介紹了構建工作流,并分析了失敗頻率和編譯器錯誤類型,以及開發者們解決這些錯誤所做的努力。論文作者們表示,研究結果所引申出的洞見,能幫助我們理解構建過程在大型組織機構中如何發揮作用,以及如何更有效地為開發者們提供支持。
論文作者們認為,研究過程中采用了描繪業界程序員與其編譯器和構建工具如何交互的方法,使得該研究“非常新奇”。此外,他們強調了構建過程的重要性,認為它是“編輯-編譯-調試”循環中的核心步驟:
緩慢的編譯可能會讓程序員被其他任務分心或是丟失當前工作的上下文[…]任何延誤都會放大程序員決定下一步要執行的變更,與查看該變更效果之間的間隔。確保構建過程快速,并了解何時以及為何失敗,是提高程序員生產力的關鍵部分。
研究者們對以下四方面指標的分析,并試著回答一些問題:
- 每個開發者執行的構建數量。
- 構建失敗率。
- 每個錯誤類型實際發生的錯誤數量。
- 開發者解決錯誤所花費的時間。
構建失敗的情況有多頻繁?
構建失敗率的分析結果顯示,“失敗情況接近正態分布。其中,C++構建失敗的中位百分比(38.4%)高于 Java(28.5%)。”研究者們將不同語言之間的差異,歸結于(至少部分程度上):大部分 JAVA 開發者能夠從他們使用的 IDE 所提供的內建的檢查中獲益。
“失敗率極低或極高的開發者都很少見,”而且這兩種類型的開發者似乎都不是某一特定語言或項目的常規參與者(臨時使用該語言或參與該項目)。
對于構建數量與構建失敗率之間,這次的研究并沒有發現強相關現象。因此,或許能夠排除這樣的假設:構建更頻繁的開發者可能會擁有更高的失敗率。
而對于開發者經驗和構建失敗率之間,研究甚至沒有發現相關性,或許某種程度上“這也許是因為很難精確地描繪經驗或專業度。”
構建為何會失敗?
論文中列出了許多構建錯誤,并對其發生頻率進行了測量,如圖 1 所示(點擊查看大圖)。
對于列出的這些錯誤,該論文將其進一步劃分為五大類:依賴性、類型不匹配、語法、語義和其他。錯誤的數量在這五大類型中的分布如圖 2 所示。
對C++(52.68%)和 Java(64.71%)來說,依賴相關的錯誤都是最常見錯誤。而語法方面的錯誤,C++多于 Java。對此,論文作者同樣認為,這是由于 Java 開發者能夠“享受到”更強大的 IDE 所致。
解決構建失敗的問題需要多久?
總的來說,這次的研究發現,解決構建錯誤的中位時間分別是 5 分鐘(C++)和 12 分鐘(Java)。
對于不同錯誤類型來說,這兩個數字可能會有數量級的差異,但平均來說,C++解決時間要少于 Java——不過,部分 C++ 構建錯誤的解決時間的中位數要高于 Java,因為它們更難以解決。
在修訂錯誤之前的構建嘗試方面,無論 Java 還是C++,面對 25 個最常見的錯誤時,75% 的構建錯誤在最多兩次構建中就得以解決了。
調查結果與啟發
這項研究最主要的啟示,作者認為包括以下方面:
- 編程語言無關,90% 的構建失敗分布在大約 10% 的錯誤類型中。
- 依賴性錯誤最常出現。
- 平均來說,修復一個構建錯誤需要一次構建迭代,而大部分錯誤可以在兩次構建迭代中得以解決。
作者們認為研究結果對 IT 從業者和工具開發者來說都很有價值。
<引文>對于 IT 從業者來說,該研究提供了一套手段,用來識別在哪些領域中,額外的專業知識、工具使用或開發行為(例如減少依賴)能夠帶來最大的好處。
另一方面,“更好的能夠解決依賴性錯誤的工具,將帶來最大的潛在回報”。類似地,對錯誤信息和類型所做的定量分析,能夠幫助編譯器團隊識別出,需要重新審視哪些錯誤信息,以便使其對開發者而言更有意義。
最后,希望大家能夠意識到,與任何其他研究報告一樣,這份研究也有其局限性。論文的作者們給出了以下可能影響其有效性的因素:
- 該研究僅在一家公司內部展開,因此受限于特定的流程、制約因素、資源和工具。不過,該研究覆蓋的構建、開發者和涉及系統的數量量級,為社區提供了寶貴的基線。
- 該研究專注于 C++ 和 Java 兩門編程語言。
- 最后,與以下因素有關的抉擇,都可能會影響研究結果的適用性。這些因素包括數據采集、錯誤分級、將錯誤映射到分類方法(歸類),以及為了消除干擾而對數據做的裁剪。
這項研究由 Google 工程師 Caitlin Sadowski、Edward Aftandilian 和 Robert Bowdidge,與香港大學研究員 Hyunmin Seo、Nebraska 大學研究員 Sebastian Elbaum 共同完成。
來自: InfoQ