Žmonėms konkurencingi pataisymai automatiniame programų taisyme su „Repairnator“

Remontas yra robotas. Jis nuolat stebi programinės įrangos klaidas, aptinkamas nuolat integruojant atvirojo kodo programinę įrangą, ir bando jas automatiškai ištaisyti. Jei pavyksta susintetinti galiojantį pleistrą, „Repairnator“ pasiūlo pleistrą žmonių kūrėjams, paslėptą pagal netikrą žmogaus tapatybę. Iki šiol „Repairnator“ sugebėjo pagaminti 5 pataisas, kurias priėmė žmonių kūrėjai ir visam laikui sujungė į kodų bazę. Tai yra žmogaus konkurencingumo etapas atliekant programinės įrangos inžinerijos tyrimus, susijusius su automatiniu programų taisymu. Šiame įraše papasakosime istoriją apie šį tyrimą, atliktą KTH Karališkajame technologijos institute, Inrijoje, Lilio ir Valensieno universitetuose.

Programų taisymo tyrimais siekiama minties, kad algoritmai gali pakeisti žmones, norėdami ištaisyti programinės įrangos klaidas [4]. Trikčių taisymas yra pataisymas, įterpiantis, ištrinantis arba modifikuojantis šaltinio kodą. Pvz., Šiame pakeitime kūrėjas pakeitė teiginio if sąlygą:

- jei (x <10)
+ jei (x <= 10)
foo ();

Programos taisymo botas yra dirbtinis agentas, bandantis susintetinti šaltinio kodo pataisas. Jis analizuoja klaidas ir gamina pataisas, kaip ir žmonių kūrėjai, užsiimantys programinės įrangos priežiūros veikla. Ši programos taisymo programos idėja yra žlugdanti, nes šiandien žmonės yra atsakingi už klaidų taisymą. Kitaip tariant, mes kalbame apie robotą, skirtą (iš dalies) pakeisti žmonių kūrėjus varginančiomis užduotimis.

Kai botas bando įvykdyti užduotį, kurią paprastai atlieka žmonės, ji yra žinoma kaip užduotis, dėl kurios konkuruoja žmonės [1]. Empiriniai programų taisymo tyrimų vertinimai [3] rodo, kad dabartinės programų taisymo sistemos sugeba sintetinti pataisas, skirtas tikroms klaidoms tikrose programose. Tačiau visi tie pleistrai buvo susintetinti dėl ankstesnių klaidų, dėl klaidų, kurias anksčiau, dažniausiai prieš metus, taisė žmonių kūrėjai. Nors tai rodo techninį programos taisymo įgyvendinamumą, tai neįrodo, kad programos taisymas yra konkurencingas žmonėms.

Žmogaus konkurencingumas

Norėdami parodyti, kad programos taisymas yra konkurencingas žmonėms, programos taisymo robotas turi rasti aukštos kokybės pataisą, prieš tai padarydamas žmogus. Šiuo atveju pleistras gali būti laikomas konkurencingu žmonėms, jei jis atitinka dvi savalaikiškumo ir kokybės sąlygas. Savalaikiškumas reiškia tai, kad sistema turi rasti pataisą prieš žmogaus kūrėją. Kitaip tariant, prototipų sistema turi sudaryti pataisas minučių, o ne dienų, tvarka. Taip pat roboto pagamintas pleistras turi būti pakankamai teisingas, panašios kokybės - teisingas ir lengvai skaitomas - palyginti su žmogaus užrašytu pleistru. Atminkite, kad yra pleistrų, kurie roboto požiūriu atrodo teisingi, tačiau jie nėra teisingi (literatūroje tai vadinama pertekliniais pleistrais [6, 3]). Šie pleistrai neabejotinai nėra konkurencingi žmonėms, nes žmonės niekada jų nepriimtų į savo kodą.

Taigi tam, kad pleistras būtų konkurencingas žmonėms 1) robotas turi susintetinti pleistrą greičiau nei žmogaus kūrėjas 2) pleistras turi būti pakankamai gerai įvertintas žmogaus kūrėjo ir visam laikui sujungtas į kodo bazę.

