Apakah kode meninjau praktik yang baik?

Ketika perusahaan tempat saya bekerja mempekerjakan manajer baru, mereka menawari kami untuk meninjau kode seseorang pada setiap pertemuan. Kami mengadakan pertemuan setiap dua minggu, jadi setiap kali salah satu pengembang menunjukkan kode-nya di proyektor, dan yang lain akan membahasnya.

Saya pikir ini akan menjadi luar biasa: setiap pengembang akan lebih berhati-hati saat menulis kode dan kami dapat membagikan pengalaman kami dengan lebih baik. Tapi entah bagaimana kami lupa tentang ini dan tawaran itu tetap saja tawaran.

Apa manfaatnya dan apakah ada kekurangannya?

Ulasan kode adalah praktik yang bagus.

Mungkin ini adalah cara terbaik untuk belajar dari kesalahan dan untuk melihat bagaimana masalah tertentu diselesaikan oleh orang lain. Ini juga salah satu cara terbaik untuk menjaga kualitas dalam basis kode.

Tinjauan kode terjadi di banyak perusahaan, meskipun sulit untuk mengatakan bahwa ada proses khusus yang mereka ikuti.

Dalam tinjauan kode yang lebih formal, senior (atau beberapa senior) akan duduk bersama dengan pengembang untuk meninjau kode mereka, menawarkan saran dan mengajar pada saat yang sama.

Manfaat tambahan untuk ulasan kode (seperti yang dikomentari untuk pertanyaan ini), termasuk:

• Cara yang bagus untuk mengajar dan belajar
• Mereka adalah salah satu cara terbaik untuk meningkatkan dan menjaga konsistensi basis kode (gaya dan idiom)
• Mereka membantu memastikan semua anggota tim memahami gaya dan idiom yang digunakan dalam proyek dan bagaimana menggunakannya
• Ulasan kode akan mempercepat pengembangan karena mereka menangkap bug dan cacat desain lebih awal (jadi, meskipun mereka dapat memperlambat pengembangan awal, mereka membayar dividen dalam siklus pengembangan selanjutnya)
• Ada dukungan perkakas yang membantu merampingkan proses peninjauan kode

Ulasan kode adalah alat yang sangat berguna untuk belajar , terutama ketika Anda memiliki anggota tim baru. Yah, ini juga dikenal sebagai proses peer review :)

Ada berbagai jenis ulasan kode:

• Over-the-shoulder - di mana satu pengembang melihat dari balik pembuat kode ketika pembuat kode berjalan melalui kode.
• Pass-around email - Sistem manajemen kode sumber kode email ke pengulas secara otomatis setelah checkin dibuat. Ekstrak dari komentar: Setelah gagal meyakinkan manajemen untuk mengalokasikan waktu untuk segala jenis tinjauan kode formal, saya telah mengambil untuk melihat perubahan rekan kerja saya setiap kali saya menarik revisi baru dari kontrol sumber menggunakan alat histori / diff dibangun ke dalam Tortise
• Pair Programming - Dua penulis mengembangkan kode bersama di workstation yang sama, seperti yang umum di Extreme Programming.
• Peninjauan kode berbantu alat - Penulis dan pengulas menggunakan alat khusus yang dirancang untuk peninjauan kode rekan.

Hanya ada satu di associated disadvantagemana tinjauan kode formal memerlukan investasi yang cukup besar dalam persiapan untuk acara peninjauan dan waktu pelaksanaan.

Lebih banyak referensi tercantum di bawah ini (untuk bacaan menyelam lebih dalam)

• MSDN - Tinjauan Kode
• Temukan dan Perbaiki Kerentanan Sebelum Aplikasi Anda Dikirim
• Tautan wiki

Praktik khusus itu tampaknya tidak efisien dan mungkin memalukan - yang ingin kesalahan mereka diarahkan ke seluruh kelompok orang. Jadi, jika mereka tidak dapat memilih apa yang akan ditinjau dan kode belum diproduksi, ini mungkin membuat orang tidak nyaman.

