Menggunakan Data Science untuk Mengeksplorasi Pengembangan Perangkat Lunak

Banyak pengembang perangkat lunak mempelajari data science untuk menganalisis data pelanggan mereka. Semakin banyak yang menyadari bahwa mereka dapat menggunakan teknik yang sama untuk menjawab pertanyaan mereka sendiri, seperti:

• Kapan proyek ini siap untuk dirilis?
• Komponen mana dari aplikasi kami yang paling perlu diuji?
• Siapa yang seharusnya memperbaiki bug ini?
• Bagian mana dari API saya yang paling sulit digunakan orang?

Selama 15 tahun terakhir, terjadi ledakan penelitian empiris dalam rekayasa perangkat lunak untuk mengeksplorasi pertanyaan-pertanyaan ini, didorong sebagian oleh ketersediaan data dari situs seperti GitHub dan Stack Overflow. Postingan blog ini menyajikan beberapa hasil yang representatif, lalu membahas metode di balik tiga di antaranya dengan lebih rinci.

Jika Anda ingin mengetahui lebih lanjut tentang cara menggunakan data science untuk mendapatkan wawasan seperti ini dalam proyek Anda sendiri, silakan beri tahu saya.

Data Science dan Rekayasa Perangkat Lunak: Contoh

Mari mulai dengan sebuah temuan yang memengaruhi semua orang yang melakukan data science dalam skala besar: penemuan Yuan dkk. bahwa pengujian sederhana dapat mencegah sebagian besar kegagalan kritis pada sistem terdistribusi yang intensif data. Mereka menelaah kegagalan pada Cassandra, Hadoop MapReduce, dan sistem serupa, dan menemukan bahwa:

1. Hampir semua kegagalan memerlukan 3 node komputasi atau kurang untuk direproduksi. Artinya, Anda biasanya tidak membutuhkan klaster untuk men-debug klaster.
2. Log kesalahan biasanya berisi cukup data untuk memungkinkan reproduksi.
3. Mayoritas kegagalan katastrofik sebenarnya bisa dicegah dengan mudah dengan melakukan pengujian sederhana pada kode penanganan kesalahan.

Poin terakhir adalah yang paling tidak terduga. Meskipun para profesional biasanya menguji bahwa kode analisis mereka berfungsi saat semuanya berjalan baik, mereka jarang menguji bahwa kode tersebut melakukan hal yang benar ketika sesuatu berjalan salah. Menambahkan hanya beberapa pengujian semacam itu selama pengembangan akan mencegah banyak masalah di hilir.

Hasil skala besar lainnya datang dari karya Altadmri dan Brown, yang meneliti 37 juta upaya mengompilasi program oleh siswa sekolah menengah di Inggris. Mereka kemudian menanyakan kepada para guru apa kesalahan paling umum yang dilakukan siswa mereka, dan menemukan bahwa:

1. Para guru tidak saling sepakat tentang kesalahan apa yang paling mungkin dilakukan siswa.
2. Yang lebih penting, prediksi para guru hanya memiliki korelasi lemah dengan apa yang sebenarnya salah dilakukan oleh siswa.

Tentu saja, penambangan data bukan satu-satunya cara untuk menghasilkan wawasan berbasis bukti yang berguna dalam pemrograman. Pada 2013, tim Andreas Stefik menerbitkan studi kedua dalam rangkaian penelitian tentang apakah beberapa bahasa lebih mudah untuk dipelajari dibanding yang lain. Sebagai garis dasar, mereka memasukkan bahasa rekaan dalam studi mereka yang kata kuncinya dihasilkan secara acak.

Yang mengejutkan mereka, bahasa dengan kurung kurawal seperti Java dan Perl sama sulitnya bagi pemula untuk dipelajari pengenalannya seperti bahasa yang dihasilkan secara acak. Python dan Ruby jauh lebih mudah dipelajari, dan Quorum, yang melakukan A/B testing pada sintaks setiap fitur baru sebelum menambahkannya, bahkan lebih mudah lagi. Andreas membahas hasil ini, dan alasan mengapa perancang bahasa pemrograman begitu sedikit memperhatikan kegunaan, dalam podcast yang menghibur ini.

