Ulasan Kode, apa kelebihannya? [Tutup]

Di tim saya, kami tidak melakukan tinjauan kode formal. Kita cenderung berpikir bahwa itu cukup dengan pemrograman pasangan dan pasangan berputar sering.

Haruskah kita mempertimbangkan melakukan tinjauan kode formal? Apa kelebihannya?

Kami melakukan review kode yang sedikit berbeda (mungkin).

Kami datang bersama semua programmer (setiap hari Jumat) dan lihat apa yang telah kami lakukan dalam periode minggu. Kemudian kami memilih proyek apa yang ingin kami tinjau sehingga setiap proyek yang dikerjakan / sedang berlangsung akan memiliki setidaknya satu atau beberapa orang. Kemudian dalam satu jam atau lebih kita melihat perubahan yang telah dibuat, mencari kesalahan, bagaimana proyek lain bekerja dan lain-lain. Setelah itu kita berdiskusi, mengatakan kesalahan, bagaimana seharusnya dilakukan (kita tidak memperbaiki bug, kita hanya menunjukkannya. dan spam kode dengan FIXME). Semua itu biasanya bagi kita (10 programmer) membutuhkan waktu sekitar 2 jam.

Pro:

• Setiap anggota tahu apa yang terjadi di perusahaan
• Bug ditemukan lebih cepat
• Itu memaksa kita untuk menulis kode yang dapat dibaca (kode yang dapat dibaca tanpa penjelasan atau memperkenalkan!)
• Metode optimasi / trik / program produktif menyebar lebih cepat
• Programmer sebagai spesialis "berkembang" lebih cepat
• Itu menyenangkan

Apa yang saya miliki terhadap pemrograman pasangan seperti yang disebutkan (yakin itu hanya pendapat pribadi saya) adalah bahwa semakin lama tim bekerja bersama - semakin cepat.

Saya berharap itu akan membawa beberapa makanan untuk dipikirkan. Semoga berhasil.

Anda mungkin ingin membaca buku gratis ini:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

Tentu, mereka memiliki produk untuk didorong, tetapi masih ada banyak informasi berguna di sana.

Mereka juga membahas bagaimana pemrograman berpasangan memberikan beberapa keuntungan yang sama, jadi jika Anda memprogram pemrograman Anda mungkin tidak perlu meninjau kode sama sekali.

Saya tidak punya banyak pengalaman dalam meninjau di lingkungan Anda. Kami tidak melakukan banyak pemrograman berpasangan di sini, kami melakukan tinjauan kode untuk menyebarkan pengetahuan tentang perangkat lunak dalam tim, memiliki sepasang mata lain untuk mengambil kesalahan dan memiliki titik formal untuk memeriksa apakah perangkat lunak mematuhi pedoman pengkodean kami. .

2 poin pertama cukup baik dicakup oleh pemrograman pasangan, yang ketiga sangat tergantung pada pasangan dan bisa menjadi lebih baik dari tinjauan kode formal.

Haruskah Anda melakukan tinjauan kode formal?

Benar

Hanya sebagai sisi catatan singkat, saya memiliki sangat sedikit pengalaman dengan pemrograman berpasangan, tapi saya tidak percaya bahwa ulasan akan bertentangan dengan metode ini.

Saya akan memperkenalkan dua bentuk ulasan kode:

Ulasan kode rekan

Bahkan jika pemrograman berpasangan bekerja untuk Anda, tidak ada salahnya untuk mendapatkan satu set mata lain pada kode. Manfaat untuk ini adalah:

1. Ini mendapat satu set mata segar pada kode, seseorang yang mungkin memiliki pengetahuan yang lebih intim tentang basis kode yang Anda (dan / atau pasangan Anda) mungkin tidak terbiasa dengan. Ini bisa mengungkap masalah knock-on.
2. Itu membuat Anda (pasangan) memvalidasi ulang solusi Anda sebelum pengiriman. Karena pengulas tidak tahu apa pun tentang apa yang Anda tulis, Anda harus menjelaskannya secara keseluruhan. Ini dapat mengungkap kasus tepi yang tidak Anda pikirkan, atau logika yang tidak valid.

