Cilvēkiem konkurētspējīgi ielāpi automātiskā programmu labošanā ar Repairnator palīdzību

Remontators ir robotprogrammatūra. Tas pastāvīgi uzrauga programmatūras kļūdas, kas atklātas nepārtrauktas atvērtā pirmkoda programmatūras integrācijas laikā, un mēģina tās automātiski novērst. Ja izdodas sintezēt derīgu plāksteri, Repairnator ierosina plāksteri izstrādātājiem, slēpjot viltotu cilvēka identitāti. Līdz šim Repairnator ir spējis izgatavot 5 ielāpus, kurus ir pieņēmuši cilvēku izstrādātāji un kas ir neatgriezeniski apvienoti kodu bāzē. Tas ir pagrieziena punkts cilvēku konkurētspējai programmatūras inženierijas pētījumos par automātisku programmu remontu. Šajā amatā mēs pastāstīsim stāstu par šo pētījumu, kas veikts KTH Karaliskajā tehnoloģiju institūtā, Inrijā, Lilles universitātē un Valensijas Universitātē.

Programmu labošanas pētījumos tiek īstenota ideja, ka algoritmi var aizstāt cilvēkus, lai labotu programmatūras kļūdas [4]. Kļūdu labojums ir plāksteris, kas ievieto, dzēš vai modificē avota kodu. Piemēram, šajā ielāpā izstrādātājs ir mainījis if paziņojuma nosacījumu:

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

Programmas labošanas robotprogrammatūra ir mākslīgs līdzeklis, kas mēģina sintezēt avota koda ielāpus. Tas analizē kļūdas un rada ielāpus tāpat kā cilvēku izstrādātāji, kas iesaistīti programmatūras uzturēšanas darbībās. Šī ideja par programmas labošanas robotprogrammatūru ir graujoša, jo mūsdienās cilvēki ir atbildīgi par kļūdu novēršanu. Citiem vārdiem sakot, mēs runājam par robotu, kas paredzēts (daļēji) cilvēku izstrādātāju aizvietošanai garlaicīgu uzdevumu veikšanai.

Kad robots mēģina sasniegt uzdevumu, ko parasti veic cilvēki, to sauc par cilvēku konkurences uzdevumu [1]. Programmu labošanas pētījumu empīriskie novērtējumi [3] liecina, ka pašreizējās programmu labošanas sistēmas spēj sintezēt reālu programmu labojumus patiesām kļūdām. Tomēr visi šie ielāpi tika sintezēti pagātnes kļūdām un kļūdām, kuras cilvēku izstrādātāji bija labojuši pagātnē, parasti pirms gadiem. Lai gan tas norāda uz programmas labošanas tehnisko iespējamību, tas tomēr neliecina, ka programmas labošana ir konkurētspējīga cilvēkiem.

Cilvēku konkurētspēja

Lai pierādītu, ka programmas labošana ir konkurētspējīga cilvēkiem, programmas labošanas robotam ir jāatrod augstas kvalitātes ielāps, pirms cilvēks to dara. Šajā kontekstā plāksteri var uzskatīt par konkurenci cilvēkiem, ja tas atbilst diviem savlaicīguma un kvalitātes nosacījumiem. Savlaicīgums attiecas uz faktu, ka sistēmai jāatrod labojums pirms cilvēka izstrādātāja. Citiem vārdiem sakot, prototipa sistēmai ir jāražo plāksteri minūšu, nevis dienu, secībā. Arī robotprogrammatūras ģenerētajam plāksterim jābūt pietiekami pareizam, līdzīgas kvalitātes - pareizam un salasāmam - salīdzinājumā ar plāksteri, kuru uzrakstījis cilvēks. Ņemiet vērā, ka ir plāksteri, kas no robota viedokļa izskatās pareizi, bet tomēr nav pareizi (literatūrā tos sauc par pārāk piemērotiem plāksteriem [6, 3]). Šie plāksteri, domājams, nespēj konkurēt ar cilvēkiem, jo ​​cilvēki tos nekad nepieņems savā kodu bāzē.

Līdz ar to, lai plāksteris varētu konkurēt ar cilvēkiem 1) robotprogrammatūrai ir jāsintezē plāksteris ātrāk nekā cilvēka izstrādātājam 2) cilvēkam izstrādātājs ir jānovērtē plāksteris pietiekami labi un pastāvīgi jāapvieno kodu kodā.