Mengidentifikasi Laporan Bug Keamanan

Sebagai contoh bagaimana studi-studi ini dilakukan, Fayola Peters di LERO menggunakan model prediksi berbasis teks untuk menemukan laporan bug keamanan di pelacak bug sistem besar sehingga pengerjaan atasnya dapat diprioritaskan. Dalam satu studi, ia menggunakan data dari proyek Chromium, Wicket, Ambari, Camel, dan Derby; ini berisi total 45.940 laporan bug, namun hanya 0,8% yang merupakan laporan bug keamanan.

Beberapa bug keamanan diberi label secara manual, dan ini dapat digunakan untuk melatih pengklasifikasi guna mendeteksi yang tidak berlabel. Teknik seperti Naïve Bayes dan Random Forests menjadi titik awal, tetapi efisiensi model generik sering kali dapat ditingkatkan melalui penyaringan kata kunci tertentu. Pemeriksaan terpenting adalah seberapa baik model yang dibangun dari proyek dengan bug keamanan berlabel dapat menemukan bug serupa di proyek lain. Hasilnya menggembirakan: Peters menemukan bahwa pengklasifikasinya cukup bekerja dengan baik untuk berguna dalam praktik.

Apakah Patch Saya Akan Diterima?

Sebagai contoh kedua, perusahaan ingin modifikasi mereka disertakan dalam proyek agar terhindar dari keharusan memelihara kode sendiri, dan relawan juga ingin mendapat indikasi apakah patch mereka memiliki peluang. Karena sering ada jeda waktu panjang antara pengajuan patch dan penerimaan, Bram Adams dan kelompoknya di Polytechnique Montréal telah membangun model untuk memprediksi patch mana yang akan diterima.

Seperti banyak proyek data science, ini dimulai dengan mengambil dan membersihkan data dari berbagai sumber, termasuk repositori Git dan ulasan kode Gerrit. Namun, untuk proyek yang menggunakan ulasan berbasis email, seperti kernel Linux, pengumpulan data berarti mengikis arsip milis dan menggunakan heuristik seperti checksum patch atau irisan berbasis himpunan dari baris yang diubah untuk mencocokkan patch dengan percakapan. Bahkan dengan bantuan alat seperti GrimoireLab, akan selalu ada patch yang beberapa versinya ditinjau, dan patch yang dipecah menjadi beberapa bagian yang ditinjau secara terpisah. Seperti dalam semua data science, analislah yang harus membangun model, dan asumsi di dalamnya akan sangat memengaruhi kesimpulan akhir.

Langkah kedua adalah memutuskan variabel apa yang akan diperiksa dan metrik apa yang akan digunakan untuk masing-masing, seperti:

• kualitas patch
• pengalaman pengembang patch
• proses ulasan (misalnya, komentar ulasan dan jumlah peninjau)
• kualitas ulasan (misalnya, tingkat kedetailan ulasan)
• waktu ulasan
• interaksi penulis patch dan peninjau (misalnya, ramah versus marah)

Hanya setengah lusin ini saja mungkin menggunakan segala sesuatu mulai dari statistik kelangsungan hidup hingga analisis sentimen. Setelah memutuskan apa yang akan diukur, Anda dapat menerapkan alat data science yang diajarkan kursus DataCamp. Karena tujuan nyata Anda adalah memprediksi penerimaan patch di masa depan, pendekatan paling lugas adalah regresi logistik, tetapi ada banyak yang lain.

Terakhir, Anda dapat mengukur pentingnya variabel untuk menentukan dampak masing-masing variabel pada penerimaan patch. Ini pasti sebagian bersifat kualitatif, karena tujuan Anda adalah mengidentifikasi apa yang dapat dilakukan pengembang untuk meningkatkan peluang karya mereka masuk ke produk. Seperti biasa, Anda harus berhati-hati agar tidak menyamakan korelasi dengan kausalitas, tetapi bahkan beberapa rekomendasi sederhana (seperti "JANGAN GUNAKAN HURUF KAPITAL SEMUA DALAM PESAN COMMIT ANDA") dapat membuat perbedaan nyata.

