Don’t Touch My Code!!! | Part 2
Analisis Relasi antara Ownership dan Kualitas Software
Sebelumnya telah dijelaskan mengenai beberapa teori mengenai hubungan antara ownership dan kualitas software serta beberapa asumsi awal. Kita akan melanjutkan kepenjelasan mengenai beberapa istilah atau terminologi dan metrik perhitungan yang akan digunakan.
Terminology dan Metriks
Kita perjelas dahulu tujuan dari analisis ini yakni, mengetahui relasi antara ownership dan kualitas software. Kita berharap juga mendapatkan informasi dan pemahaman tambahan dari variasi sebaran relasi yang dimaksud terhadap proses development yang digunakan.
Dengan demikian, akhirnya kita mendapatkan arahan proses development apa yang terbaik harus digunakan dan kebijakan-kebijakan apa yang harus diambil sehingga menghasilkan software dengan kualitas yang lebih baik dan minim bug dan cacat.
Untuk mencapai tujuan di atas, berikut beberapa pertanyaan yang kita gunakan.
- Apakah tingkat ownership yang tinggi akan terkait langsung dengan jumlah bug yang lebih sedikit?
- Apakah ada pengaruh negatif ketika sebuah software dibuat oleh banyak team dengan level ownership rendah?
- Apakah pengaruh negatif tersebut berhubungan dengan proses development yang digunakan?
Selain pertanyaan di atas, kita tentukan pula beberapa metrik dan istilah yang akan digunakan dalam menguji hipotesis yang akan disampaikan nanti. Berikut adalah istilah dan metrik-matriksnya.
- Software Component. Merupakan bagian atau unit dari software yang memiliki fungsi utama tertentu (core function). Bug dan cacat (defect) dapat kita telusuri sampai ke komponen-komponen tersebut. Perubahan yang dibuat team developer dapat kita telusuri juga sampai ke komponen ini.
- Contributor. Merupakan software developer yang telah memberikan andil berupa penambahan code pada komponen suatu software. Kita biasanya menyebutnya sebagai setiap orang yang telah melakukan commit pada repository dari source code.
- Proporsi dari Ownership. Merupakan ukuran banyaknya jumlah commit yang telah dilakukan berbanding dengan total commit yang terjadi. Misalkan, Ahmad telah melakukan 20 kali commit terhadap some.dll file. Total commit yang ada adalah 100 kali. Dengan demikian, Ahmad memiliki ownership 20%. Catatan, yang kita hitung adalah banyaknya commit bukanlah banyaknya line of code (LOC) yang dibuat.
- Minor Contributor. Merupakan developer yang telah melakukan commit source code dengan jumlah proporsi paling banyak sebesar 5%. Penentuan batasan ini diambil dari beberapa hasil penelitian, salah satu contohnya hasil kurva distribusi penelitian team Microsoft yang meneliti level ownership dan kualitas OS Windows pada versi tertentu.
- Major Contributor. Merupakan developer yang telah melakukan commit source code dengan total proporsi lebih dari 5%.
- Ownership. Merupakan nilai perbandingan antara Mayor/Minor. Semakin tinggi nilainya berarti menunjukkan ownership yang semakin bagus atau besar dampaknya.
Seperti dijelaskan secara singkat di atas, bahwa kita menghitung kontribusi berdasarkan banyaknya jumlah commit yang terjadi bukan berdasarkan banyaknya line of code yang dibuat. Hal ini diambil karena banyaknya commit lebih menunjukkan exposure team terhadap ownership. Tentu saja commit yang terjadi bukanlah sembarang commit, tetapi merupakan commit yang sudah tervalidasi atau di review dengan benar serta memiliki maksud dan tujuan.
Hal ini sejalan juga dengan hasil penelitian yang pernah dilakukan dan dipublikasi oleh, S. Elbaum dan J. Munson. Code churn: A measure for estimating the impact of code change. In Proceedings of the International Conference on Software Maintenance, 1998.
Dari grafik di atas dapat dijelaskan sebagai berikut. Source code memiliki total commit sebanyak 918. Kontributor teratas sebanyak 379 sekitar 41% dan ada 5 developer yang memiliki kontributor di atas 5% serta total developer yang telah commit adalah 17. Dengan demikian, metrik untuk library example.dll ini adalah sebagai berikut.
Hypothesis
Kita mulai dengan asumsi bahwa developer dengan tingkat keahlian yang rendah akan menghasilkan banyak bug. Developer yang telah memberikan commit pada source code dengan jumlah yang sedikit diperkirakan memiliki skill yang lebih rendah dan akan memberikan kemungkinan bug atau defect yang lebih tinggi. Semakin banyak jumlah kontributor maka semakin menurun pula perkiraan kualitas software yang dihasilkan.
Hypothesis 1. Komponen software dengan jumlah minor kontributor yang banyak akan memberikan kemungkinan jumlah kesalahan terjadi daripada komponen software dengan jumlah kontributor minornya sedikit.
Dapat dilihat juga terhadap proporsi ownership pada kontributor tertinggi untuk setiap komponen. Jika nilai ownership tinggi maka ada satu developer yang jadi “pemilik” komponen tersebut dan memiliki level expertise yang tinggi. Orang ini pun berfungsi sebagai man of the match dan merupakan support yang bagus untuk team lain yang membutuhkan komponen tersebut atau setidaknya untuk tempat bertanya. Apabila ada orang ini dalam team maka level kualitas dari komponen tersebut diperkirakan akan bagus.
Hypothesis 2. Komponen software dengan nilai ownership yang tinggi akan menghasilkan kualitas software yang lebih bagus.
Jika jumlah minor kontributor berdampak negatif pada kualitas software, kita harus mengetahui kenapa jumlah minor kontributor ini sangat begitu banyak? Berdasarkan beberapa pengalaman, hal ini terjadi biasanya selama proses development, baik itu ketika fixing bug, penambahan fitur baru, atau sekadar maintenance, seorang pemilik komponen harus melakukan perubahan di komponen lain terlebih dahulu.
Sebagai contoh, pada media player A seorang developer harus fixing bug terkait proses pemutaran lagu. Dikarenakan proses pemutaran lagu membutuhkan library codex.dll sehingga perbaikan code di bagian interfacenya dibutuhkan untuk dilakukan.
Biasanya developer tersebut harus membenarkan dahulu di library codex.dll tadi, padahal dia bukanlah pemilik dari library. Hal ini dikarenakan pemilik codex.dl lagi fokus mengerjakan tugas lainnya.
Kejadian inilah yang sering terjadi sehingga membuat kontributor minor semakin banyak di salah satu komponen software.
Hypothesis 3. Minor kontributor pada suatu komponen tidak menunjukan bawah developer ini memiliki skill yang kurang bagus. Developer ini bisa menjadi kontributor utama atau major kontributor pada komponen lainnya.
Apabila para developer dengan skill kurang sangat berpengaruh terhadap kualitas software, maka kita berharap bawa prediksi bug dan cacat terhadap ownership benar adanya.
Hypothesis 4. Apabila kita menghilangkan atau meminimalkan jumlah minor kontributor maka kualitas dari software akan meningkat.
Demikianlah, beberapa hipotesis di atas akan kita gunakan dalam menganalisis data dari lapangan untuk mendapatkan kesimpulan dan masukan yang positif bagi kualitas software yang lebih baik.
Selanjutnya proses pengambilan data, analisis proses, dan kesimpulan akan dilanjutkan di artikel selanjutnya.
References
- https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/
- Quality Code: Software Testing Principles, Practices, and Patterns 3rd Edition
Sponsor
Membutuhkan kaos dengan tema pemrograman :
Dapat menghubungi The Legend.
