Tambal yang berdaya saing manusia dalam Perbaikan Program Otomatis dengan Repairnator

Repairnator adalah bot. Itu terus-menerus memonitor bug perangkat lunak yang ditemukan selama integrasi terus-menerus dari perangkat lunak sumber terbuka dan mencoba memperbaikinya secara otomatis. Jika berhasil mensintesis tambalan yang valid, Repairnator mengusulkan tambalan kepada pengembang manusia, yang disamarkan dengan identitas manusia palsu. Hingga saat ini, Repairnator telah mampu menghasilkan 5 tambalan yang diterima oleh pengembang manusia dan secara permanen digabungkan dalam basis kode. Ini adalah tonggak untuk daya saing manusia dalam penelitian rekayasa perangkat lunak pada perbaikan program otomatis. Dalam posting ini, kami menceritakan tentang penelitian yang dilakukan di KTH Royal Institute of Technology, Inria, University of Lille dan University of Valenciennes.

Penelitian perbaikan program mengejar gagasan bahwa algoritma dapat menggantikan manusia untuk memperbaiki bug perangkat lunak [4]. Perbaikan bug adalah tambalan yang menyisipkan, menghapus, atau memodifikasi kode sumber. Misalnya, dalam tambalan berikut, pengembang telah mengubah kondisi pernyataan if:

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

Bot perbaikan program adalah agen buatan yang mencoba mensintesis patch kode sumber. Ini menganalisis bug dan menghasilkan tambalan, dengan cara yang sama seperti pengembang manusia yang terlibat dalam kegiatan pemeliharaan perangkat lunak. Gagasan bot perbaikan program ini mengganggu, karena saat ini manusia bertanggung jawab untuk memperbaiki bug. Dengan kata lain, kita berbicara tentang bot yang dimaksudkan untuk (sebagian) mengganti pengembang manusia untuk tugas-tugas yang membosankan.

Ketika bot mencoba mencapai tugas yang biasanya dilakukan oleh manusia, ia dikenal sebagai tugas kompetitif manusia [1]. Evaluasi empiris penelitian perbaikan program [3] menunjukkan bahwa sistem perbaikan program saat ini mampu mensintesis patch untuk bug nyata dalam program nyata. Namun, semua tambalan itu disintesis untuk bug masa lalu, untuk bug yang diperbaiki oleh pengembang manusia di masa lalu, biasanya bertahun-tahun yang lalu. Walaupun hal ini menunjukkan kelayakan teknis dari perbaikan program, ini gagal menunjukkan bahwa perbaikan program bersifat kompetitif bagi manusia.

Daya saing manusia

Untuk menunjukkan bahwa perbaikan program bersifat kompetitif-manusia, bot perbaikan program harus menemukan tambalan berkualitas tinggi sebelum manusia melakukannya. Dalam konteks ini, tambalan dapat dianggap sebagai daya saing manusia jika memenuhi dua kondisi ketepatan waktu dan kualitas. Ketepatan waktu mengacu pada fakta bahwa sistem harus menemukan tambalan sebelum pengembang manusia. Dengan kata lain, sistem prototipe harus menghasilkan tambalan dalam urutan besarnya menit, bukan hari. Juga, tambalan yang dihasilkan oleh bot harus benar-benar, dengan kualitas yang sama - benar dan mudah dibaca - dibandingkan dengan tambalan yang ditulis oleh manusia. Perhatikan bahwa ada tambalan yang terlihat benar dari sudut pandang bot, namun itu tidak benar (ini dikenal sebagai tambalan yang sesuai pada literatur [6, 3]). Tambalan itu bisa dibilang tidak kompetitif bagi manusia, karena manusia tidak akan pernah menerimanya dalam basis kode mereka.

Konsekuensinya, agar tambalan menjadi kompetitif bagi manusia 1) bot harus mensintesis tambalan lebih cepat daripada pengembang manusia 2) tambalan harus dinilai cukup baik oleh pengembang manusia dan secara permanen digabungkan dalam basis kode.