Ir jāņem vērā vēl viens aspekts. Ir pierādīts, ka cilvēku inženieri nepieņem robotu ieguldījumu tikpat viegli kā citu cilvēku ieguldījumus, pat ja tie ir stingri identiski [5]. Iemesls ir tāds, ka cilvēkiem parasti ir a priori aizspriedumi pret mašīnām, un viņi ir tolerantāki pret kļūdām, ja ieguldījums nāk no vienaudžiem. Programmas labošanas kontekstā tas nozīmē, ka izstrādātāji var paaugstināt plākstera kvalitātes līmeni, ja viņi zina, ka plāksteris nāk no robotprogrammatūras. Tas kavētu mūsu centienus pierādīt cilvēku konkurētspēju programmas labošanas kontekstā.

Lai novērstu šo problēmu, projekta sākumā mēs nolēmām, ka visi Repairnator ielāpi tiks ierosināti ar viltotu cilvēka identitāti. Mēs esam izveidojuši GitHub lietotāju ar nosaukumu Luc Esape, kurš mūsu pētniecības laboratorijā tiek prezentēts kā programmatūras inženieris. Lucam ir profila bilde un viņš izskatās kā jaunākais izstrādātājs, kurš vēlas veikt atvērtā pirmkoda ieguldījumu vietnē GitHub. Tagad iedomājieties Repairnator, nomaskētu kā Lūps Epsē, kurš ierosina plāksteri: izstrādātājs, kurš to pārskata, domā, ka viņa pārskata cilvēka ieguldījumu. Šī maskēšanās ir nepieciešama, lai pārbaudītu mūsu zinātnisko hipotēzi par cilvēku konkurētspēju. Ētikas labad Lū patiesā identitāte ir atklāta katrā viņa atsaukšanas pieprasījumā.

Automātisks remonts un nepārtraukta integrācija

Nepārtraukta integrācija, pazīstama arī kā CI, ir ideja, ka serveris apkopo kodu un veic visus testus katrai saistībai, kas tiek veikta programmatūras projekta versiju vadības sistēmā (piemēram, Git). KI runājot, katra saistība ir pamatota. Apbūve satur informāciju par izmantoto avota koda momentuzņēmumu (piemēram, atsauci uz Git saistību), kompilācijas un testa izpildes rezultātu (piemēram, neveiksme vai panākumi) un izpildes izsekošanas žurnālu. Tiek uzskatīts, ka veidošana neizdodas, ja neizdodas kompilēt vai vismaz viens testa gadījums neizdodas. Ir pierādīts, ka aptuveni viena no četrām būvēm neizdodas, un ka visizplatītākais būves kļūmju cēlonis ir pārbaudes kļūme [8].

Galvenā Repairnator ideja ir automātiski ģenerēt ielāpus, kas labo būvēšanas kļūmes, pēc tam parādīt tos cilvēku izstrādātājiem, lai beidzot redzētu, vai šie cilvēku izstrādātāji tos pieņems kā derīgu ieguldījumu koda bāzē. Ja tas notiks, tas būs pierādījums cilvēku konkurētspējai programmas uzlabošanā.

Šī iestatīšana - automātiska remonta kļūmju rašanās nepārtrauktā integrācijā - ir īpaši piemērota un savlaicīga šādu iemeslu dēļ. Pirmkārt, būvēšanas kļūmes apmierina galveno problēmu paziņojumu par testkomplektu balstītas programmas labošanu [4], kur kļūdas tiek norādītas kā neveiksmīgas pārbaudes lietas un tās, kuras neizdodas, tiek izmantotas, lai virzītu plākstera automatizētu sintēzi [4]. Otrkārt, tas ļauj godīgi salīdzināt robotprogrammatūras un cilvēkus: kad nepārtrauktas integrācijas serverī tiek atklāts neveiksmīgs tests, cilvēka izstrādātājs un robotprogrammatūra tiek informēti par to tieši tajā pašā laikā. Šis pārbaudes neveiksmes paziņojums ir sākumpunkts sacensībai starp cilvēkiem un robotiem.

Remontatora uzmanība koncentrēšanās uz kļūmēm ir unikāla, taču tā iekļaujas lielajā viedo programmatūras botu attēlā [2]. Piemēram, Facebook ir rīks ar nosaukumu SapFix, kas novērš kļūdas, kas atrastas ar automatizētu testēšanu. Saistīti arī ar DARPA Cyber ​​Grand Challenge robotprogrammatūras uzbrucējiem un aizstāvjiem, salīdzinot ar drošības ekspertiem, cenšoties konkurēt ar cilvēkiem.