Ulasan kode rekan (di dunia saya) dilakukan sebelum setiap pengiriman. Bagaimana ini terjadi di dunia pemrograman berpasangan, saya tidak yakin.

Ulasan kode grup

Ini terjadi lebih jarang daripada ulasan kode rekan. Saya biasanya akan menarik grup saya (atau subbagian dari grup saya) di ruang pertemuan untuk peninjauan kode informal. Saya biasanya memilih beberapa kode yang ditulis oleh orang yang acak di tim, lebih disukai kode yang ditulis dari awal - kode yang dire-refaktasi tidak memunculkan masalah seperti kode baru.

Pastikan semua orang tahu bahwa ulasan ini tidak dimaksudkan untuk mendukung dan tidak digunakan untuk mencerminkan kinerja. Mereka hanya untuk memastikan bahwa standar pengkodean tim Anda diikuti dan untuk membantu semua orang menjadi insinyur yang lebih baik dan dengan demikian, menjadi lebih bermanfaat bagi tim (dan pertumbuhan karier lebih lanjut, dll.) - dan memastikan bahwa ini adalah maksud sebenarnya dari ulasan . Jika ada yang mencurigai sesuatu yang berbeda, ini akan menjadi takut dan kurang produktif.

Saya akan membaca kode ini secara tidak resmi, membiarkan siapa pun di dalam ruangan menunjukkan solusi berbeda yang mungkin mereka miliki atau kesalahan logika yang mereka temui. Ini dimaksudkan untuk menjadi lebih dari diskusi kelompok daripada seorang pemimpin yang duduk di sana memberitahu semua orang bagaimana mereka harus kode.

Saya telah menemukan bahwa menggunakan kedua metode ini meningkatkan tingkat kemajuan insinyur serta menurunkan jumlah bug secara signifikan :)

Saya belum pernah melakukan pemrograman berpasangan dalam praktek (hanya berharap untuk itu), jadi saya tidak bisa langsung membandingkan kedua latihan tersebut. Namun, saya dapat menceritakan pengalaman saya dengan ulasan kode formal.

Saya biasa memimpin tinjauan kode formal dalam proyek sebelumnya, pada kode warisan. Proyek ini berantakan total dan manajemen menyambut inisiatif dengan harapan membawa ketertiban ke dalam kekacauan. Pada waktu itu saya pikir tinjauan kode formal adalah ide yang bagus. Kami memang menemukan bug, dan kami memang melihat bahwa kualitas kode yang baru ditulis secara signifikan lebih baik daripada kode lama. Saya mengumpulkan statistik, jumlah bug, dll. Untuk membuktikan ini.

Kami melakukan satu sesi per minggu rata-rata, yang melibatkan 3-5 orang. Setiap sesi memakan waktu sekitar 3-4 jam per orang (termasuk persiapan), dan mengulas 200-300 baris kode (LOC) *. Dengan kecepatan ini, selama periode lebih dari 6 bulan, kami berhasil meninjau sekitar 5K LOC, dari sekitar 50K.

Dalam retrospeksi, saya merasa itu sangat mahal. Dengan kecepatan ini, kami butuh 5 tahun untuk meninjau seluruh basis kode warisan. OTOH memiliki lebih dari satu sesi seminggu akan mengambil sumber daya dari pengembangan. Tentu saja, itulah dilema khas dengan kode legacy. Tetapi bahkan meninjau semua kode yang baru ditulis secara formal akan membutuhkan banyak waktu, memperlambat pengembangan secara signifikan.

Kesimpulan saya adalah bahwa tinjauan kode formal paling baik dilakukan pada kode yang baru ditulis, berfokus pada bagian paling kritis dari kode. Sisanya lebih baik ditangani dengan cara yang lebih informal, mungkin melalui pemrograman pasangan. Ini hanya pendapat saya saat ini, yang dapat berubah. Saya tidak mengklaim sebagai guru ulasan kode atau apa pun.