Tergantung pada saat kode ditinjau dapat membuat perbedaan besar dalam apakah komentar ulasan kode membuatnya menjadi kode atau tidak. Jika dev dapat memilih dan memilih hanya kode produksi, komentar ulasan tidak mungkin diimplementasikan. Sangat menyenangkan untuk mengadakan pertemuan di mana pengembang dapat memamerkan beberapa teknik bagus yang mereka pelajari bahwa orang lain akan tertarik, tetapi itu bukan tinjauan kode. Itu pelatihan.

Kami melakukan peninjauan kode dari setiap bagian kode sebelum dipindahkan ke QA. Setiap bagian. Biasanya hanya melibatkan peninjau kode dan pengembang. Itu tidak pergi ke QA sampai kode resensi secara resmi melewatinya. Jadi pengembang harus melakukan perubahan. Kami telah menemukan dan dengan cepat memperbaiki banyak masalah yang mungkin tidak ditemukan oleh QA (mereka menemukan hal-hal yang tidak kami lihat dalam ulasan kode juga). Selain itu, cara ini mengurangi pengkodean koboi dan dengan cepat mengidentifikasi orang-orang yang tidak berkinerja baik sehingga kami dapat memperbaiki masalah mereka dan melatih atau menyingkirkannya sebelum mereka merusak aplikasi kita. Waktu tinjauan kode adalah bagian dari perkiraan waktu kami saat merencanakan pekerjaan sehingga tidak mempengaruhi tenggat waktu sama sekali. Dan sebenarnya, ini menghemat waktu dalam jangka panjang karena semakin awal masalah ditemukan semakin mudah untuk memperbaikinya.

Saya pribadi telah mengajarkan pengembang yang kurang berpengalaman banyak teknik yang lebih baik melalui tinjauan kode dan saya telah belajar beberapa teknik yang lebih baik dengan meninjau kode orang lain serta komentar mereka pada kode saya. Peninjauan kode lebih lanjut memastikan bahwa orang lain memahami kode yang jauh mengarah ke membuatnya lebih terpelihara. Terkadang, kodenya berfungsi tetapi pertanyaan-pertanyaan dalam tinjauan menjelaskan bahwa akan ada masalah pemeliharaan karena kodenya sulit dipahami. Lebih baik refactor dalam kasus-kasus itu sementara itu semua masih segar dalam pikiran Anda daripada setahun kemudian ketika bahkan pembuat kode dibiarkan menggaruk kepalanya dan bertanya-tanya mengapa kode melakukan ini dan itu.

Masalahnya dengan jenis review kode ini, satu pengembang setiap dua minggu, progresnya akan lambat. Bisa jadi berbulan-bulan sebelum semua orang mendapat giliran.

Meskipun ulasan kode bisa bagus, harus ada alasan di baliknya, dan di balik prosedur untuk melakukannya.

Beberapa masalah harus diputuskan:

• Siapa yang akan memilih pengembang, dan berapa banyak pemberitahuan akan diberikan. Tidak ada ulasan pemberitahuan yang merupakan jebakan.
• Siapa yang akan memilih bagian kode yang ditinjau: manajemen, pengembang senior pada proyek, atau pengembang yang ditinjau.
• Apakah tujuan untuk mengajar orang yang kode-nya ada di proyektor bagaimana melakukan sesuatu yang lebih baik, atau apakah tujuan orang yang kode-nya ada di proyektor untuk mengajar orang lain di sekitar ruangan bagaimana memperbaiki kode mereka.
• Berapa persentase kode yang akan ditinjau dengan cara ini, apakah ini akan menjadi bagian dari proses QA?

Jika orang-orang yang mengajukan rencana ini belum memiliki jawaban untuk pertanyaan-pertanyaan ini, ada kemungkinan mereka membaca sebuah artikel tentang bagaimana semua perusahaan besar melakukan review kode, jadi kita juga harus melakukannya, tanpa memahami tujuan di baliknya.

Peninjauan kode adalah praktik yang bagus, hanya ketika ide untuk tinjauan kode berasal dari tim pengembang. Pengembang tidak memerlukan proyektor dan presentasi untuk meninjau satu sama lain kode. Jika mereka mau - mereka akan lebih suka pergi ke konferensi.

