Patch-uri uman-competitive în repararea automată a programului cu Repairnator

Repairnator este un bot. Monitorizează constant erorile de software descoperite în timpul integrării continue a software-ului open-source și încearcă să le remedieze automat. Dacă reușește să sintetizeze un patch valid, Repairnator propune corecția dezvoltatorilor umani, deghizați sub o identitate umană falsă. Până în prezent, Repairnator a reușit să producă 5 patch-uri care au fost acceptate de dezvoltatorii umani și fuzionate permanent în baza de cod. Aceasta reprezintă un punct de reper pentru competitivitatea umană în cercetarea ingineriei software privind repararea automată a programelor. În acest post, spunem povestea acestei cercetări efectuate la KTH Royal Institute of Technology, Inria, Universitatea din Lille și Universitatea Valenciennes.

Cercetarea de reparații a programului urmărește ideea că algoritmii pot înlocui oamenii pentru a remedia erorile de software [4]. O remediere a erorilor este un patch care introduce, șterge sau modifică codul sursă. De exemplu, în următorul patch, dezvoltatorul a modificat starea instrucțiunii if:

- dacă (x <10)
+ dacă (x <= 10)
foo ();

Un bot de reparare a programului este un agent artificial care încearcă să sintetizeze patch-urile de cod sursă. Analizează bug-urile și produce patch-uri, în același mod ca dezvoltatorii umani implicați în activități de întreținere software. Această idee a unui bot de reparare a programului este perturbatoare, deoarece astăzi oamenii sunt responsabili de remedierea erorilor. Cu alte cuvinte, vorbim despre un bot menit să înlocuiască (parțial) dezvoltatorii umani pentru sarcini obositoare.

Atunci când un bot încearcă să realizeze o sarcină de obicei făcută de oameni, este cunoscut ca o sarcină competitivă a omului [1]. Evaluările empirice ale cercetării privind reparațiile programelor [3] arată că sistemele actuale de reparare a programelor sunt capabile să sintetizeze patch-uri pentru bug-urile reale din programele reale. Cu toate acestea, toate acele patch-uri au fost sintetizate pentru bug-urile anterioare, pentru bug-urile care au fost rezolvate de dezvoltatorii umani în trecut, de obicei cu ani în urmă. Deși acest lucru indică fezabilitatea tehnică a reparației programului, acest lucru nu demonstrează că repararea programului este competitivă pentru om.

Om-competitivitate

Pentru a demonstra că repararea programului este competitivă pentru om, un bot de reparare a programului trebuie să găsească un plasture de înaltă calitate înainte ca un om să facă acest lucru. În acest context, un plasture poate fi considerat a fi competitiv pentru om dacă satisface cele două condiții de actualitate și calitate. Punctualitatea se referă la faptul că sistemul trebuie să găsească un plasture înainte de dezvoltatorul uman. Cu alte cuvinte, sistemul prototip trebuie să producă patch-uri în ordinea mărimii de minute, nu a zilei. De asemenea, corecția generată de bot trebuie să fie suficient de corectă, de calitate similară - corectă și lizibilă - în comparație cu un plasture scris de un om. Rețineți că există corecții care arată corecte din punctul de vedere al botului, dar care sunt incorecte (aceasta este cunoscută sub denumirea de corecții din literatura de specialitate [6, 3]). Aceste patch-uri nu sunt, probabil, competitive pentru oameni, deoarece oamenii nu le-ar accepta niciodată în baza lor de cod.

În consecință, pentru ca un plasture să fie competitiv pentru om 1) botul trebuie să sintetizeze patch-ul mai repede decât dezvoltatorul uman 2) patch-ul trebuie să fie considerat suficient de bine de dezvoltatorul uman și să fie contopit definitiv în baza codului.

Există încă un aspect de luat în considerare. S-a demonstrat că inginerii umani nu acceptă contribuții din partea roboților la fel de ușor ca contribuțiile altor oameni, chiar dacă sunt strict identici [5]. Motivul este că oamenii tind să aibă prejudecăți a priori față de mașini și sunt mai toleranți la erori dacă contribuția provine de la un coleg uman. În contextul reparației programului, acest lucru înseamnă că dezvoltatorii pot pune bara mai ridicată asupra calității patch-ului, dacă știu că patch-ul provine de la un bot. Acest lucru ar împiedica căutarea noastră pentru o dovadă a competitivității umane în contextul reparației programului.