Remonts īsumā

Laikā no 2017. līdz 2018.gadam mēs esam izstrādājuši, ieviesuši un vadījuši Repairnator - robotprogrammatūru automatizētam programmas remontam. Repairnator ir specializējies celtniecības kļūmju novēršanai, kas notiek nepārtrauktas integrācijas laikā. Tas pastāvīgi uzrauga tūkstošiem apņemšanos nokļūt GitHub koda mitināšanas platformā un analizē to atbilstošās versijas. Katru minūti tā sāk jaunus labošanas mēģinājumus, lai novērstu kļūdas pirms cilvēka izstrādātāja. Tas ir paredzēts, lai dotos pēc iespējas ātrāk, jo tas piedalās sacīkstēs: ja Repairnator atrod plāksteri pirms cilvēka izstrādātāja, tas ir konkurētspējīgs cilvēkiem.

Ļaujiet mums tagad sniegt pārskatu par to, kā darbojas robots Repairnator.

Galvenā Repairnator ieeja ir nepārtraukta integrācija, ko aktivizē izstrādātāju saistības (attēla augšējā daļa, (a) un (b)), pamatojoties uz GitHub projektiem (a). Remontatora izejas ir divējādas: (1) tas automātiski rada ielāpus neveiksmīgu versiju labošanai (g), ja tādi ir; (2) tas vāc vērtīgus datus turpmākiem programmas labošanas pētījumiem (h) un (k). Pastāvīgi Repairnator uzrauga visu nepārtraukto darbību no GitHub projektiem ©. KI veidošana tiek ievadīta kā trīs posmu cauruļvads: (1) pirmais posms apkopo un analizē KI veidošanas žurnālus (e); (2) otrā posma mērķis ir lokāli reproducēt kļūmes, kas notikušas CI (f); (3) trešajā posmā tiek izpildīti dažādi programmu remonta prototipi, kas iegūti no jaunākajiem akadēmiskajiem pētījumiem. Kad tiek atrasts plāksteris, Repairnator projekta dalībnieks veic ātru saprāta pārbaudi, lai nelietderīgi tērētu atvērtā pirmkoda izstrādātāju laiku. (i) Ja viņa uzskata, ka plāksteris nav deģenerēts, viņa pēc tam ierosina to sākotnējiem projekta izstrādātājiem kā pieprasījuma pieprasījumu vietnē GitHub (j). Pēc tam izstrādātāji ievēro parasto koda pārskatīšanas un apvienošanas procesu.

Remontatoram jādarbojas noteiktā programmatūras ekosistēmā. Sakarā ar mūsu kompetenci ar Java iepriekšējos pētniecības projektos, Repairnator prototipa ieviešana ir vērsta uz Java programmēšanas valodā uzrakstītās programmatūras labošanu, kas veidota ar Maven rīku ķēdi, atvērtā pirmkoda projektos, kas izvietoti GitHub un kuri izmanto Travis CI nepārtrauktas integrācijas platformu. .

Ekspedīcijas sasniegumi

Kopš 2017. gada janvāra mēs strādājam Repairnator trīs dažādās fāzēs. Mēneša laikā, 2017. gada janvārī, mēs veica izmēģinājuma eksperimentu ar sākotnējo prototipa versiju. No 2017. gada 1. februāra līdz 2017. gada 31. decembrim mēs vadījām Repairnator ar fiksētu 14 188 projektu sarakstu, mēs to saucam par “Expedition # 1”. No 2018. gada 1. janvāra līdz 2018. gada 30. jūnijam Repairnator ir uzraudzījis Travis CI veidošanas straumi reāllaikā, mēs to saucam par “Expedition # 2”.

Izmēģinājuma eksperimenta galvenais mērķis bija apstiprināt mūsu dizainu un sākotnējo ieviešanu. Mēs noskaidrojām, ka mūsu prototips, ņemot vērā mūsu skaitļošanas resursus, dienā spēj veikt aptuveni 30 remonta mēģinājumus. Vēl svarīgāk ir tas, ka šis eksperimentālais eksperiments apstiprināja mūsu galvenos tehnoloģiskos pieņēmumus: ievērojama daļa populāru atklātā pirmkoda projektu izmanto Travis un vairums no tiem izmanto Maven kā būvēšanas tehnoloģiju. Tas nozīmēja, ka mums būs diezgan lielas iespējas sasniegt savu mērķi sintezēt cilvēku konkurences plāksteri šajā kontekstā.