Ketika ide tinjauan kode berasal dari manajemen - itu bisa terdengar seperti investigasi kualitas perangkat lunak yang rendah, dan dapat menurunkan moral tim pengembangan. Saya tidak berpikir bahwa tim manajemen harus terlibat dalam proses peninjauan kode. Peninjauan kode berdampingan dengan tim manajemen - praktik yang sangat buruk, membunuh, dan merusak.

Peninjauan kode adalah praktik yang sangat baik, terutama jika dilakukan oleh pengembang untuk berbagi pengetahuan, dan aturan dasar ditetapkan sebelumnya bahwa saran dan kritik dimaksudkan untuk KONSTRUKTIF, dan tidak menggunakan pengembang individu untuk praktik target.

Manajer yang bukan pengembang akan disambut dengan kecurigaan oleh pengembang jika mereka memutuskan untuk melakukan tinjauan kode. Sebagian besar tipe manajer tidak ingin masuk ke detail yang secara inheren masuk ke pengembang ketika melihat kode. Sebagian besar manajer juga tidak akan mengerti mengapa pengembang mengkritik satu pendekatan terhadap yang lain.

Jika Anda ingin memamerkan pekerjaan yang baik yang dilakukan pengembang ke manajemen, maka "tinjauan kode" memiliki arti yang berbeda, dan tidak boleh sedetail tinjauan kode yang dilakukan untuk menginstruksikan / meningkatkan kualitas kode di antara para pengembang. Presentasi semacam ini dapat membantu dalam menunjukkan apa yang dilakukan pengembang jika presentasi bisa lebih tinggi, dan kurang spesifik kode, dengan fokus pada apa yang dipahami oleh manajer (nilai, ROI, dll.). Mungkin membuat manajer mengerti bahwa Joe telah menambah nilai signifikan bagi perusahaan dengan membangun X, yang dapat kami tunjukkan menghemat jumlah waktu Y, atau Z dolar per pesanan, dll. Saya pikir itu mungkin sepadan dengan usaha dalam menunjukkan nilai individu anggota tim Anda. Ingat, bagaimanapun, bahwa Anda harus berhati-hati agar Anda tidak membanjiri audiens Anda dengan jargon, atau terlalu banyak level detail.

Sementara saya sepenuhnya setuju bahwa tinjauan kode sangat konstruktif untuk pengajaran yang ingin saya tekankan, bagi saya bagaimanapun, itu adalah untuk memastikan bahwa pola desain tim diikuti dengan benar.

Kami menulis karya prototipe kecil dan kami memperbaiki bit kode dan sementara kami merasa nyaman dengan produk pada akhirnya keterbacaan telah rusak - orang tidak dapat melihatnya dan melihat dengan jelas apa yang terjadi.

Mata independen selalu bermanfaat, saya temukan ketika Anda terjebak dalam mode pemikiran tertentu dan ini ada di semua tingkat pengalaman. Anda menginvestasikan berjam-jam ke dalam desain dan kode sehingga ulasan kode sulit untuk ditangani ketika ada rasa takut upaya Anda akan dibuang. Namun pada akhirnya Anda, semoga, berakhir dengan aplikasi yang lebih bersih, lebih ramping, dan lebih mudah dikelola dan pengalaman itu sudah tertanam dalam diri Anda.

Untuk tim kami, kami melakukan seperti yang disebutkan @ElYusubov dan menggunakan alat khusus untuk Peninjauan Kode - Crucible. Orang-orang meninjau, mengomentari, dan menandatangani kode. Setiap minggu kami duduk dan mengulas potongan kode yang menarik dan / atau kompleks.

Sebagai seorang magang rekayasa perangkat lunak, saya telah menemukan ulasan kode sangat membantu.