Reikia atsižvelgti į dar vieną aspektą. Įrodyta, kad žmonių inžinieriai nepriima botų įmokų taip lengvai, kaip kitų žmonių indėliai, net jei jie yra griežtai identiški [5]. Priežastis ta, kad žmonės paprastai turi a priori nusistatymą prieš mašinas ir yra labiau tolerantiški klaidoms, jei indėlį teikia žmogaus bendraamžiai. Programos taisymo kontekste tai reiškia, kad kūrėjai gali pakelti pataisų kokybės juostą aukščiau, jei jie žino, kad pataisymas kilo iš roboto. Tai kliudytų mūsų siekiui įrodyti žmonių konkurencingumą programų taisymo kontekste.

Norėdami išspręsti šią problemą, projekto pradžioje nusprendėme, kad visi „Repairnator“ pleistrai bus siūlomi suklastota žmogaus tapatybe. Mes sukūrėme „GitHub“ vartotoją, pavadintą Luc Esape, kuris pristatomas kaip programinės įrangos inžinierius mūsų tyrimų laboratorijoje. Lukas turi profilio nuotrauką ir atrodo kaip jaunesnysis kūrėjas, norintis prisidėti prie atvirojo kodo „GitHub“. Įsivaizduokite „Repairnator“, paslėptą kaip Lucas Esape'as, siūlantis pataisą: ją peržiūrėjęs kūrėjas mano, kad ji peržiūri žmogaus indėlį. Šis kamufliažas reikalingas norint patikrinti mūsų mokslinę žmogaus konkurencingumo hipotezę. Etikos sumetimais tikroji Luko tapatybė buvo atskleista kiekviename jo prašyme.

Automatinis taisymas ir nuolatinė integracija

Nuolatinė integracija, dar vadinama CI, yra idėja, kad serveris surenka kodą ir vykdo visus bandymus kiekvienam įsipareigojimui, padarytam programinės įrangos projekto versijos valdymo sistemoje (pvz., „Git“). Kalbant apie CI, kiekvienas įsipareigojimas yra kuriamas. Sudėtyje yra informacijos apie naudojamą šaltinio kodo momentinį vaizdą (pvz., Nuorodą į „Git“ įsipareigojimą), kompiliavimo ir bandymo vykdymo rezultatą (pvz., Nesėkmę ar sėkmę) ir vykdymo pėdsakų žurnalą. Sakoma, kad sudėjimas nepavyksta, jei nepavyksta kompiliuoti arba bent vienas bandomasis pavyzdys nepavyksta. Įrodyta, kad maždaug vienas iš 4 statinių sugenda ir kad dažniausiai pasitaikanti pastato gedimo priežastis yra bandymo gedimas [8].

Pagrindinė „Repairnator“ idėja yra automatiškai sugeneruoti pataisas, atitaisančias pastato gedimus, tada parodyti jas žmonių kūrėjams ir pagaliau išsiaiškinti, ar tie žmonių kūrėjai juos priims kaip pagrįstą indėlį į kodo bazę. Jei taip atsitiks, tai bus žmonių konkurencingumo programos taisymo įrodymas.

Ši sąranka - automatiškai taisanti nuolatinės integracijos triktis, yra ypač tinkama ir tinkama dėl šių priežasčių. Pirma, konstravimo gedimai patenkina pagrindinį bandomųjų programų paketo taisymo problemos pareiškimą [4], kur klaidos nurodomos kaip nesėkmingi bandymo atvejai, o tie nesėkmingi atvejai naudojami automatinei pataisos sintezei skatinti [4]. Antra, tai leidžia sąžiningai palyginti robotus ir žmones: kai nenutrūkstamo integravimo serveryje aptinkamas nesėkmingas testas, žmogaus kūrėjas ir robotas yra tuo pačiu informuojami. Šis bandymo nesėkmės pranešimas yra atskaitos taškas varžyboms tarp žmonių ir robotų.

„Repairnator“ dėmesys sutelkimo gedimams yra unikalus, tačiau jis tinka dideliame programinės įrangos intelektualiųjų robotų paveikslėlyje [2]. Pavyzdžiui, „Facebook“ turi įrankį, vadinamą „SapFix“, kuris taiso klaidas, rastas atliekant automatinius bandymus. Tai taip pat susiję su „DARPA Cyber ​​Grand Challenge“ botų užpuolikais ir gynėjais, siekiant saugumo ekspertų.

Remontas trumpai