Pentru a depăși această problemă, am decis la începutul proiectului că toate patch-urile Repairnator vor fi propuse sub o identitate umană falsă. Am creat un utilizator GitHub, numit Luc Esape, care este prezentat ca inginer software în laboratorul nostru de cercetare. Luc are o imagine de profil și arată ca un dezvoltator junior, dornic să aducă contribuții open-source pe GitHub. Acum imaginați-l pe Repairnator, deghizat în ideea că Luc Esape a propus un patch: dezvoltatorul care îl analizează crede că ea revizuiește o contribuție umană. Acest camuflaj este necesar pentru a testa ipoteza noastră științifică a competitivității umane. Acum, din motive de etică, identitatea reală a lui Luc a fost dezvăluită la fiecare dintre cererile sale de tragere.

Reparație automată și integrare continuă

Integrarea continuă, de asemenea CI, este ideea că un server compilează codul și rulează toate testele pentru fiecare angajare făcută în sistemul de control al versiunii unui proiect software (de exemplu, Git). În limbajul CI, există o acumulare pentru fiecare angajament. O compilare conține informații despre instantaneul codului sursă utilizat (de exemplu, o referință la un Git angajat), rezultatul compilării și executării testelor (de exemplu, eșec sau succes) și un jurnal de urmărire a execuției. Se spune că o construcție nu reușește dacă eșuarea compilării sau eșuează cel puțin un caz de test. S-a arătat că aproximativ unul din 4 compilări nu reușește și că cea mai comună cauză a eșecului de construire este o eroare de testare [8].

Ideea cheie a Repairnator este de a genera automat patch-uri care reparează eșecurile de construire, apoi de a le arăta dezvoltatorilor umani, pentru a vedea în final dacă acei dezvoltatori umani le-ar accepta ca contribuții valide la baza de cod. Dacă se întâmplă acest lucru, aceasta ar fi o dovadă a competitivității umane în repararea programului.

Această configurare - repararea automată a eșecurilor de construire care se întâmplă în integrare continuă - este deosebit de adecvată și în timp util din următoarele motive. În primul rând, eșecurile de construire satisfac declarația principală a problemei de reparare a programului bazat pe test-suite [4], unde bug-urile sunt specificate ca cazuri de testare defecte, iar acele cazuri de testare defecte sunt utilizate pentru a conduce sinteza automată a unui patch [4]. În al doilea rând, permite compararea robotilor și a oamenilor în mod corect: atunci când este descoperit un test eșuant pe serverul de integrare continuă, dezvoltatorul uman și bot-ul sunt informați despre acesta, în același timp. Această notificare de eșec test este punctul de plecare al competiției umane vs. bot.

Concentrația lui Repairnator pe eșecurile de construire este unică, dar se potrivește imaginii mari a robotelor inteligente pentru software [2]. De exemplu, Facebook are un instrument numit SapFix care repară erorile găsite cu testarea automată. De asemenea, înrudite, atacatorii și apărătorii botului DARPA Cyber ​​Grand Challenge încearcă să fie competitivi între oameni în ceea ce privește experții în securitate.

Reparator într-un Nutshell

În 2017-2018, am conceput, implementat și operat Repairnator, un bot pentru repararea automată a programelor. Repairnator este specializat în repararea defecțiunilor de construire care se întâmplă în timpul integrării continue. Monitorizează constant mii de angajamente care sunt împinse către platforma de găzduire a codului GitHub și analizează componentele corespunzătoare ale acestora. În fiecare minut, lansează noi încercări de reparații pentru a remedia erorile înaintea dezvoltatorului uman. Este proiectat să meargă cât mai repede, deoarece participă la o cursă: dacă Repairnator găsește un plasture înainte de dezvoltatorul uman, este competitiv pentru oameni.

Să oferim acum o imagine de ansamblu asupra funcționării bot-ului Repairnator.

Introducerea principală a Repairnator este constituirea continuă a integrării, declanșată de angajamentele realizate de dezvoltatori (partea superioară a figurii, (a) și (b)) pe baza proiectelor GitHub (a). Produsele Repairnator sunt de două ori: (1) produce automat patch-uri pentru repararea construcțiilor defecte (g), dacă există; (2) colectează date valoroase pentru cercetările viitoare privind reparațiile programelor (h) și (k). Permanenț, Repairnator monitorizează toată activitatea continuă din proiectele GitHub ©. Construcțiile CI sunt date ca o intrare pentru o conductă în trei etape: (1) o primă etapă colectează și analizează jurnalele de construire CI (e); (2) oa doua etapă vizează reproducerea locală a eșecurilor de construire care s-au întâmplat pe CI (f); (3) oa treia etapă derulează prototipuri diferite de reparare a programelor care provin din ultimele cercetări academice. Când este găsit un plasture, un membru al proiectului Repairnator efectuează o verificare rapidă a sanității, pentru a evita pierderea timpului prețios al dezvoltatorilor open-source. (i) Dacă consideră că plastureul nu a fost degenerat, atunci îl propune dezvoltatorilor originali ai proiectului ca o solicitare de tragere pe GitHub (j). Dezvoltatorii urmează apoi procesul lor obișnuit de revizuire a codului și îmbinare.