Ada satu aspek lagi yang perlu dipertimbangkan. Telah ditunjukkan bahwa insinyur manusia tidak menerima kontribusi dari bot semudah kontribusi dari manusia lain, bahkan jika mereka sangat identik [5]. Alasannya adalah bahwa manusia cenderung memiliki bias apriori terhadap mesin, dan lebih toleran terhadap kesalahan jika kontribusi berasal dari rekan manusia. Dalam konteks perbaikan program, ini berarti bahwa pengembang dapat menempatkan bar lebih tinggi pada kualitas tambalan, jika mereka tahu bahwa tambalan berasal dari bot. Ini akan menghambat pencarian kami untuk bukti daya saing manusia dalam konteks perbaikan program.

Untuk mengatasi masalah ini, kami telah memutuskan di awal proyek bahwa semua patch Repairnator akan diusulkan di bawah identitas manusia palsu. Kami telah menciptakan pengguna GitHub, bernama Luc Esape, yang disajikan sebagai insinyur perangkat lunak di laboratorium penelitian kami. Luc memiliki gambar profil dan terlihat seperti pengembang junior, bersemangat untuk membuat kontribusi open-source di GitHub. Sekarang bayangkan Repairnator, yang menyamar ketika Luc Esape mengusulkan tambalan: pengembang yang meninjau berpikir bahwa dia sedang meninjau kontribusi manusia. Kamuflase ini diperlukan untuk menguji hipotesis ilmiah kami tentang daya saing manusia. Sekarang, demi etika, identitas asli Luc telah diungkapkan pada masing-masing permintaan tariknya.

Perbaikan Otomatis dan Integrasi Berkelanjutan

Integrasi berkelanjutan, alias CI, adalah gagasan bahwa server mengkompilasi kode dan menjalankan semua tes untuk setiap komit yang dibuat dalam sistem kontrol versi proyek perangkat lunak (mis. Git). Dalam bahasa CI, ada build untuk setiap commit. Build berisi informasi tentang snapshot kode sumber yang digunakan (mis. Referensi ke komit Git), hasil kompilasi dan pengujian eksekusi (misal gagal atau sukses), dan log jejak eksekusi. Build dikatakan gagal jika kompilasi gagal atau setidaknya satu test case gagal. Telah ditunjukkan bahwa sekitar satu dari 4 build gagal, dan bahwa penyebab paling umum untuk kegagalan build adalah kegagalan uji [8].

Gagasan kunci dari Repairnator adalah untuk secara otomatis menghasilkan tambalan yang memperbaiki kegagalan pembangunan, kemudian menunjukkannya kepada pengembang manusia, untuk akhirnya melihat apakah pengembang manusia itu akan menerimanya sebagai kontribusi yang valid ke basis kode. Jika ini terjadi, itu akan menjadi bukti daya saing manusia dalam perbaikan program.

Pengaturan ini - secara otomatis memperbaiki kegagalan bangunan yang terjadi dalam integrasi berkelanjutan - sangat sesuai dan tepat waktu karena alasan berikut. Pertama, kegagalan build memenuhi pernyataan masalah inti dari perbaikan program berbasis test-suite [4], di mana bug ditetapkan sebagai kasus uji yang gagal, dan kasus uji yang gagal digunakan untuk menggerakkan sintesis otomatis tambalan [4]. Kedua, memungkinkan membandingkan bot dan manusia secara adil: ketika tes gagal ditemukan pada server integrasi berkelanjutan, pengembang manusia dan bot diinformasikan tentang hal itu, pada saat yang bersamaan. Pemberitahuan kegagalan pengujian ini adalah titik awal kompetisi manusia vs bot.

Fokus Repairnator pada kegagalan pembangunan adalah unik, tetapi cocok dengan gambaran besar bot cerdas untuk perangkat lunak [2]. Misalnya, Facebook memiliki alat bernama SapFix yang memperbaiki bug yang ditemukan dengan pengujian otomatis. Juga terkait, para penyerang dan pembela bot DARPA Cyber ​​Grand Challenge mencoba untuk menjadi manusia yang kompetitif sehubungan dengan para pakar keamanan.

Singkatnya, Repairnator