* Ini adalah langkah normal dari tinjauan kode formal.

Tarif ulasan kode biasanya sekitar 150 baris kode per jam. Memeriksa dan meninjau lebih dari beberapa ratus baris kode per jam untuk perangkat lunak penting (seperti perangkat lunak tertanam yang aman untuk keselamatan) mungkin terlalu cepat untuk menemukan kesalahan.

Dikutip dari Wikipedia (penekanan oleh saya).

Alasan yang mendasari ulasan kode ada adalah karena programmer terisolasi perlu bertemu dan mendiskusikan kode mereka dan memeriksa apakah itu sesuai dengan standar mereka.

Anda tidak menyebutkan masalah kualitas, jadi sepertinya tim Anda sudah melakukan cukup tinjauan kode melalui pemrograman pasangan mereka. Luar biasa!

Pemrograman pasangan yang dilakukan dengan benar membuat ulasan kode formal berlebihan. Tetapi cobalah selama beberapa minggu dan lihat bagaimana hasilnya, tetapi saya kira Anda tidak akan melihat adanya peningkatan.

Perlu diingat bahwa tinjauan kode adalah proses yang melelahkan dan mahal dan bukan sesuatu yang bisa dianggap enteng. Ini pada dasarnya memperkenalkan penyerahan dalam proyek Anda yang mahal dan memperlambat semuanya . Jauh lebih baik untuk memastikan kode itu benar sejak awal, daripada mencoba mencari masalah nanti.

Mungkin. Ulasan kode membutuhkan waktu. Mereka hanya bermanfaat jika waktu yang diambil oleh ulasan disimpan di titik lain dalam proses. Penghematan apa yang Anda harapkan dari ulasan kode? Apakah Anda mengalami kesulitan yang dapat dicegah dengan ulasan kode?

Jika Anda melakukan pemrograman berpasangan, kebutuhan untuk tinjauan kode secara substansial menurun tetapi Anda tentu akan mendapat manfaat dari tinjauan rekan. Agar ini bermanfaat, itu harus dilakukan oleh seseorang yang lebih senior dan lebih berpengalaman daripada pasangan anggota.

Apa manfaatnya? Ya, akan lebih baik jika Anda mempertimbangkan risiko tidak melakukannya.

• Pasangan bisa melakukan sesuatu yang salah atau mungkin melakukannya dengan cara yang tidak optimal
• Mungkin Anda tidak mengikuti standar pengkodean atau tidak mendokumentasikan kode dengan benar. Ulasan sejawat sangat bagus dalam menemukan ini
• Tidak ada orang lain selain pasangan yang memahami sepotong kode tertentu. Jadi apa yang terjadi jika kedua anggota pasangan telah pergi dan kodenya tidak terdokumentasi dengan baik? Yang lain akan membuang waktu untuk mencari tahu. Memiliki orang ketiga yang tahu apa yang telah Anda lakukan mengurangi risiko.

Saya senang orang-orang mengatakan bahwa review kode hanya membuang-buang waktu. Ya, memang butuh waktu. Mungkin itu tidak akan menghasilkan perubahan dalam kode tetapi itu tidak berarti itu sia-sia. Itu seperti mengatakan Anda tidak perlu memeriksa sistem kebakaran Anda secara teratur karena itu buang-buang waktu.

Bagi saya keuntungan utama dari tinjauan kode adalah membuat orang menulis kode yang lebih baik.

Mengetahui bahwa kode Anda akan dibaca dan diulas membuat Anda lebih sadar akan keterbacaan dan "benar" kode Anda. Ketika Anda tahu kode akan langsung masuk ke dalam repositori dan tidak ada orang lain yang akan membacanya kecuali jika mereka memperbaiki cacat Anda cenderung membiarkan hal-hal tergelincir seperti tidak re-factoring nama bidang ketika penggunaannya berubah, meninggalkan metode yang tidak digunakan berkeliaran kalau-kalau mereka mungkin diperhitungkan kembali dll. dll