1. ekspedīcijas laikā, kuras rezultāti ir sīki aprakstīti [7], Repairnator ir analizējis 11 523 būves ar testa kļūmēm. 3551 no tiem (30,82%) Repairnator spēja lokāli reproducēt testa kļūmi. No 3551 labošanas mēģinājumiem Repairnator atrada 15 ielāpus, kas varēja padarīt CI nozīmīgu. Tomēr mūsu plākstera analīze atklāja, ka neviens no šiem plāksteriem nebija konkurētspējīgs cilvēkiem, jo ​​tie nāca par vēlu (Repairnator izgatavoja plāksteri pēc cilvēka izstrādātāja) vai bija zemas kvalitātes (tie izveidoja veiksmīgu sagadīšanos).

Veiksmīga ir 2. ekspedīcija. Tas parādīja, ka programmu labošanas tehnoloģija ir šķērsojusi cilvēku konkurētspējas robežas. Remontators ir izveidojis 5 plāksterus, kas atbilst iepriekš definētajiem cilvēku konkurētspējas kritērijiem: 1) plāksteri tika izgatavoti pirms cilvēkiem paredzētajiem, 2) cilvēka attīstītājs pieņēma plāksterus kā derīgus ieguldījumus, un plāksteri tika apvienoti galvenajā kodu bāzē.

Cilvēku konkurences ieguldījums Github, roboti Repairnator sintezētie un izstrādātāja akceptētie ielāpi:

  • 2018. gada 12. janvārī, aaime / geowebcache / pull / 1, “Paldies par plāksteri!”
  • 2018. gada 23. marts, parkito / BasicDataCodeU […] / pull / 3 “merged 140a3e3 apvienoja parkito: attīstīt”
  • 2018. gada 5. aprīlis, dkarv / jdcallgraph / pull / 2 “Paldies!”
  • 2018. gada 3. maijs, eclipse / ditto / pull / 151 “Forši, paldies, ka apmeklējāt Eclipse procesu un labojāt.”
  • 2018. gada 25. jūnijs, donnelldebnam / CodeU […] / pull / 151 “Paldies !!”

Pirmo plāksteri, ko apvienoja mūsu programmas labošanas robotprogrammatūra, izstrādātājs pieņēma cilvēkam 2018. gada 12. janvārī. Šeit ir stāsts: 2018. gada 12. janvārī plkst. 12:28 projektā aaime / geowebcache11 tika sākta instalēšana. 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Izveidošana neizdevās pēc 2 minūšu izpildes, jo divos testa gadījumos bija kļūda. Četrdesmit minūtes vēlāk, 2018. gada 12. janvārī pulksten 13:08, Repairnator regulārā monitoringa laikā atklāja kļūdainu būvēšanu un sāka darbināt pieejamās programmu labošanas sistēmas, kas konfigurētas Repairnator. Pēc desmit minūtēm pulksten 13:18 tajā tika atrasts plāksteris.

2018. gada 12. janvārī plkst. 13.35 Repairnator komandas loceklis paņēma Repairnator ģenerēto plāksteri un apstiprināja atbilstošā pieprasījuma pieprasījuma atvēršanu vietnē GitHub. 2018. gada 12. janvārī pulksten 14:10 izstrādātājs pieņēma plāksteri un apvienoja to ar komentāru: “Dīvaini, es domāju, ka es jau to laboju… varbūt es to izdarīju kādā citā vietā. Paldies par plāksteri! ”. Tas bija pirmais labojums, kuru izgatavoja Repairnator un kas tika pieņemts kā derīgs cilvēka izstrādātāja ieguldījums un kas galīgi tika apvienots kodu bāzē. Citiem vārdiem sakot, Repairnator pirmo reizi bija konkurētspējīgs cilvēkiem.

Pēc vēl 6 darbības mēnešiem Repairnator ir bijuši 5 ielāpi, kurus apvienojuši izstrādātāji un kuri ir uzskaitīti iepriekš.

Kopumā Repairnator projekts ir piepildījis savu misiju. Tas parādīja, ka programmas labošanu var uzskatīt par konkurenci cilvēkiem: Repairnator ir atradis ielāpus 1) pirms cilvēkiem, 2) kurus paši cilvēki uzskatīja par labas kvalitātes.

Nākotne

