Človeški konkurenčni popravki v samodejnem popravilu programov z Repairnatorjem

Repairnator je bot. Nenehno spremlja programske napake, odkrite med nenehnim vključevanjem odprtokodne programske opreme, in jih poskuša samodejno odpraviti. Če uspe sintetizirati veljaven obliž, Repairnator predlaga obliž človeškim razvijalcem, preoblečenim v ponarejeno človeško identiteto. Do danes je Repairnator uspel izdelati 5 popravkov, ki so jih sprejeli človeški razvijalci in jih trajno združili v kodno bazo. To je mejnik za človekovo konkurenčnost v raziskavah programskega inženiringa za samodejno popravilo programov. V tej objavi pripovedujemo zgodbo o tej raziskavi, opravljeni na KTH Royal Institute of Technology, Inria, University of Lille in University of Valenciennes.

Raziskave o popravilu programov zasledujejo idejo, da algoritmi lahko nadomestijo ljudi, da odpravijo programske napake [4]. Odpravljanje napak je popravek, ki vstavi, izbriše ali spremeni izvorno kodo. Na primer, v naslednjem popravku je razvijalec spremenil stanje stavka if:

- če (x <10)
+ če (x <= 10)
foo ();

Bot za popravilo programa je umetno sredstvo, ki poskuša sintetizirati popravke izvorne kode. Analizira napake in izdeluje popravke, enako kot razvijalci ljudi, ki sodelujejo v dejavnostih vzdrževanja programske opreme. Ta ideja programa za popravilo programov je moteča, saj so danes ljudje odgovorni za odpravljanje napak. Z drugimi besedami, govorimo o botru, ki naj bi deloma nadomestil človeške razvijalce za dolgočasne naloge.

Ko bot poskuša doseči nalogo, ki jo običajno opravijo ljudje, je znana kot človeško-tekmovalna naloga [1]. Empirične ocene raziskav o popravilu programov [3] kažejo, da so trenutni sistemi za popravilo programov sposobni sintetizirati popravke za resnične napake v resničnih programih. Vendar so bili vsi ti popravki sintetizirani za pretekle napake, za hrošče, ki so jih odpravljali človeški razvijalci v preteklosti, običajno že pred leti. Čeprav to kaže na tehnično izvedljivost popravila programa, pa to ne kaže, da je popravilo programa človeško konkurenčno.

Konkurenčnost človeka

Da bi dokazali, da je popravilo programa človeško konkurenčno, mora programski program za popravilo programske opreme najti visokokakovostni obliž, preden to stori človek. V tem okviru se lahko šteje, da je obliž človeško konkurenčen, če izpolnjuje oba pogoja pravočasnosti in kakovosti. Pravočasnost se nanaša na dejstvo, da mora sistem najti obliž pred razvijalcem človeka. Z drugimi besedami, prototipni sistem mora izdelati popravke v vrstnem redu minut, ne dni. Tudi obliž, ki ga ustvari bot, mora biti dovolj pravilen, podobne kakovosti - pravilen in berljiv - v primerjavi z obližem, ki ga je napisal človek. Upoštevajte, da obstajajo obliži, ki z vidika bota izgledajo pravilno, vendar so napačni (to je v literaturi znano kot preoblikovanje popravkov [6, 3]). Ti obliži verjetno niso konkurenčni človeku, ker jih ljudje nikoli ne bi sprejeli v svojo kodno bazo.

Torej, da je obliž konkurenčen človeku 1) bot mora sintezo sintetizirati hitreje kot človeški razvijalec 2) človeški razvijalec mora patch presoditi dovolj dobro in ga trajno združiti v kodno bazo.

Upoštevati je treba še en vidik. Pokazalo se je, da človeški inženirji prispevkov botov ne sprejemajo tako enostavno kot prispevki drugih ljudi, čeprav so strogo enaki [5]. Razlog je v tem, da imajo ljudje a priori pristranskost do strojev in so bolj strpni do napak, če prispevek izvira iz človeških vrstnikov. V okviru popravila programov to pomeni, da lahko razvijalci postavijo višjo raven kakovosti popravka, če vedo, da obliž prihaja iz robota. To bi oviralo naše prizadevanje za dokaz človekove konkurenčnosti v okviru popravila programa.

Da bi odpravili to težavo, smo se že zgodaj v projektu odločili, da bomo vse popravke popravljalcev predlagali pod ponarejeno človeško identiteto. Ustvarili smo uporabnika GitHub-a z imenom Luc Esape, ki je v programskem inženirju predstavljen v našem raziskovalnem laboratoriju. Luc ima sliko profila in je videti kot mlajši razvivalec, ki želi pripraviti prispevke z odprtimi kodami za GitHub. Zdaj si predstavljajte Repairnator, preoblečen kot Luc Esape, ki predlaga obliž: razvijalci, ki ga pregledujejo, mislijo, da pregleda človeški prispevek. Ta kamuflaža je potrebna za preizkušanje naše znanstvene hipoteze o človekovi konkurenčnosti. Zdaj je zaradi etike razkrita prava identiteta Luca na vsaki njegovi prošnji.

