1. 引言

研究背景：現(xiàn)代生產(chǎn)代碼庫極其復(fù)雜并且不斷更新。靜態(tài)分析器可以幫助開發(fā)人員發(fā)現(xiàn)代碼中的潛在問題（在本文的其余部分中稱為錯誤），這對于在這些大型代碼庫中保持高代碼質(zhì)量是必要的。雖然通過靜態(tài)分析盡早發(fā)現(xiàn)錯誤是有幫助的，但修復(fù)這些錯誤的問題在實(shí)踐中仍然主要是手動任務(wù)，阻礙了靜態(tài)分析工具的采用。

現(xiàn)存問題：大多數(shù)靜態(tài)分析器都會查找常見錯誤類別的實(shí)例，例如潛在的空取消引用、流行 API 的錯誤使用或特定語言結(jié)構(gòu)的誤用。研究團(tuán)隊(duì)觀察到，針對特定錯誤類別的修復(fù)通常彼此相似：它們有一個模式。也就是說，過去人類對同一錯誤類別的修復(fù)可能會提供有關(guān)如何修復(fù)該錯誤類別的未來實(shí)例的見解。鑒于這一觀察，是否可以通過學(xué)習(xí)過去的修復(fù)來自動修復(fù)發(fā)現(xiàn)的錯誤？

研究內(nèi)容：論文通過學(xué)習(xí)過去的修復(fù)來解決自動修復(fù)常見錯誤類別實(shí)例的問題。論文假設(shè)兩個輸入：（1）修復(fù)特定類型錯誤的一組更改，例如來自代碼庫的版本歷史記錄。這些變化可以作為訓(xùn)練數(shù)據(jù)來學(xué)習(xí)修復(fù)模式。(2) 一段帶有我們要修復(fù)的靜態(tài)分析警告的代碼。僅給出這兩個輸入，問題是預(yù)測解決方案，以類似于或等于人類開發(fā)人員所做的方式解決靜態(tài)分析警告。通過自動生成修復(fù)程序并僅將是否應(yīng)用修復(fù)程序的最終決定留給人類，可以大大減少解決靜態(tài)分析器指出的錯誤所花費(fèi)的總體工作量。

論文專注于那些具有不平凡但重復(fù)性修復(fù)的錯誤。一方面，有些錯誤類別通常意味著特定的修復(fù)。例如，對于建議某個字段為最終結(jié)果的警告，實(shí)施自動修復(fù)建議非常簡單。這種自動修復(fù)可以由該規(guī)則的作者在靜態(tài)分析器中定義，而不需要知道應(yīng)用該規(guī)則的特定上下文；事實(shí)上，有些容易出錯規(guī)則帶有自動修復(fù)功能。另一方面，一些錯誤需要復(fù)雜的、特定于應(yīng)用程序的修復(fù)，例如用戶進(jìn)行一系列特定交互后 UI 選項(xiàng)卡不顯示的問題。在這里，論文的目標(biāo)是介于這兩個極端之間的錯誤類別，其中找到修復(fù)程序并非易事，但典型的修復(fù)程序?qū)儆谝唤M重復(fù)出現(xiàn)的修復(fù)模式。對于此類錯誤類別，通常存在不止一種方法來解決問題，并且解決錯誤類別的特定實(shí)例的正確方法取決于上下文，例如，靜態(tài)分析警告周圍的代碼。

作為本工作中針對的錯誤類別的一個示例，請考慮 NullPointerExceptions 仍然是 Java 和其他語言中最普遍的錯誤之一。如果靜態(tài)分析器警告潛在的空取消引用，開發(fā)人員可以通過各種方式解決該問題。上圖顯示了空取消引用錯誤修復(fù)的三個匿名示例，這些示例分別向現(xiàn)有 if 條件添加了一個連接、用三元運(yùn)算替換了調(diào)用以及添加了提前返回。雖然所有這些修復(fù)都引入了某種空檢查，但確切的修復(fù)在很大程度上取決于現(xiàn)有的代碼。除了這些示例之外，還有更多方法可以修復(fù)空取消引用錯誤，例如，通過添加新的 if 語句或以分離方式擴(kuò)展現(xiàn)有的 if 條件。學(xué)習(xí)所有這些修復(fù)模式并決定將哪一種模式應(yīng)用于給定的錯誤代碼是一個不小的問題。論文的工作旨在自動修復(fù)大規(guī)模工業(yè)軟件開發(fā)中的錯誤。 這種設(shè)置會帶來一些有趣的挑戰(zhàn)：

• 為了減少修復(fù)錯誤所花費(fèi)的人力時間，該方法可能只提出少量潛在的修復(fù)方案，最好只提出一個修復(fù)方案。
• 為了使此修復(fù)為開發(fā)人員所接受，建議的修復(fù)應(yīng)該類似于人類：與人類開發(fā)人員將實(shí)現(xiàn)的修復(fù)非常相似或完全相同。