2017–2018 m. Mes sukūrėme, įdiegėme ir eksploatavome automatinį programos taisymo robotą „Repairnator“. „Repairnator“ specializuojasi pastatų gedimų, atsirandančių nuolatinės integracijos metu, taisymui. Jis nuolat stebi tūkstančius įsakymų, nukreiptų į „GitHub“ kodo prieglobos platformą, ir analizuoja jų atitinkamas versijas. Kiekvieną minutę jis pradeda naujus bandymus taisyti klaidas prieš žmogaus kūrėją. Jis skirtas važiuoti kuo greičiau, nes dalyvauja varžybose: jei „Repairnator“ randa pleistrą prieš žmogaus kūrėją, jis konkuruoja su žmonėmis.

Dabar pateiksime apžvalgą, kaip veikia „Repairnator“ robotas.

Pagrindinis „Repairnator“ įnašas yra nuolatinė integracija, kurią inicijuoja kūrėjų prisiimti įsipareigojimai (viršutinė paveikslo dalis, a ir b), paremti „GitHub“ projektais (a). „Repairnator“ išėjimai yra dvejopi: (1) jis automatiškai sukuria pataisas nesėkmingų statinių taisymui (g), jei tokių yra; (2) kaupia vertingus duomenis būsimiems programos taisymo tyrimams (h) ir (k). Nuolat „Repairnator“ stebi visą nenutrūkstamą „GitHub“ projektų veiklą ©. CI kaupimas pateikiamas kaip įvestis į trijų pakopų dujotiekį: (1) pirmasis etapas renka ir analizuoja CI sukūrimo žurnalus (e); (2) antruoju etapu siekiama vietoje atkurti konstravimo gedimus, kurie nutiko CI (f); (3) trečiajame etape vykdomi įvairių programų taisymo prototipai, gauti iš naujausių akademinių tyrimų. Radęs pataisą, „Repairnator“ projekto narys greitai patikrina sveiko nuovokumo principą, kad nešvaistytų brangaus laiko atvirojo kodo kūrėjams. (i) Jei ji nustato, kad pataisa nėra išsigimusi, ji tada siūlo ją pradiniams projekto kūrėjams kaip „GitHub“ (j) užklausą. Tada kūrėjai seka įprastą kodų peržiūros procesą ir sujungia.

Remontas turi veikti tam tikroje programinės įrangos ekosistemoje. Atsižvelgiant į mūsų patirtį su „Java“ ankstesniuose mokslinių tyrimų projektuose, „Repairnator“ prototipų diegimas sutelktas į programinės įrangos, parašytos „Java“ programavimo kalba, sukurtos naudojant „Maven“ įrankių grandinę, taisymą atviro kodo projektuose, esančiuose „GitHub“, naudojantiems „Travis CI“ nuolatinės integracijos platformą. .

Ekspedicijos pasiekimai

Nuo 2017 m. Sausio mėn. „Repairnator“ dirba trimis skirtingais etapais. Per vieną mėnesį, 2017 m. Sausio mėn., Mes atlikome bandomąjį eksperimentą su pradine prototipo versija. Nuo 2017 m. Vasario 1 d. Iki 2017 m. Gruodžio 31 d. Mes vadovavome „Repairnator“ su fiksuotu 14 188 projektų sąrašu, vadiname jį „1 ekspedicija“. Nuo 2018 m. Sausio 1 d. Iki 2018 m. Birželio 30 d. „Repairnator“ stebėjo „Travis CI“ kūrimo srautą realiuoju laiku, mes jį vadiname „2 ekspedicija“.

Pagrindinis bandomojo eksperimento tikslas buvo patvirtinti mūsų projektą ir pradinį įgyvendinimą. Mes nustatėme, kad mūsų prototipas gali atlikti maždaug 30 taisymo bandymų per dieną, atsižvelgiant į mūsų skaičiavimo išteklius. Dar svarbiau, kad šis bandomasis eksperimentas patvirtino mūsų pagrindines technologines prielaidas: nemaža dalis populiarių atvirojo kodo projektų naudoja „Travis“, o dauguma jų naudoja „Maven“ kaip pastato technologiją. Tai reiškė, kad turėsime nemažą galimybę pasiekti tikslą sintetinti žmonėms konkurencingą pleistrą tame kontekste.

