Bagaimana cara menentukan efektivitas proses peninjauan kode?


14

Kami telah memperkenalkan proses peninjauan kode dalam organisasi kami dan tampaknya berfungsi dengan baik. Namun, saya ingin dapat mengukur keefektifan proses dari waktu ke waktu, yaitu apakah kita tidak menemukan bug karena kodenya bersih atau apakah orang tidak mengambil bug?

Saat ini, kami tidak memiliki proses pengujian otomatis otomatis yang efektif. Kami terutama menggunakan pengujian manual, jadi kami tidak dapat mengandalkan cacat yang ditemukan pada tahap ini untuk memastikan bahwa proses peninjauan kode berfungsi.

Adakah yang pernah menemukan masalah ini sebelumnya atau memiliki pemikiran tentang apa yang bekerja dengan baik dalam mengukur ulasan kode?


7
Menemukan bug bukan satu-satunya tujuan ulasan kode. Mereka juga berguna untuk memperkuat standar pengkodean, pelatihan silang, penyerbukan silang ide dan teknologi, dll
Jason

Terima kasih Jason & mengerti, namun dalam hal ini saya mencoba mencari cara untuk memastikan bahwa proses mencapai tujuan intinya pencegahan cacat sedini mungkin dalam proses pengembangan

@ Johnv2020 Itu bukan tujuan intinya meskipun ... Anda benar-benar kehilangan titik tinjauan kode. Ini akan seperti menempatkan fitur keselamatan baru yang hebat di armada pesawat jet, kemudian mencoba menilai efektivitasnya berdasarkan jumlah kecelakaan. Ada terlalu banyak variabel dan faktor lain untuk dipertimbangkan untuk secara akurat membuat klaim bahwa fitur keselamatan meningkatkan kemungkinan kecelakaan tidak terjadi.
maple_shaft

@maple_shaft: Analogi yang lemah. Mencoba untuk mengukur tingkat bug lebih seperti mencoba mengukur jumlah peti mati yang digunakan untuk orang mati dari kecelakaan.
S.Lott

1
Di semua ulasan kode yang saya hadiri, banyak bug telah diperbaiki dalam unit dan pengujian tingkat lebih tinggi. Artinya, kode tidak siap untuk ditinjau hanya karena dikompilasi.
Pete Wilson

Jawaban:


7

Ada sejumlah metrik yang dapat dikumpulkan dari ulasan kode, beberapa bahkan memperpanjang sepanjang siklus proyek.

Metrik pertama yang saya rekomendasikan untuk dikumpulkan adalah defect removal efektivitas (DRE) . Untuk setiap cacat, Anda mengidentifikasi pada tahap apa cacat tersebut diperkenalkan dan pada tahap apa ia dihilangkan. Berbagai teknik deteksi cacat yang Anda gunakan semuanya dinilai secara bersamaan, sehingga berlaku sama untuk ulasan kebutuhan, ulasan desain, ulasan kode, ulasan kode, unit test , dan seterusnya. Anda akan sangat tertarik pada jumlah cacat yang tertangkap dalam fase kode, karena ini mungkin akan mencakup pengujian unit Anda serta ulasan kode. Jika banyak kerusakan dari fase kode yang berhasil sampai ke fase pengujian integrasi atau bahkan bidang, Anda tahu bahwa Anda mempraktikkan post-coding harus dievaluasi.

Berbagai metrik rapat juga akan relevan. Ini termasuk waktu untuk mempersiapkan, waktu dalam rapat, jalur kode membaca, cacat yang ditemukan dalam ulasan, dan sebagainya. Beberapa pengamatan dapat dilakukan dari data ini. Sebagai contoh adalah jika pengulas Anda menghabiskan banyak waktu membaca kode dalam persiapan untuk ulasan, tetapi menemukan sangat sedikit masalah. Ditambah dengan data DRE, Anda dapat menarik kesimpulan bahwa jika cacat sedang diuji dalam pengujian integrasi atau bidang, maka tim Anda perlu fokus pada teknik peninjauan mereka untuk dapat menemukan masalah. Catatan lain yang menarik adalah baris-baris kode (atau ukuran ukuran lain) yang dibaca dalam rapat dibandingkan dengan waktu rapat. Penelitian telah menemukan bahwa kecepatan tinjauan kode tipikal adalah 150 baris kode per jam.

Dengan salah satu dari metrik ini, penting untuk memahami dampaknya pada proses. Analisis akar penyebab, menggunakan teknik seperti mengapa-karena , diagram Lima Mengapa , atau diagram Ishikawa dapat digunakan untuk mengidentifikasi alasan mengapa tinjauan kode (atau teknik peningkatan kualitas lainnya) efektif.

Anda mungkin juga tertarik dengan artikel ini tentang inspeksi dari The Ganssle Group dan sebuah artikel oleh Capers Jones di Crosstalk tentang Potensi Cacat dan DRE .


2

Sementara sebagian besar memang benar demikian tinjauan kode akan mengambil masalah yang agak laten bahwa pengujian mungkin atau mungkin tidak. Namun, menurut pendapat saya Anda mungkin memiliki kode yang benar-benar stabil (praktis bebas bug) tetapi masih ditulis sedemikian rupa sehingga sangat tidak terbaca atau tidak dapat dipertahankan. Jadi mungkin ulasan kode TIDAK mungkin menemukan bug jika sebenarnya tidak ada masalah dalam kode.

Karena itu, saya benar-benar akan bertanya, mengapa orang ingin melakukan review kode? Alasan sederhana mengapa ini penting adalah bahwa kode harus ditingkatkan agar lebih mudah dibaca, dipelihara, dan dikembangkan. Banyak orang harus bisa membaca kode bersih dan masuk akal. Dalam hal itu, tujuan paling sederhana dari proses peninjauan kode adalah menghasilkan kode yang bersih. Jadi ukuran efektivitasnya adalah seberapa bersih kodenya sekarang.