Repairnator trebuie să funcționeze într-un ecosistem software dat. Datorită expertizei noastre cu Java în proiectele de cercetare anterioare, implementarea prototipului Repairnator se concentrează pe repararea software-ului scris în limbajul de programare Java, construit cu cablul de instrumente Maven, în proiecte open-source găzduite pe GitHub, care folosesc platforma de integrare continuă Travis CI .

Realizări de expediție

Funcționăm Repairnator din ianuarie 2017, în trei etape diferite. Pe parcursul unei luni, în ianuarie 2017, am efectuat un experiment pilot cu o versiune inițială a prototipului. În perioada 1 februarie 2017 - 31 decembrie 2017, am derulat Repairnator cu o listă fixă ​​de 14.188 de proiecte, numindu-l „Expediția # 1”. În perioada 1 ianuarie 2018 - 30 iunie 2018, Repairnator a monitorizat fluxul de construire Travis CI în timp real, îl numim „Expediția # 2”

Scopul principal al experimentului pilot a fost validarea proiectării și implementării noastre inițiale. Am descoperit că prototipul nostru este capabil să efectueze aproximativ 30 de încercări de reparație pe zi, având în vedere resursele noastre de calcul. Mai important, acest experiment pilot a validat ipotezele noastre tehnologice de bază: o proporție semnificativă din proiectele populare open-source îl folosesc pe Travis, iar majoritatea utilizează Maven ca tehnologie de construire. Aceasta a însemnat că vom avea șanse corecte de a atinge obiectivul nostru de a sintetiza o corecție umană competitivă în acel context.

În timpul Expediției nr. 1, ale cărei rezultate sunt prezentate în detalii în [7], Repairnator a analizat 11.523 de versiuni cu eșecuri de testare. Pentru 3.551 dintre ei (30,82%), Repairnator a fost capabil să reproducă local defectarea testului. Din 3.551 de încercări de reparații, Repairnator a găsit 15 patch-uri care ar putea face CI-ul să treacă. Cu toate acestea, analiza noastră de patch-uri a arătat că niciunul dintre aceste patch-uri nu a fost competitiv pentru oameni, deoarece au venit prea târziu (Repairnator a produs un plasture după dezvoltatorul uman) sau au fost de calitate scăzută (au făcut ca construcția să aibă succes coincident).

Expediția nr. 2 este cea de succes. A arătat că tehnologia de reparare a programelor a trecut granița competitivității umane. Repairnator a produs 5 patch-uri care îndeplinesc criteriile de competitivitate umană definite mai sus: 1) patch-urile au fost produse înainte de cele umane, 2) un dezvoltator uman a acceptat patch-urile ca contribuții valide, iar patch-urile au fost contopite în baza codului principal.

Contribuții umane competitive pe Github, patch-uri sintetizate de robotul Repairnator și acceptate de dezvoltatorul uman:

  • 12 ianuarie 2018, aaime / geowebcache / pull / 1, „Mulțumesc pentru plasture!”
  • 23 martie 2018, parkito / BasicDataCodeU [...] / pull / 3 „comisie comisă 140a3e3 în parkito: dezvoltați”
  • 5 aprilie 2018, dkarv / jdcallgraph / pull / 2 „Mulțumesc!”
  • 3 mai 2018, eclipse / ditto / pull / 151 „Bine, mulțumesc că ai trecut prin procesul Eclipse și pentru remediere.”
  • 25 iunie 2018, donnelldebnam / CodeU […] / pull / 151 „Mulțumesc !!”

Primul plasture comasat de botul nostru de reparații al programului a fost acceptat de un dezvoltator uman pe 12 ianuarie 2018. Iată povestea: pe 12 ianuarie 2018 la 12:28 pm, a fost declanșată o construcție pe proiectul aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Construcția a eșuat după 2 minute de execuție, deoarece două cazuri de test au fost în eroare. Patru minute mai târziu, pe 12 ianuarie 2018 la 13:08, Repairnator a detectat construirea eșuată în timpul monitorizării sale regulate și a început să ruleze sistemele de reparații disponibile ale programului configurate în Repairnator. Zece minute mai târziu, la 1:18 pm, a găsit un plasture.