Pada 2017–2018, kami telah merancang, mengimplementasikan, dan mengoperasikan Repairnator, sebuah bot untuk perbaikan program otomatis. Repairnator adalah khusus untuk memperbaiki kegagalan pembangunan yang terjadi selama integrasi berkelanjutan. Itu terus-menerus memonitor ribuan komit didorong ke platform hosting kode GitHub, dan menganalisis bangunan yang sesuai. Setiap menit, ia meluncurkan upaya perbaikan baru untuk memperbaiki bug sebelum pengembang manusia. Ini dirancang untuk berjalan secepat mungkin karena berpartisipasi dalam perlombaan: jika Repairnator menemukan tambalan di depan pengembang manusia, itu adalah persaingan manusia.

Mari kita sekarang memberikan gambaran tentang bagaimana bot Repairnator bekerja.

Input utama Repairnator adalah pembangunan integrasi berkelanjutan, dipicu oleh komitmen yang dibuat oleh pengembang (bagian atas gambar, (a) dan (b)) berdasarkan proyek GitHub (a). Output dari Repairnator adalah dua kali lipat: (1) secara otomatis menghasilkan tambalan untuk memperbaiki bangunan yang gagal (g), jika ada; (2) mengumpulkan data berharga untuk penelitian perbaikan program di masa depan (h) dan (k). Secara permanen, Repairnator memonitor semua aktivitas berkelanjutan dari proyek GitHub ©. CI build diberikan sebagai input untuk pipa tiga tahap: (1) tahap pertama mengumpulkan dan menganalisis CI build logs (e); (2) tahap kedua bertujuan mereproduksi kegagalan bangun yang terjadi pada CI (f) secara lokal; (3) tahap ketiga menjalankan berbagai prototipe perbaikan program yang berasal dari penelitian akademik terbaru. Ketika tambalan ditemukan, anggota proyek Repairnator melakukan pemeriksaan kewarasan cepat, untuk menghindari pemborosan waktu berharga dari pengembang open-source. (i) Jika ia menemukan tambalan tersebut tidak mengalami degenerasi, ia kemudian mengusulkannya kepada pengembang asli proyek sebagai permintaan tarik pada GitHub (j). Pengembang kemudian mengikuti proses pengkajian dan penggabungan kode seperti biasa.

Repairnator harus beroperasi dalam ekosistem perangkat lunak yang diberikan. Karena keahlian kami dengan Java dalam proyek-proyek penelitian sebelumnya, implementasi prototipe Repairnator berfokus pada perbaikan perangkat lunak yang ditulis dalam bahasa pemrograman Java, dibangun dengan toolaven Maven, dalam proyek-proyek sumber terbuka yang di-host di GitHub, yang menggunakan platform integrasi berkelanjutan Travis CI .

Prestasi Ekspedisi

Kami telah mengoperasikan Repairnator sejak Januari 2017, dalam tiga fase berbeda. Selama satu bulan, pada Januari 2017, kami melakukan percobaan percobaan dengan versi awal prototipe. Dari 1 Februari 2017 hingga 31 Desember 2017, kami menjalankan Repairnator dengan daftar tetap 14.188 proyek, kami menyebutnya "Ekspedisi # 1". Dari 1 Januari 2018 hingga 30 Juni 2018, Repairnator telah memantau aliran pembangunan Travis CI secara real time, kami menyebutnya "Ekspedisi # 2"

Tujuan utama percobaan percobaan adalah untuk memvalidasi desain dan implementasi awal kami. Kami menemukan bahwa prototipe kami mampu melakukan sekitar 30 upaya perbaikan per hari, mengingat sumber daya komputasi kami. Lebih penting lagi, percobaan percontohan ini memvalidasi asumsi teknologi inti kami: sebagian besar proyek open-source populer menggunakan Travis dan sebagian besar menggunakan Maven sebagai teknologi bangun. Ini berarti kami akan memiliki kesempatan yang adil untuk mencapai tujuan kami dalam mensintesis tambalan kompetitif manusia dalam konteks itu.

