Mendapatkan SEMUA pengembang melakukan ulasan kode

13

Saya seorang pengembang perangkat lunak dalam tim pengembang 7-8. Kami telah melakukan tinjauan kode untuk beberapa waktu sekarang dan kualitas kode telah meningkat dari waktu ke waktu.

Namun saya baru-baru ini memperhatikan bahwa beberapa pengembang diminta untuk lebih banyak ulasan kode daripada yang lain. Saya khawatir itu karena sikap mereka yang fleksibel.

Dalam pandangan saya, ini bukan bagaimana review kode harus dilakukan: semua tim harus bertanggung jawab untuk itu dan pengulas kode tidak boleh dipilih karena kesediaan mereka untuk dengan mudah menerima perubahan.

Bagaimana Anda menangani masalah ini di tim Anda?

Sudahkah Anda menetapkan aturan untuk memilih peninjau kode?

Apakah menurut Anda peninjau kode harus diberi imbalan atas waktu yang mereka habiskan untuk melakukan tinjauan kode (baik)? Dan bagaimana mereka harus diberi imbalan?

Terima kasih atas jawaban / ide Anda.

code-quality code-reviews software-craftsmanship

— guillaumegallois
sumber

7

Sudahkah Anda mempertimbangkan untuk membuat sistem round robin di mana kedua pembuat kode dibiarkan dalam kegelapan tentang siapa yang meninjau dan pengkaji dibiarkan dalam kegelapan tentang siapa yang merupakan pembuat kode?

— Neil

1

Saya belum, tapi saya suka ide ini! Terima kasih!

— guillaumegallois

1

Siapa yang bertanggung jawab dan mengapa mereka tidak melakukan pekerjaan mereka yang seharusnya memastikan semua orang melakukannya?

— JeffO

Di tim saya, pengulas secara otomatis ditetapkan setiap kali permintaan tarik dibuka. Peninjau dipilih dari round-robin tim. Kami memiliki webhook untuk masing-masing repo kami yang menetapkan pengulas secara otomatis setiap kali PR dibuka. Itu pada dasarnya menyimpan daftar semua devs, dan siapa yang terakhir ditugaskan, dan hanya bekerja jalan melalui daftar.

— Dan Jones

12

Kami tidak memilih pengulas.

Di tim kami:

Semua perubahan kode harus ditinjau kode sebelum Permintaan Tarik selesai
Setidaknya satu pengembang harus meninjau kode (dua pengulas lebih atau lebih baik dan memiliki penguji, analis, dan anggota tim lainnya yang melakukan tinjauan kode juga sangat bermanfaat)

Ulasan Kode tidak ditugaskan, orang-orang mengambilnya ketika berfungsi untuk mereka. Pemahamannya adalah bahwa kita tidak bisa mendorong cerita melalui pipa. Kadang-kadang seseorang akan menyebutkan bahwa mereka sedang menunggu CR di standup tapi itu saja.

Saya suka model ini, itu memberi orang untuk mengambil apa yang mereka bisa dan menghindari "memberi orang pekerjaan".

— Liath
sumber

6

Tetapkan aturan bahwa bug dapat ditugaskan untuk memperbaikinya, tidak hanya untuk mereka yang melakukan perubahan, tetapi hanya untuk mereka yang meninjaunya. Itu harus menciptakan perspektif yang benar untuk ulasan kode.

Untuk

Apakah menurut Anda peninjau kode harus diberi imbalan atas waktu yang mereka habiskan untuk melakukan tinjauan kode (baik)?

Yah saya tidak yakin bagaimana umumnya pengembang dihargai untuk melakukan pekerjaan mereka kecuali hanya mendapatkan gaji dan menjadi bangga dengan apa yang telah mereka lakukan. Tetapi karena kode peninjauan adalah bagian dari pekerjaan mereka, peninjau harus mendapatkan waktu untuk peninjauan, dan berbagi kredit entah bagaimana.

— max630
sumber

2