Karena Anda ingin memiliki efektivitas yang terukur - inilah yang akan saya sarankan:

  1. Metrik yang terkait dengan jumlah pengerjaan ulang - Jumlah waktu pengerjaan ulang diterapkan dalam modul / objek / item kerja yang sama adalah ukuran seberapa buruk kode tersebut dalam hal kemampuan pemeliharaan. Ketika tinjauan kode yang efektif diterapkan, seberapa sering kita dapat mengurangi permintaan pengerjaan ulang pada modul yang sama?

  2. Metrik terkait dengan jumlah perubahan yang ditimbulkan setiap permintaan perubahan. Ketika setiap kali permintaan perubahan terjadi - kode dengan faktor buruk akan selalu memiliki jumlah modul yang lebih besar terpengaruh. Ukuran mungkin akan menunjukkan bahwa setelah review kode - sebuah adalah bahwa setiap pengurangan seperti penyebaran perubahan untuk permintaan perubahan serupa di masa lalu?

  3. Metrik yang terkait dengan kecepatan rata-rata yang dapat digunakan untuk menanggapi permintaan perubahan. Ketika kode lebih bersih - lebih cepat dan lebih baik untuk merespons perubahan yang diperlukan. Setelah kode dibersihkan dalam proses peninjauan, mati kami menemukan kecepatan dalam menanggapi permintaan ukuran yang sama.

Saya tidak menempatkan satuan ukuran yang tepat - Anda mungkin dapat membuat pengukuran yang lebih akurat tentang hal ini dari pendekatan ini. Akan ada lebih banyak formalisme penyuluhan dalam pendekatan di atas mengenai hal ini.

Pada dasarnya, maksud saya adalah bahwa alih-alih melihat jumlah bug yang diidentifikasi oleh proses review kode; kita harus mengukur keefektifan dalam hal apakah tinjauan kode telah mampu menjadikan kode menjadi lebih bersih, lebih ramping, dan lebih mudah dirawat; karenanya, kita dapat mengukur efektivitas itu jika kita melihat bahwa permintaan perubahan serupa di masa mendatang menjadi lebih efisien untuk ditanggapi.


1
Meskipun bukan "bug", kurangnya keterbacaan, pemeliharaan, atau evolvabilitas adalah cacat dalam kode dan harus diperlakukan seperti itu. Tidak ada alasan mengapa ini tidak dapat dilacak dalam pelacak cacat, tepat bersama dengan bug yang sebenarnya dalam fungsionalitas. Dengan melakukan ini, Anda juga membuka kemampuan untuk melacak sejumlah metrik terkait cacat lainnya dalam fase pengkodean.
Thomas Owens

1
Sebagai pengembang saya yakin ingin melihat kode bersih. Namun, tinjauan kode sangat mahal. Jadi sebagai manajer mendanai proyek, kode bersih sebenarnya bukan alasan kuat untuk menambahkan 5-10% biaya dan waktu ke anggaran pengembangan saya. Terutama ketika (sebagai manajer) bonus / ulasan saya terikat untuk menyelesaikan proyek saat ini tepat waktu / sesuai anggaran. Jadi pendapat Anda bahwa alasan utama ulasan kode adalah untuk mendapatkan kode yang bersih akan membuat manajer yang baik mengatakan ROI tidak sepadan. Anda dapat berdebat tentang pengembalian jangka panjang, tetapi pada saat itu manajer yang memberikan tepat waktu / sesuai anggaran akan dipromosikan jauh dari masalah itu
Dunk

...masalah. Sementara manajer yang mempromosikan ulasan kode akan memiliki proyek pemeliharaan yang sukses tetapi akan telah diberi nama baru karena tidak menyelesaikan proyek asli tepat waktu / sesuai anggaran seperti manajer yang tidak. OTOH, jika ulasan kode membantu menemukan bug yang tidak ada ulasannya dan yang membiarkan manajer ulasan kode menyelesaikan proyeknya lebih tepat waktu / sesuai anggaran, maka itu adalah cerita yang berbeda. Itulah kisah yang perlu dijual. Yang juga berarti bahwa kode bersih tidak dapat menjadi alasan untuk tinjauan kode.
Dunk

@Dunk Biaya tinjauan kode tergantung pada jenis review kode. Inspeksi formal dengan 3-5 pembaca, moderator, dan kehadiran penulis (5-7 orang di sebuah ruangan) mahal. Pemeriksaan di atas meja yang terdiri dari pengembang lain yang melirik kode selama 10-15 menit juga merupakan tinjauan kode, tetapi jauh lebih formal dan jauh lebih murah. Bahkan pemrograman berpasangan dapat dianggap semacam teknik "review kode". Teknik yang tepat ditentukan oleh faktor-faktor termasuk (tetapi tidak terbatas pada) kekritisan kode, tingkat cacat yang diinginkan, dan jumlah waktu / uang yang akan diinvestasikan.
Thomas Owens

@Dunk - Saya pikir Anda telah membuat argumen untuk mengambil keputusan "haruskah kita mengkaji kode" dari tangan manajer proyek, dan menempatkannya di tangan manajer yang memiliki tanggung jawab untuk platform perangkat lunak jangka panjang. IMO, secara umum, membelanjakan 5-10% ekstra untuk pengembangan ulasan kode yang layak adalah investasi yang berharga dalam hal umur panjang sistem yang sedang dikembangkan. Tetapi mungkin tidak dalam hal anggaran dan jadwal proyek saat ini.
Dawood mengatakan mengembalikan Monica
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.