Selama Ekspedisi # 1, yang hasilnya disajikan secara rinci dalam [7], Repairnator telah menganalisis 11.523 bangunan dengan kegagalan uji. Untuk 3.551 dari mereka (30,82%), Repairnator mampu mereproduksi kegagalan tes secara lokal. Dari 3.551 upaya perbaikan, Repairnator menemukan 15 tambalan yang dapat membuat CI membangun lulus. Namun, analisis patch kami mengungkapkan bahwa tidak ada satu pun dari tambalan itu yang bersaing manusia karena mereka datang terlambat (Repairnator menghasilkan tambalan setelah pengembang manusia) atau berkualitas rendah (mereka membuat bangunan itu berhasil secara kebetulan).

Ekspedisi # 2 adalah yang sukses. Ini telah menunjukkan bahwa teknologi perbaikan program telah melewati batas daya saing manusia. Repairnator telah menghasilkan 5 tambalan yang memenuhi kriteria daya saing manusia yang didefinisikan di atas: 1) tambalan diproduksi sebelum tambalan manusia, 2) pengembang manusia menerima tambalan sebagai kontribusi yang valid, dan tambalan digabung dalam basis kode utama.

Kontribusi kompetitif manusia pada Github, tambalan yang disintesis oleh robot Repairnator dan diterima oleh pengembang manusia:

  • 12 Jan 2018, aaime / geowebcache / pull / 1, "Terima kasih untuk tambalannya!"
  • 23 Mar 2018, parkito / BasicDataCodeU […] / pull / 3 “menggabungkan komit 140a3e3 ke parkito: mengembangkan”
  • 5 April 2018, dkarv / jdcallgraph / pull / 2 "Terima kasih!"
  • 3 Mei 2018, gerhana / ditto / tarik / 151 "Keren, terima kasih telah melalui proses Eclipse dan untuk perbaikannya."
  • 25 Juni 2018, donnelldebnam / CodeU […] / pull / 151 "Terima kasih !!"

Tambalan pertama yang digabungkan oleh bot perbaikan program kami diterima oleh pengembang manusia pada 12 Januari 2018. Ini adalah kisahnya: pada 12 Januari 2018 pukul 12:28 siang, sebuah bangunan dipicu pada proyek aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. Pembangunan gagal setelah 2 menit eksekusi, karena dua kasus pengujian salah. Empat puluh menit kemudian, pada 12 Januari 2018 pukul 13:08, Repairnator mendeteksi pembangunan yang gagal selama pemantauan rutinnya, dan mulai menjalankan sistem perbaikan program yang tersedia yang dikonfigurasi dalam Repairnator. Sepuluh menit kemudian, pada pukul 1:18 siang, ia menemukan sebuah tambalan.

Pada 12 Januari 2018, pada pukul 1:35 siang, seorang anggota tim Repairnator mengambil tambalan yang dihasilkan oleh Repairnator, dan memvalidasi pembukaan permintaan tarik yang sesuai di GitHub. Pada 12 Januari 2018, pukul 14:10, pengembang menerima tambalan, dan menggabungkannya dengan komentar: "Aneh, saya pikir saya sudah memperbaiki ini ... mungkin saya lakukan di tempat lain. Terima kasih untuk tambalannya! ". Itu tambalan pertama yang diproduksi oleh Repairnator dan diterima sebagai kontribusi yang valid oleh pengembang manusia, yang secara definitif bergabung dalam basis kode. Dengan kata lain, Repairnator adalah manusia-kompetitif untuk pertama kalinya.

Setelah 6 bulan beroperasi, Repairnator telah memiliki 5 tambalan yang digabungkan oleh pengembang manusia, yang tercantum di atas.

Secara keseluruhan, proyek Repairnator telah memenuhi misinya. Telah menunjukkan bahwa perbaikan program dapat dianggap sebagai daya saing manusia: Repairnator telah menemukan tambalan 1) sebelum manusia, 2) yang dianggap berkualitas baik oleh manusia sendiri.

Masa depan

Selain menunjukkan bahwa perbaikan program adalah daya saing manusia, proyek Repairnator telah memberikan banyak informasi tentang bug dan integrasi berkelanjutan, dan tentang kekurangan saat ini dari penelitian perbaikan program, disajikan dalam [7].