Itu ide yang menarik, tetapi sering kali bug muncul, 90% pekerjaannya mencari tahu persis apa yang menyebabkan bug, dan 10% pekerjaan memperbaikinya. Melakukan post-mortem untuk mengetahui dengan tepat perubahan apa yang menyebabkan bug tidak terjadi, kecuali itu membantu mencari tahu apa yang terjadi, atau bagaimana melakukan perbaikan yang aman.

— DaveG

Anda membuat poin bagus tentang kredit yang harus diberikan oleh pengulas kode. Ini jelas merupakan masalah yang harus ditangani. Terima kasih atas jawaban anda!

— guillaumegallois

Saya pikir itu mungkin membuat orang mencoba untuk tidak melakukan review kode sama sekali atau mungkin Anda tidak akan memiliki pekerjaan yang dilakukan karena orang akan mulai melakukan nitpicking.

— Mateusz

5

Jawaban ini mengasumsikan tujuan ulasan kode adalah untuk menemukan bug. Bukan itu masalahnya, tujuan utamanya adalah untuk menjaga kode dalam keadaan dapat dipertahankan dan dikembangkan (dan jika Anda beruntung, beberapa bug juga ditemukan).

— Doc Brown

@DocBrown untuk mencegah bug dan juga untuk memastikan perbaikan bug di masa depan akan lebih cepat (baik dengan membiasakan pengembang lain dengan kode dan dengan memastikan kode tersebut ditulis dengan baik)

— max630

4

Masalah utama yang Anda miliki bukan teknis, tetapi beberapa alat dapat menurunkan jumlah upaya yang dilakukan tinjauan kode. Ada beberapa tantangan yang harus diatasi:

Memahami apa perubahan itu. Permintaan Tarik Git pada cabang fitur sangat membantu proses ini.
Membuat kode meninjau acara di mana orang harus berada di ruangan yang sama. Ini menambah tekanan penjadwalan, sumber pertemuan, dll. GitHub, GitLab, dan BitBucket memungkinkan ulasan asinkron sehingga dapat terjadi ketika rekan siap.
Kemampuan untuk memberikan umpan balik yang berarti ketika melihat kode. Sejujurnya, fitur komentar baris demi baris di GitHub, GitLab, permintaan tarik Bitbucket benar-benar lebih berguna daripada pertemuan tatap muka. Rasanya kurang politis.

Itu bukan untuk mengatakan bahwa Anda tidak dapat menggunakan SubVersion atau alat lain (seperti Fisheye) untuk membantu, tetapi integrasi yang dibangun ke dalam pipa Git dengan cabang-cabang fitur benar-benar membuat pekerjaan kurang dari tugas.

Di luar tooling, Anda perlu melihat lebih banyak tantangan sosial:

Mintalah pengembang Anda memulai hari mereka dengan meninjau setiap permintaan tarik terbuka untuk menandatanganinya.
Mintalah pengembang Anda meninjau permintaan tarik terbuka apa pun sebelum mereka memulai tugas baru
Membutuhkan persetujuan dari lebih dari satu orang untuk permintaan tarik Anda.

Mungkin juga layak memeriksa jenis tugas apa yang sedang ditinjau kode oleh orang yang lebih terlibat. Mereka mungkin meraih semua ulasan mudah, yang membuat segalanya lebih menyakitkan bagi semua orang.

— Berin Loritsch
sumber

Poin terakhir bagus. Saya pernah bekerja dengan pengembang di tim kecil yang hanya akan meninjau perubahan pada perangkat lunak yang ia tulis yang menyebabkan kemacetan yang signifikan di tempat lain dalam tim.

— Robbie Dee

Dalam hal itu, sepertinya Anda memiliki seseorang yang mencoba melindungi "wilayah" mereka. Sebisa mungkin, Anda ingin menumbuhkan rasa memiliki masyarakat terhadap kode tersebut. Dengan kata lain, tidak ada sanctum yang dilindungi dalam kode yang tidak dapat disentuh pengembang lain kecuali yang "diberkati". Saya mengerti jika ada celah khusus dan Anda tidak dapat meninjau matematika, tetapi Anda setidaknya dapat meninjau seberapa baik kode cocok dengan niatnya.