Samodejno popravilo in stalna integracija

Nenehna integracija, imenovana tudi CI, je ideja, da strežnik zbere kodo in izvede vse preizkuse za vsako zavezo, opravljeno v sistemu za nadzor različic programskega projekta (npr. Git). V parlamentarnem sporazumu CI obstaja vsaka zaveza. Sestava vsebuje informacije o uporabljenem posnetku izvorne kode (npr. Sklic na ukaz Git), rezultatu sestavljanja in izvedbe preizkusa (npr. Neuspeh ali uspeh) in dnevniku sledenja izvedbe. Če sestavljanje ne uspe ali vsaj en testni primer ne uspe, sestava ne uspe. Pokazalo se je, da približno ena od štirih konstrukcij ne uspe in da je najpogostejši vzrok za neuspeh gradnje testna napaka [8].

Ključna ideja Repairnatorja je, da samodejno ustvari popravke, ki popravijo napake pri gradnji, nato pa jih pokaže ljudem razvijalcem, da na koncu vidijo, ali jih bodo ti človeški razvijalci sprejeli kot veljavne prispevke k zbirki. Če se to zgodi, bi to kazalo na konkurenčnost ljudi pri popravilu programov.

Ta nastavitev - avtomatično odpravljanje napak pri gradnji, ki se dogajajo v stalni integraciji - je še posebej primerna in pravočasna iz naslednjih razlogov. Prvič, napake v gradnji ustrezajo izjavi o težavi popravka programa, ki temelji na testnem programu [4], kjer so napake določene kot neuspešni testni primeri, tisti neuspešni preskusni primeri pa se uporabljajo za pogon samodejne sinteze popravka [4]. Drugič, omogoča primerjavo botov in ljudi na pošteni osnovi: ko se na strežniku za neprekinjeno integracijo odkrije neuspešni test, se človeški razvijalec in bot obvestita o njem ob istem času. To obvestilo o neuspehu pri preizkusu je izhodišče tekmovanja med ljudmi in boti.

Osredotočenost Repairnatorja na napake pri gradnji je edinstvena, vendar se prilega veliki sliki inteligentnih botov za programsko opremo [2]. Na primer, Facebook ima orodje, imenovano SapFix, ki popravlja napake, najdene z avtomatskim testiranjem. Tudi v zvezi s tem se napadalci in zagovorniki DARPA Cyber ​​Grand Challenge bota trudijo biti človeško konkurenčni glede varnostnih strokovnjakov.

Popravila v matici

V letih 2017–2018 smo zasnovali, izvedli in upravljali Repairnator, bot za samodejno popravilo programa. Repairnator je specializiran za popravilo napak v gradnji, ki se zgodijo med nenehno integracijo. Nenehno spremlja tisoče komitentov, ki jih potisne na platformo gostovanja kode GitHub, in analizira njihove ustrezne sestavine. Vsako minuto sproži nove poskuse popravljanja, da bi odpravil napake pred človeškim razvijalcem. Zasnovan je tako, da gre čim hitreje, ker sodeluje na dirki: če Repairnator najde popravek pred razvijalcem človeka, je človeško konkurenčen.

Dajmo zdaj pregled nad delovanjem bona Repairnatorja.

Primarni vložek Repairnatorja so neprekinjene gradnje integracij, ki jih sprožijo zaveze razvijalcev (zgornji del slike, (a) in (b)), ki temeljijo na projektih GitHub (a). Izhodi Repairnatorja so dvojni: (1) samodejno ustvari popravke za popravilo okvarjenih sestav (g), če obstajajo; (2) zbira dragocene podatke za prihodnje raziskave popravil programov (h) in (k). Repairnator stalno nadzira vse neprekinjene aktivnosti projektov GitHub ©. Konstrukcije CI so podane kot vhod v tristopenjski cevovod: (1) prva stopnja zbira in analizira dnevnike gradnje CI (e); (2) druga faza je namenjena lokalnemu reproduciranju napak na gradnji, ki so se zgodile na CI (f); (3) tretja faza izvaja različne prototipe popravil programov, ki izhajajo iz najnovejših akademskih raziskav. Ko najdete popravek, član projekta Repairnator opravi hiter pregled, da se izogne ​​izgubi dragocenega časa razvijalcev odprtega izvora. (i) Če ugotovi, da je obliž nedegeneriran, ga predlaga prvotnim razvijalcem projekta kot povlečevalno zahtevo za GitHub (j). Razvijalci nato sledijo običajnemu postopku pregleda kode in združijo.