Mari kita membahas satu hal khususnya, masalah kekayaan intelektual. Pada 3 Mei 2018, Repairnator menghasilkan tambalan yang baik untuk proyek GitHub / ditto. Tak lama setelah mengusulkan tambalan, salah satu pengembang bertanya "Kami hanya dapat menerima permintaan tarik yang datang dari pengguna yang menandatangani Perjanjian Lisensi Kontributor Eclipse Foundation.". Kami bingung karena bot tidak dapat secara fisik atau moral menandatangani perjanjian lisensi dan mungkin tidak berhak melakukannya. Siapa yang memiliki kekayaan intelektual dan tanggung jawab kontribusi bot: operator robot, pelaksana bot atau perancang algoritma perbaikan? Ini adalah salah satu pertanyaan menarik yang ditemukan oleh proyek Repairnator.

Kami percaya bahwa Repairnator memperkirakan masa depan tertentu pengembangan perangkat lunak, di mana bot dan manusia akan berkolaborasi dengan lancar dan bahkan bekerja sama dalam artefak perangkat lunak.

Ingin bergabung dengan komunitas Repairnator? Untuk menerima berita rutin tentang Repairnator, kirim email ke repairnator.subscribe@4open.science!

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

Di media:

  • Kehidupan misterius Luc Esape, bug fixer yang luar biasa. Rahasia besarnya? Dia bukan manusia (Thomas Claburn, The Register)

Referensi

  • [1] J. R. Koza (2010) Hasil Persaingan Manusia Diproduksi oleh Pemrograman Genetik. Pemrograman Genetika dan Mesin Evolvable 11 (3–4), hlm. 251–284. Dikutip oleh:.
  • [2] C. Lebeuf, M. D. Storey dan A. Zagalsky (2018) Bot perangkat lunak. Perangkat Lunak IEEE 35, hlm. 18–23. Dikutip oleh: Perbaikan Otomatis dan Integrasi Berkelanjutan.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan dan M. Monperrus (2016) Perbaikan Otomatis Bug Nyata di Jawa: Eksperimen Skala Besar pada Dataset Defects4j. Rekayasa Perangkat Lunak Empiris, hlm. 1–29. Dikutip oleh: Daya saing manusia,.
  • [4] M. Monperrus (2017) Perbaikan Perangkat Lunak Otomatis: Bibliografi. Survei Komputasi ACM. Dikutip oleh: Perbaikan Otomatis dan Integrasi Berkelanjutan,.
  • [5] A. Murgia, D. Janssens, S. Demeyer dan B. Vasilescu (2016) Di antara mesin-mesin: Interaksi manusia-bot pada situs web sosial & sosial. Dalam Prosiding Konferensi CHI 2016 Diperpanjang Abstrak tentang Faktor Manusia dalam Sistem Komputasi, hal. 1272-1279. Dikutip oleh: Daya saing manusia.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues dan Y. Brun (2015) Apakah obatnya lebih buruk daripada penyakitnya? overfitting dalam perbaikan program otomatis. Dalam Prosiding Pertemuan Gabungan ke-10 tahun 2015 tentang Yayasan Rekayasa Perangkat Lunak, hal. 532–543. Tautan Eksternal: Dokumen Dikutip oleh: Daya saing manusia.
  • [7] S. Urli, Z. Yu, L. Seinturier dan M. Monperrus (2018) Bagaimana Mendesain Bot Perbaikan Program? Wawasan dari Proyek Repairnator. Dalam ICSE 2018–40 Konferensi Internasional tentang Rekayasa Perangkat Lunak, Lacak Rekayasa Perangkat Lunak dalam Praktek, Tautan Eksternal: Tautan Dikutip oleh: Prestasi Ekspedisi, Masa Depan.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta dan S. Panichella (2017) Kisah Kegagalan Pembangunan CI: Sumber Terbuka dan Perspektif Organisasi Keuangan. Dalam Konferensi Internasional tentang Pemeliharaan dan Evolusi Perangkat Lunak, Dikutip oleh: Perbaikan Otomatis dan Integrasi Berkelanjutan.