1-osios ekspedicijos metu, kurios rezultatai išsamiai aprašyti [7], „Repairnator“ išanalizavo 11 523 pastatytus bandymo gedimus. 355 iš jų (30,82%) „Repairnator“ sugebėjo vietoje atkurti bandymo nesėkmę. Iš 3551 bandymų taisyti „Repairnator“ rado 15 pataisų, kurios galėjo padėti CI sukurti. Tačiau mūsų pataisų analizė atskleidė, kad nė vienas iš tų pataisų nebuvo konkurencingas žmonėms, nes jie atsirado per vėlai („Repairnator“ pagamino pataisą paskui žmogaus kūrėją) arba buvo žemos kokybės (jie sukūrė sėkmę atsitiktinai).

2-oji ekspedicija yra sėkminga. Tai parodė, kad programų taisymo technologija peržengė žmonių konkurencingumo ribas. „Repairnator“ pagamino 5 pleistrus, kurie atitinka aukščiau apibrėžtus žmogaus konkurencingumo kriterijus: 1) pleistrai buvo pagaminti anksčiau nei žmonės, 2) žmogaus kūrėjas priėmė pleistrus kaip pagrįstą indėlį, o pleistrai buvo sujungti į pagrindinę kodų bazę.

Žmonių konkurencinis indėlis į „Github“, robotų „Repairnator“ susisteminti ir žmogaus kūrėjo priimti pleistrai:

  • 2018 m. Sausio 12 d., Aaime / geowebcache / pull / 1, „Ačiū už pleistrą!“
  • 2018 m. Kovo 23 d., „Parkito“ / BasicDataCodeU […] / pull / 3 „sujungtas įsipareigojimas 140a3e3 į„ parkito “: kurkite“
  • 2018 m. Balandžio 5 d., Dkarv / jdcallgraph / pull / 2 „Ačiū!“
  • 2018 m. Gegužės 3 d., Eclipse / ditto / pull / 151 „Šaunu, ačiū, kad einate užtemimo procesą ir pataisėte“.
  • 2018 m. Birželio 25 d., Donnelldebnam / „CodeU“ […] / pull / 151 „Ačiū !!“

Pirmasis mūsų programos taisymo paketo sujungtas pataisas žmonių kūrėjas priėmė 2018 m. Sausio 12 d. Štai ši istorija: 2018 m. Sausio 12 d. 12:28 val., Projekto aaime / geowebcache11 metu buvo pradėtas kurti 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Sudaryti nepavyko po 2 minučių vykdymo, nes du bandymo atvejai buvo klaidingi. Po keturiasdešimties minučių, 2018 m. Sausio 12 d., 13:08, „Repairnator“ nustatė, kad atliekant įprastą stebėseną įvyko triktis, ir pradėjo vykdyti turimas programos taisymo sistemas, sukonfigūruotas „Repairnator“. Po dešimties minučių, 1:18, jis rado pleistrą.

2018 m. Sausio 12 d. 13:35 val. „Repairnator“ komandos narys paėmė „Repairnator“ sukurtą pleistrą ir patvirtino atitinkamo „pull-request“ atidarymą „GitHub“. 2018 m. Sausio 12 d., 14:10 val., Kūrėjas priėmė pleistrą ir sujungė jį su komentaru: „Keista, maniau, kad jau ištaisiau tai ... galbūt padariau kitoje vietoje. Ačiū už pleistrą! “. Tai buvo pirmasis „Repairnator“ pagamintas pleistras, priimtas kaip tinkamas žmogaus kūrėjo įnašas, galutinai sujungtas su kodų baze. Kitaip tariant, „Repairnator“ pirmą kartą buvo konkurencinga žmonėms.

Po dar 6 mėnesių eksploatavimo „Repairnator“ turėjo 5 pataisas, kurias sujungė žmonių kūrėjai ir kurios išvardytos aukščiau.

Apskritai „Repairnator“ projektas įvykdė savo misiją. Tai parodė, kad programos taisymas gali būti laikomas konkurencingu žmonėms: „Repairnator“ rado pleistrų 1) prieš žmones, 2) kuriuos patys žmonės laikė geros kokybės.

Ateitis