Repairnator mora delovati v danem programskem ekosistemu. Zaradi našega strokovnega znanja z Javo v preteklih raziskovalnih projektih se prototipska izvedba Repairnatorja osredotoča na popravilo programske opreme, napisane v programskem jeziku Java, ki je bila zgrajena z orodjarno Maven, v odprtokodnih projektih, ki jih gosti GitHub, ki uporabljajo platformo stalne integracije Travis CI .

Dosežki ekspedicije

Repairnator upravljamo od januarja 2017 v treh različnih fazah. V enem mesecu, januarja 2017, smo izvedli pilotni poskus z začetno različico prototipa. Od 1. februarja 2017 do 31. decembra 2017 smo vodili Repairnator s fiksnim seznamom 14.188 projektov, ki mu rečemo "ekspedicija # 1". Od 1. januarja 2018 do 30. junija 2018 je Repairnator v realnem času spremljal tok gradnje Travis CI, pravimo mu "ekspedicija # 2"

Glavni cilj pilotnega eksperimenta je bil potrditi naš dizajn in prvotno izvedbo. Ugotovili smo, da lahko naš prototip glede na naše računalniške vire opravi približno 30 poskusov popravljanja na dan. Še pomembneje je, da je ta pilotni poskus potrdil naše temeljne tehnološke predpostavke: velik del priljubljenih odprtokodnih projektov uporablja Travis in večina jih uporablja Maven kot tehnologijo za gradnjo. To je pomenilo, da bomo imeli poštene možnosti, da uresničimo svoj cilj sintetiziranja človeško konkurenčnega popravka v tem kontekstu.

Med ekspedicijo # 1, katere rezultati so podrobno predstavljeni v [7], je Repairnator analiziral 11.523 konstrukcij s testnimi napakami. Za 3551 od teh (30,82%) je Repairnator uspel lokalno reproducirati testno napako. Od 3551 poskusov popravljanja je Repairnator našel 15 popravkov, zaradi katerih je CI lahko prešel. Vendar pa je naša analiza popravkov pokazala, da noben od teh popravkov ni bil konkurenčen človeku, ker so prišli prepozno (Repairnator je izdelal obliž po človekovem razvijalcu) ali so bili slabe kakovosti (naredili so gradnjo uspešno naključno).

Ekspedicija # 2 je uspešna. Pokazalo se je, da je tehnologija popravljanja programov prestopila mejo človekove konkurenčnosti. Repairnator je izdelal 5 obližev, ki izpolnjujejo zgoraj določena merila človekove konkurenčnosti: 1) obliži so bili proizvedeni pred človeškimi, 2) je razviti človeški obliž sprejel kot veljavne prispevke in obliže je združil v osnovno kodno bazo.

Prispevki, ki jih konkurenca človek, o Githubu, obližih, ki jih je sintetiziral robot Repairnator in jih je sprejel človeški razvijalec:

  • 12. januar 2018, aaime / geowebcache / pull / 1, "Hvala za obliž!"
  • 23. mar. 2018, parkito / BasicDataCodeU […] / pull / 3 „združeni zavezi 140a3e3 v parkito: razvoj“
  • 5. april 2018, dkarv / jdcallgraph / pull / 2 "Hvala!"
  • 3. maj 2018, eclipse / ditto / pull / 151 "Kul, hvala za potek postopka Eclipse in za popravek."
  • 25. junij 2018, donnelldebnam / CodeU […] / pull / 151 "Hvala !!"

Prvi obliž, ki ga je združil naš programski program za popravilo, je človeški razvijalec sprejel 12. januarja 2018. Tu je zgodba: 12. januarja 2018 ob 12:28 je bila sprožena gradnja na projektu aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Po dveh minutah izvedbe sestava ni uspela, ker sta bila dva testna primera napačna. Čez nekaj minut, 12. januarja 2018 ob 13:08, je Repairnator med rednim nadzorom odkril napačno zgradbo in začel zagnati razpoložljive sisteme za popravilo programov, konfigurirane v Repairnatorju. Deset minut kasneje, ob 13:18, je našel obliž.

12. januarja 2018 ob 13:35 je član ekipe Repairnator vzel obliž, ki ga je ustvaril Repairnator, in potrdil odprtje ustrezne zahteve za povleko v GitHubu. 12. januarja 2018, ob 14.10, je razvijalka sprejela obliž in ga združila s komentarjem: "Čudno, mislil sem, da sem to že odpravil ... morda sem to storil na drugem mestu. Hvala za obliž! ”. To je bil prvi obliž, ki ga je izdelal Repairnator in ga je veljavni prispevek sprejel človeški razvijalec, dokončno združen v bazi kod. Z drugimi besedami, Repairnator je bil prvič konkurenčen človeku.