Papildus tam, ka tiek parādīts, ka programmu labošana ir konkurētspējīga cilvēkiem, Repairnator projekts ir sniedzis daudz informācijas par kļūdām un nepārtrauktu integrāciju, kā arī par programmas labošanas pētījumu pašreizējiem trūkumiem, kas aprakstīti [7].

Īpaši pakavēsimies pie viena jautājuma - intelektuālā īpašuma jautājuma. 2018. gada 3. maijā Repairnator izgatavoja labu plāksteri GitHub projekta eclipse / ditto. Neilgi pēc tam, kad tika ierosināts plāksteris, viens no izstrādātājiem jautāja: “Mēs varam pieņemt tikai tos pieprasījumus, kas nāk no lietotājiem, kuri ir parakstījuši Eclipse Foundation līdzautoru licences līgumu.” Mēs bijām neizpratnē, jo robots nevar fiziski vai morāli parakstīt licences līgumu, un, iespējams, tam nav tiesību to darīt. Kam pieder robotprogrammatūras intelektuālais īpašums un atbildība: robota operators, robotprogrammatūras ieviesējs vai remonta algoritma izstrādātājs? Šis ir viens no interesantiem jautājumiem, ko atklāja projekts “Repairnator”.

Mēs uzskatām, ka Repairnator nosaka noteiktu programmatūras izstrādes nākotni, kurā roboti un cilvēki vienmērīgi sadarbosies un pat sadarbosies programmatūras artefaktu veidošanā.

Vai vēlaties pievienoties Repairnator kopienai? Lai saņemtu regulāras ziņas par Repairnator, ierakstiet e-pastu uz repairnator.subscribe@4open.science!

- Martins Monperruss, Simons Urli, Tomass Dūrjū, Matiass Martinezs, Benoit Baudry, Lionel Seinturier

Plašsaziņas līdzekļos:

  • Noslēpumainā Luc Esape dzīve, kļūdu labošanas ierīce. Viņa lielais noslēpums? Viņš nav cilvēks (Thomas Claburn, The Register)

Atsauces

  • [1] J. R. Koza (2010) Cilvēku konkurences rezultāti, ko nodrošina ģenētiskā programmēšana. Ģenētiskā programmēšana un mainīgās mašīnas 11 (3–4), 251. – 284. Lpp. Citēts:.
  • [2] C. Lebeuf, M. D. Storey un A. Zagalsky (2018) Programmatūras robotprogrammatūras. IEEE programmatūra 35, 18. – 23. Lpp. Citēja: automātiskais remonts un nepārtraukta integrācija.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan un M. Monperrus (2016) Java reālu kļūdu automātiska labošana: liela mēroga eksperiments ar defektu4j datu kopu. Empīriskā programmatūras inženierija, 1. – 29. Lpp. Citēts: Cilvēku konkurētspēja,.
  • [4] M. Monperrus (2017) Automātiskais programmatūras remonts: bibliogrāfija. ACM skaitļošanas apsekojumi. Citēja: automātiskais remonts un nepārtraukta integrācija,.
  • [5] A. Murgia, D. Janssens, S. Demeyer un B. Vasilescu (2016) Starp mašīnām: Cilvēka un robota mijiedarbība sociālajās q un a vietnēs. CHI 2016. gada konferences Paplašinātie kopsavilkumi par cilvēka faktoriem datorsistēmās 1272–1279. Lpp. Citēts: Cilvēku konkurētspēja.
  • [6] E. K. Smits, E. T. Barrs, C. Le Goues un Y. Bruns (2015) Vai izārstēšana ir sliktāka par slimību? pārmērīga aprīkošana automātiskā programmu remontā. 2015. gada 10. kopīgās sanāksmes par programmatūras izstrādes pamatiem, 532. – 543. Lpp. Ārējās saites: Citēts dokuments: Cilvēku konkurētspēja.
  • [7] S. Urli, Z. Yu, L. Seinturier un M. Monperrus (2018) Kā noformēt programmas remonta botu? Ieskats no Repairnator projekta. ICSE 2018–40. Starptautiskajā konferencē par programmatūras inženieriju, Track Software Engineering in Practice, External Links: Link Citēts: Expedition Achievements, The Future.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta un S. Panichella (2017) CI Build Failures Tale of CI Build Failures: Open Source and finanšu organizācijas perspektīva. Starptautiskajā konferencē par programmatūras uzturēšanu un attīstību, citēja: automātiskais remonts un nepārtraukta integrācija.