Di tim saya, peninjauan kode diperlukan untuk setiap komit (perubahan besar akhirnya menjadi formal, perubahan kecil akhirnya menjadi 'penampilan cepat'). Saya benar-benar merasa seolah-olah potongan-potongan teknik / desain saya telah didorong oleh ini, terutama karena saya lebih mungkin untuk mengeluarkan papan tulis daripada terminal segera karena saya tahu saya sedang 'diawasi.' :)

Akibatnya, saya pikir itu menghasilkan kode yang jauh lebih baik dengan kelemahan hanya sedikit waktu pengembangan yang sedikit lebih lambat (yang menurut saya, sepadan dalam jangka panjang ketika Anda tidak harus memperbaiki / memperpanjang kode yang dirancang sangat). Juga, saya pikir jika Anda memiliki junior / peserta magang di tim mereka akan menghargai kesempatan untuk umpan balik yang berharga. Saya tahu saya lakukan!

Dari pengalaman saya, Ulasan Kode adalah hal yang sangat bagus jika Anda melakukannya dengan baik. Ketika Anda memiliki anggota tim dan manajer yang profesional / matang. Kita sebagai programmer adalah "solusi solver". Tugas kita bukanlah menciptakan garis "teks". Itu sebabnya kami harus berbagi ide, kesalahan, masalah, pengalaman. Tinjauan kode benar-benar praktik yang baik untuk mencapai ini.

Sayangnya kedengarannya hebat tetapi sangat sulit untuk diterapkan di sebagian besar perusahaan. Tim Anda membutuhkan banyak "otonomi". Meyakinkan manajer atau departemen keuangan Anda bahwa tidak menciptakan fitur baru itu menguntungkan tampaknya sulit.

Di perusahaan saya, kami mencoba melakukan beberapa tinjauan kode. Tetapi terlalu banyak waktu dihabiskan dengan 'mengejar kelinci' (membuat fitur).

Banyak jenis dan jenis sintaksis dasar pemeriksaan tertangkap menggunakan alat hari ini (FXCop dll).

Namun, tinjauan kode baik, terutama dengan anggota baru tim, hal-hal yang kompleks atau berdampak tinggi (misalnya sesuatu yang akan terlihat oleh orang-orang penting jika gagal atau menyebabkan dampak bisnis) dan terutama ketika melakukan outsourcing atau menggunakan kontraktor jangka pendek (terutama sekali lagi ketika mereka bukan penutur asli karena kesalahan terjemahan / masalah bahasa dapat memungkinkan perangkat lunak untuk lulus semua tes tetapi tidak benar-benar melakukan apa yang seharusnya).

Saya bukan penggemar menempatkan kode pada proyektor untuk tim untuk mengambil melalui - jauh lebih baik untuk memiliki pertemuan tinjauan kode di mana anggota tim lain (pemimpin tim dll) melewati daftar dengan dev. Ini berdampak lebih sedikit pada orang - menghentikan banyak waktu yang terbuang untuk argumen gaya - dan tidak terlalu memalukan bagi dev. Itu lebih konstruktif dan lebih mudah bagi dev untuk menyerap masalah nyata dan tidak dibutakan oleh semacam komentar "Saya akan melakukan ini ...".

Saya juga berpikir bahwa ulasan kode yang tidak dipaksakan - seperti menempatkan kode di bagian atau mengirim email dengan harapan seseorang memberikan waktu makan siang mereka untuk melewatinya - adalah buang-buang waktu.

Duduk dengan tumpukan daftar, spidol dan secangkir kopi di area kopi sangat bagus untuk ini.

Kelompok semacam ini menunjukkan dan memberi tahu akan baik untuk teknologi baru atau untuk mendapatkan beberapa jr. devs hingga kecepatan, tapi saya tidak berpikir itu sebagus review yang konsisten dari kode baru. Lebih efisien jika harus melakukannya sendiri.

Ulasan kode membantu melihat "keseluruhan". Pengembang yang terpisah memiliki kecenderungan untuk melihat hanya persyaratan / masalah mereka. CR menemukan ide dan solusi dari seluruh perspektif. CR terutama membantu menghilangkan pemborosan dari pekerjaan yang tidak perlu. Seluruh produk lebih murah dan berkualitas lebih baik.