Po šestih mesecih delovanja je Repairnator s strani človeških razvijalcev združil 5 popravkov, ki so navedeni zgoraj.

Na splošno je projekt Repairnator izpolnil svoje poslanstvo. Pokazalo se je, da se popravilo programov lahko šteje za človeško konkurenčno: Repairnator je našel obliže 1) pred ljudmi, 2) ki so jih ljudje šteli za dobro kakovost.

Prihodnost

Projekt Repairnator je poleg tega, da je pokazal, da je popravilo programov človeško konkurenčno, zagotovil veliko informacij o napakah in stalni integraciji ter o trenutnih pomanjkljivostih raziskav o popravilu programov, predstavljenih v [7].

Poglejmo predvsem eno točko, vprašanje intelektualne lastnine. 3. maja 2018 je Repairnator izdelal dober obliž za GitHub projekt eclipse / ditto. Kmalu potem, ko je predlagal obliž, je eden od razvijalcev vprašal: "Sprejemamo lahko samo zahteve po povleku, ki prihajajo od uporabnikov, ki so podpisali licenčno pogodbo za prispevke Eclipse Foundation." Zmedli so nas, ker bot ne more fizično ali moralno podpisati licenčne pogodbe in do tega verjetno ni upravičen. Kdo je lastnik intelektualne lastnine in odgovornosti za prispevek bot-a: operater robota, izvajalec bota ali oblikovalec algoritma za popravilo? To je eno izmed zanimivih vprašanj, ki jih je odkril projekt Repairnator.

Verjamemo, da Repairnator oblikuje določeno prihodnost razvoja programske opreme, kjer bodo boti in ljudje nemoteno sodelovali in celo sodelovali pri umetniških artefaktih.

Želite se pridružiti skupnosti Repairnator? Če želite prejemati redne novice o Repairnatorju, streljajte po e-pošti na repairnator.subscribe@4open.science!

- Martin Monperrus, Simon Urli, Thomas Durieux, Matias Martinez, Benoit Baudry, Lionel Seinturier

V medijih:

  • Skrivnostno življenje Luca Esapeja, dodatnega popravljalca hroščev. Njegova velika skrivnost? Ni človek (Thomas Claburn, Register)

Reference

  • [1] J. R. Koza (2010) Človeško-konkurenčni rezultati, ki jih prinaša genetsko programiranje. Genetsko programiranje in evolucijski stroji 11 (3–4), str. 251–284. Navedel:.
  • [2] C. Lebeuf, M. D. Storey in A. Zagalsky (2018) Programska oprema. IEEE Software 35, str. 18–23. Citiral: Samodejno popravilo in stalna integracija.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan in M. Monperrus (2016) Samodejno popravilo pravih hroščev na Javi: obsežni eksperiment nabora podatkov o defektih4j. Empirični programski inženiring, str. 1–29. Navedel: Konkurenčnost človeka,.
  • [4] M. Monperrus (2017) Samodejno popravilo programske opreme: bibliografija. Računalniške ankete ACM. Citiral: Samodejno popravilo in stalna integracija,.
  • [5] A. Murgia, D. Janssens, S. Demeyer in B. Vasilescu (2016) Med stroji: Interakcija človek-bot na socialnih q & spletnih straneh. V zborniku s konference 2016 CHI je razširil povzetke o človeških dejavnikih v računalniških sistemih, str. 1272–1279. Navedla: Konkurenčnost človeka.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues in Y. Brun (2015) Ali je zdravljenje slabše od bolezni? overfitting v avtomatiziranem popravilu programa. V zborniku desetega skupnega sestanka o temeljih programskega inženiringa 2015, str. 532–543. Zunanje povezave: Dokument, ki ga navaja: Konkurenčnost človeka.
  • [7] S. Urli, Z. Yu, L. Seinturier in M. Monperrus (2018) Kako oblikovati programski popravek? Vpogled v projekt Repairnator. Na mednarodni konferenci ICSE 2018–40. O programskem inženiringu, sledenju programskega inženiringa v praksi, zunanjih povezavah: povezava, ki jo navaja: Dosežki ekspedicije, prihodnost.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta in S. Panichella (2017) Zgodba o napakah pri gradnji CI: Open-source in perspektiva finančne organizacije Na Mednarodni konferenci o vzdrževanju in razvoju programske opreme, ki jo navaja: Samodejno popravilo in stalna integracija.