Projektas „Repairnator“ ne tik parodė, kad programos taisymas yra konkurencingas, bet ir pateikė daug informacijos apie klaidas ir nuolatinę integraciją bei apie dabartinius programos taisymo tyrimų trūkumus, pateiktus [7].

Paimkime visų pirma vieną intelektinės nuosavybės klausimą. 2018 m. Gegužės 3 d. „Repairnator“ pagamino gerą „GitHub“ projekto užtemimo / pakeitimo pataisą. Netrukus pasiūlęs pataisą, vienas iš kūrėjų paklausė: „Mes galime priimti tik atsisiuntimo užklausas, kurias pateikia vartotojai, pasirašę„ Eclipse “fondo bendradarbių licencijos sutartį“. Buvome suglumę, nes robotas negali fiziškai ar morališkai pasirašyti licencinės sutarties ir tikriausiai neturi teisės to pasirašyti. Kam priklauso intelektinė nuosavybė ir atsakomybė už roboto indėlį: roboto operatorius, roboto įgyvendintojas ar taisymo algoritmo kūrėjas? Tai yra vienas iš įdomių klausimų, kuriuos atskleidė „Repairnator“ projektas.

Mes tikime, kad „Repairnator“ iš anksto numato tam tikrą programinės įrangos kūrimo ateitį, kai robotai ir žmonės sklandžiai bendradarbiaus ir netgi bendradarbiaus kurdami programinės įrangos artefaktus.

Norite prisijungti prie „Repairnator“ bendruomenės? Norėdami gauti reguliarias naujienas apie „Repairnator“, rašykite el. Paštu adresu repairnator.subscribe@4open.science!

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

Žiniasklaidoje:

  • Paslaptingas Luco Esape'o, klaidų taisytojo, ekstraordinato gyvenimas. Jo didžioji paslaptis? Jis nėra žmogus (Thomas Claburn, „The Register“)

Nuorodos

  • [1] J. R. Koza (2010) Žmonių konkurencingumo rezultatai, sukurti genetinio programavimo būdu. Genetinis programavimas ir tobulinamos mašinos 11 (3–4), p. 251–284. Cituoja:.
  • [2] C. Lebeuf, M. D. Storey ir A. Zagalsky (2018) Programinės įrangos robotai. IEEE programinė įranga 35, 18–23 p. Cituoja: Automatinis taisymas ir nuolatinė integracija.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan ir M. Monperrus (2016) „Java“ tikrų klaidų automatinis taisymas: didelio masto eksperimentas su defektų4j duomenų rinkiniu. Empirinė programinės įrangos inžinerija, 1–29 p. Cituoja: Žmonių konkurencingumas,.
  • [4] M. Monperrus (2017) Automatinis programinės įrangos taisymas: bibliografija. ACM kompiuterinės apklausos. Cituoja: automatinis taisymas ir nuolatinė integracija,.
  • [5] A. Murgia, D. Janssens, S. Demeyer ir B. Vasilescu (2016) Tarp mašinų: žmogaus ir roboto sąveika socialinėse q ir svetainėse. 2016 m. CHI konferencijos „Išplėstinės santraukos apie žmogiškuosius veiksnius kompiuterinėse sistemose“ pranešimuose, p. 1272–1279. Cituoja: Žmogaus konkurencingumas.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues ir Y. Brun (2015) Ar vaistas yra blogesnis nei liga? perteklinis remontas atliekant automatinį programų remontą. 2015 m. 10-ojo jungtinio susitikimo dėl programinės įrangos inžinerijos pagrindų, 532–543 psl. Išorinės nuorodos: Cituojamas dokumentas: Žmogaus konkurencingumas.
  • [7] S. Urli, Z. Yu, L. Seinturier ir M. Monperrus (2018) Kaip sukurti programos taisymo botą? „Repairnator“ projekto įžvalgos. ICSE 2018–40-ojoje tarptautinėje programinės įrangos inžinerijos konferencijoje „Stebėkite programinės įrangos inžineriją praktikoje“, Išorinės nuorodos: Nuorodą cituoja: „Expedition Achievements“, „The Future“.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta ir S. Panichella (2017) Pasakojimas apie CI pastatų gedimus: atviro kodo ir finansinės organizacijos perspektyva. Tarptautinėje programinės įrangos priežiūros ir evoliucijos konferencijoje, cituoja: automatinis taisymas ir nuolatinė integracija.