— Berin Loritsch

2

Ide yang bagus adalah melakukannya berdasarkan sistem round robin - Anda memilih seseorang yang telah melakukan paling sedikit ulasan untuk kode Anda. Seiring waktu, setiap orang dalam tim seharusnya melakukan kurang lebih jumlah ulasan yang sama. Ini menyebarkan pengetahuan juga.

Tentunya akan ada pengecualian sesekali seperti liburan di mana akan ada puncak dan palung.

Seharusnya tidak ada perbedaan antara junior dan senior / lead. Ulasan kode harus dilakukan untuk kode semua orang - tidak peduli seberapa senior mereka. Ini mengurangi gesekan dan membantu berbagi pendekatan yang berbeda.

Jika Anda masih khawatir tentang kualitas ulasan setelah semua ini, pertimbangkan untuk memperkenalkan serangkaian standar minimum untuk lulus ulasan kode. Apa yang Anda sertakan sepenuhnya terserah Anda, tetapi beberapa hal yang mungkin ingin Anda pertimbangkan adalah cakupan kode, unit test, menghapus kode yang dikomentari, metrik, komentar yang cukup, membangun kualitas, prinsip SOLID, KERING, CIUMAN dll.

Adapun insentif ulasan kode, kode kualitas adalah hadiah. Kita semua saya yakin bekerja pada basis kode sub-optimal di mana rasa sakitnya dapat dikurangi secara signifikan seandainya pengembang lain baru saja memberikan kode sekali dari awal dan menyarankan perubahan konstruktif.

— Robbie Dee
sumber

0

Sepertinya tim tidak memiliki proses formal untuk tinjauan kode.

Saya tidak berbicara tentang membuat dokumen Word setebal 350 halaman, tetapi hanya beberapa poin sederhana tentang apa yang diperlukan prosesnya.

Bit penting:

Tentukan satu set inti dari pengulas. Tidak ada pernyataan umum. Sebutkan nama orang.

Ini harus menjadi pengembang senior Anda.
Diperlukan lebih dari 1 reviewer inti untuk menandatangani ulasan.
Identifikasi setidaknya 1 reviewer non inti lainnya setiap sprint atau rilis yang merupakan reviewer inti sementara. Mengharuskan mereka keluar dari semua ulasan kode selama waktu ini.

Butir # 3 memungkinkan pengembang lain untuk memutar ke kelompok resensi inti. Beberapa minggu mereka akan menghabiskan lebih banyak waktu untuk ulasan daripada yang lain. Itu adalah tindakan penyeimbangan.

Adapun orang yang memberi penghargaan? Berkali-kali mengakui upaya yang dilakukan seseorang selama peninjauan kode di depan seluruh tim dapat berhasil, tetapi jangan terlalu memaksakan diri untuk hal ini.

Jika ragu, tentukan prosesnya dan beri tahu tim bahwa mereka harus menaatinya.

Dan ada satu hal terakhir yang dapat Anda coba - mungkin kontroversial: biarkan @ # $% mengenai penggemar, jika saya dapat menggunakan idiom.

Biarkan tim gagal, karena proses peninjauan kode tidak diikuti. Manajemen akan terlibat, dan kemudian orang akan berubah. Ini benar-benar hanya ide yang bagus dalam kasus-kasus paling ekstrem di mana Anda telah mendefinisikan suatu proses dan tim menolak untuk mematuhinya. Jika Anda tidak memiliki wewenang untuk memecat orang atau mendisiplinkan mereka (karena kebanyakan pengembang utama tidak ) maka Anda perlu melibatkan seseorang yang dapat melakukan hal ini.

Dan tidak ada yang gagal untuk mengubah keadaan. Terlepas dari apa yang orang katakan, Anda dapat mengarahkan Titanic - tetapi tidak sebelum menghantam es es.

Terkadang Anda hanya perlu membiarkan Titanic menghantam burg ice.

— Greg Burghardt
sumber