În 12 ianuarie 2018, la 13:35, un membru al echipei Repairnator a luat patch-ul generat de Repairnator și a validat deschiderea cererii de tragere corespunzătoare pe GitHub. Pe 12 ianuarie 2018, la 14:10, dezvoltatorul a acceptat plasturele și l-a contopit cu un comentariu: „Ciudat, am crezut că am rezolvat deja acest lucru ... poate am făcut-o în alt loc. Mulțumesc pentru plasture! ”. Acesta a fost primul plasture produs de Repairnator și acceptat ca o contribuție valabilă de către un dezvoltator uman, contopit definitiv în baza codului. Cu alte cuvinte, Repairnator a fost competitiv pentru oameni pentru prima dată.

După încă 6 luni de funcționare, Repairnator a avut 5 pete îmbinate de dezvoltatorii umani, care sunt enumerate mai sus.

În general, proiectul Repairnator și-a îndeplinit misiunea. A arătat că repararea programului poate fi considerată ca fiind competitivă pentru oameni: Repairnator a găsit patch-uri 1) înaintea oamenilor, 2) care au fost considerate de bună calitate chiar de către oameni.

Viitorul

Pe lângă faptul că arată faptul că reparația programului este competitivă pentru oameni, proiectul Repairnator a oferit o mulțime de informații despre bug-uri și integrare continuă și despre deficiențele actuale ale cercetării în domeniul reparațiilor programelor, prezentate în [7].

Să ne bazăm pe un punct în special, problema proprietății intelectuale. Pe 3 mai 2018, Repairnator a produs un plasture bun pentru eclipsa / ditto de proiect GitHub. La scurt timp după ce a propus corecția, unul dintre dezvoltatori a solicitat „Putem accepta doar solicitări de tragere care provin de la utilizatorii care au semnat Acordul de licență pentru contribuția Eclipse Foundation”. Am fost încurcați, deoarece un bot nu poate semna fizic sau moral un acord de licență și, probabil, nu are dreptul să facă acest lucru. Cine deține proprietatea intelectuală și responsabilitatea unei contribuții bot: operatorul robotului, implementatorul de bot sau proiectantul algoritmului de reparații? Aceasta este una dintre întrebările interesante descoperite de proiectul Repairnator.

Credem că Repairnator prefigurează un anumit viitor al dezvoltării de software, în care roboții și oamenii vor colabora fără probleme și chiar vor coopera cu artefacte software.

Doriți să vă alăturați comunității Repairnator? Pentru a primi periodic știri despre Repairnator, trageți un e-mail la reparația.subscribe@4open.science!

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

În media:

  • Viața misterioasă a lui Luc Esape, remediere de erori extraordinaire. Marele lui secret? El nu este om (Thomas Claburn, Registrul)

Referințe

  • [1] J. R. Koza (2010) Rezultate competitive umane produse de programarea genetică. Programare genetică și mașini evolutive 11 (3–4), pp. 251–284. Citat de: .
  • [2] C. Lebeuf, M. D. Storey și A. Zagalsky (2018) Software bots. Software IEEE 35, p. 18–23. Citat de: Reparație automată și integrare continuă.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan și M. Monperrus (2016) Reparația automată a erorilor reale în Java: un experiment pe scară largă pe baza de date Defects4j. Empirical Software Engineering, pp. 1–29. Citat de: Competitivitatea umană ,.
  • [4] M. Monperrus (2017) Repararea automată a software-ului: o bibliografie. Sondaje de calcul ACM. Citat de: Reparație automată și integrare continuă ,.
  • [5] A. Murgia, D. Janssens, S. Demeyer și B. Vasilescu (2016) Printre mașini: Interacțiunea om-bot pe site-urile sociale q și un site web. În lucrările Conferinței CHI din 2016 Rezumate extinse asupra factorilor umani în sistemele de calcul, pp. 1272–1279. Citat de: Competitivitatea umană.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues și Y. Brun (2015) Este vindecarea mai rea decât boala? montarea în reparații automate a programelor. În Proceedings of the 10th Meeting 2015 on Foundations of Software Engineering, pp. 532–543. Linkuri externe: Document citat de: Competitivitatea umană.
  • [7] S. Urli, Z. Yu, L. Seinturier și M. Monperrus (2018) Cum să proiectăm un bot pentru repararea programului? Informații din proiectul Repairnator. În ICSE 2018–40th Conference International on Engineering Software, Track Software Engineering in Practica, Link-uri externe: Link Citat de: Realizări de expediție, Viitorul.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta și S. Panichella (2017) A Tale of CI Build Failures: an Open-source and o perspectivă a organizației financiare. În cadrul Conferinței internaționale privind întreținerea și evoluția software, citat de: Reparație automată și integrare continuă.