Menemukan Bantuan

Perubahan terbesar dalam cara kerja pemrogram selama 20 tahun terakhir bukanlah pada bahasa yang mereka gunakan: melainkan ketergantungan yang nyaris universal pada Stack Overflow untuk bertanya dan mendapatkan jawaban. Christoph Treude di University of Adelaide dan kolaboratornya telah mengembangkan metode untuk membuat situs seperti ini lebih bermanfaat.

Titik awal mereka adalah dump data Stack Overflow. Setelah melakukan beberapa statistik eksploratori untuk melihat jumlah kata dan kalimat, kata-kata paling umum, term frequency–inverse document frequency (TF-IDF), dan sebagainya, langkah berikutnya adalah melihat kata-kata mana dalam utas Stack Overflow yang muncul bersamaan dengan suara lebih tinggi, tingkat penerimaan lebih tinggi, dan jumlah tayang lebih tinggi.

Karena dokumentasi perangkat lunak berisi banyak kalimat tidak lengkap dan elemen kode, pustaka pemrosesan bahasa alami siap pakai sering kali keliru. Dokumentasi perangkat lunak yang ditulis dalam bahasa selain bahasa Inggris bahkan lebih sulit diurai karena masih cenderung menggunakan bahasa Inggris untuk terminologi teknis. Artinya, dokumentasi itu mencampur dua bahasa alami dan elemen kode. Heuristik ad hoc dan teknik pemodelan yang lebih maju harus digunakan bersama untuk menangani kasus seperti ini.

Menyatukan potongan-potongan tersebut memungkinkan pembuatan alat yang mengambil nama modul Python sebagai masukan dan menghasilkan kalimat bermakna tentang modul ini dari utas Stack Overflow. Lebih jauh lagi, Treude dan kolaboratornya mampu menggunakan ketergantungan gramatikal antar kata untuk secara otomatis menemukan dokumentasi perangkat lunak yang menjelaskan cara melakukan suatu tugas, dan kemudian secara otomatis mengidentifikasi potongan kode yang dapat menyelesaikan tugas tersebut.

Kesimpulan

Terlalu sering, kebenaran yang diyakini luas tentang pengembangan perangkat lunak didasarkan pada opini kuat dan suara lantang, bukan bukti. Seperti dijelaskan di awal, hal itu berubah seiring ratusan studi berkualitas tinggi muncul setiap tahun untuk mendukung beberapa keyakinan, seperti "ulasan kode memang cara terbaik untuk menemukan bug", dan menantang yang lain, seperti "pengembangan berbasis pengujian tidak seefektif yang diyakini sebagian orang, dan pernyataan goto sebenarnya tidak berbahaya".

"Rekayasa" telah didefinisikan sebagai "penerapan metode ilmiah untuk menciptakan hal-hal yang berguna". Jika itu benar, maka pengembangan perangkat lunak pada akhirnya, berkat data science, mungkin sedang berada di jalur untuk menjadi disiplin rekayasa yang sesungguhnya. Jika Anda ingin melihat kursus yang menunjukkan cara menerapkan data science pada pengembangan perangkat lunak, silakan beri tahu kami.

Bacaan Lanjutan

Para peneliti menyajikan puluhan temuan baru di bidang ini setiap tahun pada konferensi seperti Mining Software Repositories. Beberapa prosidingnya masih terkunci di balik paywall akademik, tetapi semakin banyak peneliti yang menyediakan pracetak.

Bagi yang mencari gambaran umum, buku tahun 2010 Making Software adalah kumpulan "greatest hits" dari hasil paling menarik saat itu. Trilogi baru berjudul Perspectives on Data Science for Software Engineering, The Art and Science of Analyzing Software Data, dan Sharing Data and Models in Software Engineering memberikan cakupan yang lebih luas dan lebih mutakhir tentang topik yang sama, dan secara terpisah, Derek Jones sedang mengerjakan buku baru berjudul Empirical Software Engineering Using R.