CodeWisdom-技術(shù)分享

萬萬沒想到！編譯錯誤竟然還沒滅絕？？？

復(fù)旦大學(xué)CodeWisdom團隊的代碼分析和挖掘小組針對開源軟件項目持續(xù)集成過程中出現(xiàn)的編譯錯誤，進行了大規(guī)模的經(jīng)驗研究。該研究分析了常見的編譯錯誤類型、修復(fù)代價以及修復(fù)模式，研究結(jié)果對于開發(fā)人員和研究人員具有一定的啟示作用。基于該研究的論文“A Large-Scale Empirical Study of Compiler Errors in Continuous Integration”發(fā)表在軟件工程領(lǐng)域的頂級國際會議FSE 2019上。

論文作者包括復(fù)旦大學(xué)的張晨、陳碧歡、陳琳琳、彭鑫、趙文耘。

論文鏈接地址：

https://dl.acm.org/citation.cfm?id=3338917(閱讀原文進入論文主頁)

有bug了！

每個人都有自己的死穴。對于程序猿來說，這句話絕對在死穴排行榜上名列前茅。看著一份份染著鮮血的bug日志，血壓都升高了。

而持續(xù)集成(CI)就像是一個故意懲罰程序猿的魔鬼，讓bug日志的暴風(fēng)雨，比往日來的更猛烈了一些。

我們先來看看啥叫CI, CI是一種軟件開發(fā)實踐，它要求開發(fā)人員頻繁的編譯、靜態(tài)分析、測試和集成變更代碼。

相信聰明的你一眼看穿了CI的”本質(zhì)”，可不就是更多的bug報告嘛！

但是事情往往不像表面看上去那樣簡單。由于CI頻繁的構(gòu)建代碼，使得bug能被盡早發(fā)現(xiàn)，反而降低了程序猿負擔(dān)。瞧！這一個個bug是不是變的可愛起來？

由于可以自動化構(gòu)建過程，確保軟件開發(fā)的速度和質(zhì)量，CI得到了廣泛的使用。盡管CI已被廣泛使用，但它仍然存在許多問題。比如，CI構(gòu)建經(jīng)常失敗。

編譯錯誤作為導(dǎo)致構(gòu)建失敗的主要原因之一，我們對其還缺乏了解，例如常見的編譯錯誤類型、修復(fù)代價以及修復(fù)模式。

因此，在這項研究中，我們爬取了Github上3,799個開源Java項目的Travis?CI構(gòu)建數(shù)據(jù)，從四個角度：頻率、分布、修復(fù)代價以及修復(fù)模式，對編譯錯誤進行了分析。

總數(shù)據(jù)量大概三四個TB吧，有需要的聯(lián)系我們哦~

廢話不多說，看看結(jié)果吧~

圖1展示了編譯錯誤出現(xiàn)的頻率。75%的項目的構(gòu)建出現(xiàn)過編譯器錯誤。在失敗的構(gòu)建中，11%是由編譯錯誤引起的。

嗯，看起來編譯錯誤出現(xiàn)的還挺頻繁的。咦？明明IDE會提醒代碼中的編譯錯誤，怎么還有這么多？畢竟總有些程序猿喜歡特立獨行，偏偏不用IDE嘛！此外，你電腦的運行環(huán)境和CI的環(huán)境往往有一些差別，這可能導(dǎo)致問題在CI構(gòu)建時才暴露出來哦！

圖1 頻率

圖2展示了常見的編譯錯誤類型。最常見的錯誤類型是cant.resolve，占比54%。當(dāng)編譯器無法識別代碼中的符號時，會報出此錯誤。doesnt.exist占比15.9%，該錯誤發(fā)生的原因是因為編譯器無法找到代碼中引用的包。在所有出現(xiàn)的編譯錯誤中，最常見的10種類型占比90.2%。

所以，聰明的你知道在研究編譯錯誤時，該針對哪些類型了吧。

圖2 分布

圖3展示了10種最常見編譯錯誤類型的修復(fù)時間，從左到右，修復(fù)時間由18分鐘增長至97分鐘。相比expected, doesnt.exist 和cant.resolve等錯誤， does.not.override.abstract 和method.does.not.override.superclass需要花費兩倍以上的修復(fù)時間，因為它們的修復(fù)往往會涉及方法中邏輯代碼的實現(xiàn)。

看起來，程序猿小哥哥和程序媛小姐姐似乎在碰到靠右邊的錯誤類型時，更需要幫助呢~相信你開發(fā)的自動debug和修復(fù)工具會大大加快他們的工作效率。

圖3 修復(fù)代價

圖4展示了常見編譯錯誤的修復(fù)模式，第一列代表錯誤類型，第二列簡要描述了該錯誤類型，第三列展示了相應(yīng)的修復(fù)模式。我們發(fā)現(xiàn)大多數(shù)修復(fù)模式都很簡單，只涉及幾行代碼的更改，這表明自動修復(fù)常見的編譯器錯誤是可行的。但是，每種編譯錯誤都對應(yīng)多種修復(fù)方式，就拿cant.reslove來說吧，它有10種修復(fù)模式，這意味著對于每一個該類型的錯誤，你都有10種手段來解決，那究竟哪種是程序猿真正想要的？想想就讓人頭大。

圖4 修復(fù)模式

當(dāng)前IDE已經(jīng)提供了一定的編譯器錯誤修復(fù)功能。我們測試了兩種被廣泛使用的IDE, Eclipse和IntelliJ IDEA，來確定它們能否提供我們確定的修復(fù)模式作為修復(fù)建議，以及在不借助人工幫助的情況下，是否能夠自動修復(fù)錯誤，上圖中第四至第七欄展示了相關(guān)結(jié)果。

在48種修復(fù)模式中，Eclipse和IntelliJ IDEA分別提供32種和29種修復(fù)模式。在提供的模式中，Eclipse和IntelliJ IDEA只支持7種和4種模式的自動修復(fù)。從結(jié)果可以看出，當(dāng)前IDE對于編譯錯誤修復(fù)提供的支持非常有限。我們總結(jié)的修復(fù)模式可以用來進一步完善IDE的相關(guān)功能。

IDE的自動修復(fù)功能實在是要加把勁啊！

CodeWisdom

歡迎關(guān)注CodeWisdom，Codewisdom平臺由復(fù)旦大學(xué)軟件工程實驗室運營，提供智能化軟件開發(fā)平臺及線上沙龍相關(guān)資訊，關(guān)注可了解更多智能化軟件開發(fā)的最新消息~

總結(jié)

以上是生活随笔為你收集整理的ora 00900 已编译但有错误_技术分享|万万没想到！编译错误竟然还没灭绝???的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。