Bagaimana cara memonitor review kode secara efisien?


28

Saya menduga ulasan kode utama ditutup-tutupi di tim saya. Terlalu banyak ulasan kode digabungkan tanpa komentar.

Menurut saya sepertinya tidak ada tinjauan kode tanpa satu komentar.

Bagaimana saya sebagai pemimpin tim dapat memonitor dengan baik bahwa tim saya sedang melakukan proses peninjauan kode yang tepat dan bagaimana saya dapat membantu mereka untuk memaksimalkan manfaat proses?

Memperbarui

Orang yang berpikir mungkin ingin tahu tentang pembaruan apa pun. Saya mencoba banyak saran yang diberikan di sini. sebagian besar sudah digunakan. beberapa membantu sedikit. Namun, masalahnya tetap ada - beberapa orang terus menerus mendapatkan kode yang buruk ketika saya tidak melihat.

Saya menemukan bahwa pemantauan tinjauan kode tidak membantu seperti memberikan alat tim saya untuk membuat kode mereka lebih baik.

Jadi saya menambahkan perpustakaan bernama "jscpd" untuk mendeteksi copy paste. Bangunan gagal pada pasta salinan. Itu menghilangkan satu masalah dengan segera.

selanjutnya kita akan mencoba codeclimate.

Saya juga melakukan tinjauan manual pada ulasan kode lama sekali berlari selama setengah hari. Saya mengkonversi todomenjadi isu / tiket - karena saya tahu orang-orang menulisnya, tetapi mereka tidak pernah ditangani di kemudian hari. Saya juga melakukan pertemuan dengan seluruh tim untuk meninjau kode bila perlu.

secara umum rasanya seperti kita bergerak ke arah yang benar.


1
Jika Anda menggunakan TFS, Anda dapat mengonfigurasinya untuk memasukkan Nama Peninjau Kode.
Krishnandu Sarkar


11
@gnat saya tidak setuju. Ada perbedaan antara seseorang yang tidak menyukai ulasan kode dan apa yang ditanyakan oleh pertanyaan ini. Pertanyaan ini dapat diserang dari perspektif keterlacakan (menghubungkan perubahan dalam kode sumber dengan ulasan, atau cacat / peningkatan / cerita dengan ulasan implementasi itu, dll) atau dari kualitas proses dan perspektif audit. Keduanya memiliki implikasi, bahkan jika orang umumnya tidak memiliki masalah melakukan tinjauan kode.
Thomas Owens

3
Apakah Anda menghadiri ulasan ini? Mungkin sudah waktunya untuk memilih satu? Tunjukkan beberapa hal sendiri & tanyakan kepada setiap pengulas secara terpisah mengapa dia melewatkan semuanya?
Mawg

2
Apakah Anda menemukan bahwa masalah yang jelas belum terlihat oleh ulasan? Apakah Anda telah menambahkan komentar (penting)?
usr

Jawaban:


70

Saya akan menawarkan pandangan berbeda dari sesama penjawab saya. Mereka benar - terlibatlah jika Anda ingin melihat bagaimana keadaan. Jika Anda ingin lebih mudah ditelusuri, ada alat untuk itu.

Tetapi dalam pengalaman saya, saya curiga ada sesuatu yang terjadi.

Sudahkah Anda menganggap bahwa tim Anda mungkin merasa bahwa prosesnya rusak / bodoh / tidak efektif untuk sebagian besar komitmen? Ingat, proses mendokumentasikan apa yang berfungsi dengan baik, bukan aturan untuk dipatuhi . Dan sebagai pemimpin tim, Anda berada di sana untuk membantu mereka menjadi yang terbaik, bukan menegakkan aturan.

Jadi dalam retrospektif Anda (jika gesit) atau satu-satunya (jika Anda seorang manajer) atau dalam pertemuan lorong dadakan acak (jika Anda adalah seorang pemimpin tim yang tidak gesit dan ada manajer lain yang mengerjakannya sendiri), bawalah. . Tanyakan pendapat orang tentang proses peninjauan kode. Bagaimana cara kerjanya? Bagaimana tidak? Katakan Anda pikir itu mungkin tidak menguntungkan tim sebanyak mungkin. Pastikan kamu mendengarkan .

Anda dapat melakukan advokasi untuk tinjauan kode dalam pertemuan ini, tetapi lebih baik mendengarkan umpan baliknya. Kemungkinan besar, Anda akan menemukan bahwa tim Anda berpikir bahwa proses "yang tepat" perlu disesuaikan, atau bahwa ada beberapa penyebab utama (tekanan waktu, kurangnya pengulas, Bob hanya melakukan kode-nya jadi mengapa kita tidak bisa) menangani .

Memaksa alat di atas proses yang rusak tidak akan membuat proses lebih baik.


5
+1 untuk pendekatan yang tepat untuk masalah ini (dan banyak lainnya!)
Olivier Dulac

7
+1 untuk kalimat terakhir. Ini adalah sesuatu yang hampir tidak ada yang mengerti, tetapi sangat penting.
JohnEye

1
Jawaban bagus. Mencoba itu .. Tim saya mengatakan "perusahaan melakukan hal-hal dengan cara yang salah. Kami membutuhkan lebih banyak qa .. dan biarkan pengembang mengembangkan" sementara perusahaan mengatakan "kami ingin pengembang mengirimkan kode kualitas yang baik. Kami bertujuan untuk membubarkan tim qa karena begitu kode dalam kualitas yang baik, qa tidak lagi diperlukan .. "... Apa yang terjadi akhirnya adalah orang-orang yang mendapat kode buruk terus-menerus dipecat dan saya merekonstruksi tim saya.
guy mograbi

43

Saya tidak suka memposting jawaban satu baris, tetapi yang ini sepertinya tepat:

Berpartisipasilah dalam proses ini.


15
Saya juga tidak suka satu baris jawaban. Untungnya Anda mengambil dua baris - dan jawaban saya. +1
Mawg

1
Saya. tetapi ketika saya tidak .. hal-hal terjadi. itulah yang membuatku curiga. Saya mulai meninjau ulang ulasan orang lain, dan menemukan hal-hal buruk.
guy mograbi

6

Dapatkan alat, seperti ReviewBoard atau plugin Redmine's codereview . Kemudian setiap ulasan dibuat sebagai tugas yang harus ditutup atau dikomentari oleh seseorang (seperti tiket bug). Kemudian Anda dapat dilacak dari siapa yang membuat tiket ulasan, dan siapa yang menutupnya. Anda dapat mengikat tiket ulasan dengan checkin kode sumber, yaitu membuat tiket dari revisi.


2

Beberapa hal (sejujurnya, sebagian besar dibahas di seluruh jawaban, tapi saya ingin menempatkannya di satu tempat)

  • Anda bisa menerapkan proses dan aturan untuk memastikan review kode terjadi, tetapi sangat tidak mungkin untuk memasukkannya sehingga review kode sebenarnya lebih dari sekadar latihan mencentang kotak. Pada akhirnya tim harus melihat manfaat dari proses tersebut, jika mereka ingin mendekatinya dengan berguna

  • Menurut contoh. Ambil bagian dalam ulasan. Sebagai seorang pengembang, saya merasa sedih jika manajer saya (yang bukan pengembang sekarang) melihat hal-hal yang tidak saya lakukan. Sorot masalah yang seharusnya tertangkap dalam tinjauan (dengan cara yang tidak menyalahkan). Jika masalah produksi terjadi, jika masalah muncul selama QA (jika Anda memiliki proses QA terpisah), sorot di mana mereka bisa ditangkap dalam tinjauan kode. Diskusikan dengan tim bagaimana kita bisa memastikan masalah di masa depan seperti itu tertangkap

  • Diskusikan dengan tim apa yang mereka ingin proses lakukan. Jika mereka tidak melihat titik untuk itu (seperti yang mungkin terjadi di awal) gunakan masalah produksi dan refix yang diperlukan sebagai bukti manfaatnya

  • Gunakan perangkat lunak pengecekan kode otomatis seperti Sonarqube sehingga ulasan kode dapat fokus pada masalah seperti kode yang tidak dapat dipahami, kesalahan logika, kurangnya dokumentasi, dll yang tidak dapat dilihat secara otomatis.


2

Anda dapat mendokumentasikan apa yang diinginkan tim dalam ulasan kode yang telah Anda diskusikan dan sepakati bersama pengembang. Beberapa hal yang dapat Anda pertimbangkan sebagai bagian dari tinjauan kode adalah:

  • Pastikan kode melakukan apa yang seharusnya dilakukan yaitu memenuhi persyaratan

  • Gaya kode untuk memastikan bahwa pengembang mengkode ke gaya yang konsisten

  • Optimasi misalnya jumlah panggilan fungsi

  • Arsitektur dan penggunaan kembali

  • Penanganan dan penebangan pengecualian

  • Utang teknis: adalah kode dalam kondisi yang lebih baik daripada saat pengembang mulai mengerjakannya

  • Lihat dan buat kodenya (saya menemukan ini berguna tetapi pengembang lain di tim saya lebih suka menyerahkan ini kepada penguji)

  • Menggunakan alat otomatis (Saya sudah menggunakan SonarQube ). Saya merasa berguna untuk mengintegrasikan ini ke dalam proses pembuatan Anda untuk menegakkan perbaikan pada kode misalnya meningkatkan cakupan pengujian

Beberapa langkah di atas dapat dicakup oleh alat otomatis, tetapi saat Anda mencoba meningkatkan ulasan kode cara atau melakukannya mungkin layak menggunakan kedua alat dan tinjauan bola mata. Namun, langkah paling penting untuk mencegah utang teknis (arsitektur dan penggunaan kembali) tidak dapat sepenuhnya otomatis.

Jika tim Anda tidak konsisten dalam menerapkan ini, Anda bisa mencoba hanya mengizinkan pengembang yang melakukan tinjauan kode dengan benar untuk memiliki hak penggabungan. Misalnya, Anda mungkin hanya ingin memulai dengan pemimpin tim. Pertukaran dengan pendekatan ini adalah bahwa para pengembang tersebut dapat menjadi penghambat dalam proses pengembangan, sehingga Anda dan tim perlu memutuskan apakah Anda menginginkannya. Secara pribadi saya akan menerima pertukaran ini dan melalui ulasan kode meningkatkan disiplin di seluruh tim dan kemudian ketika siap Anda dapat meningkatkan jumlah pengembang dengan hak penggabungan.

Akhirnya, ada baiknya meninjau ulasan. Jadi seminggu sekali berkumpul dengan para pengembang dan secara konstruktif membahas ulasan dan cara untuk memperbaikinya.


apakah ini sebuah iklan untuk SonarQube? Saya mencobanya - saya tidak akan merekomendasikannya, terlalu menyakitkan untuk digunakan dan sementara biaya "open source" untuk semua bit yang berguna.
gbjbaanb

Ini berjalan dengan baik di tim saya saat ini dan tidak terlalu sulit untuk diatur dan itu membantu - ini bukan iklan tapi itu satu-satunya alat semacam ini yang saya punya pengalaman. Apakah Anda akan mengatakan hal yang sama untuk Redmine codereview dan ReviewBoard?
br3w5

Kami menggunakan SonarQube di tim kami, melayani sekitar 70+ proyek, mulai dari 10k hingga 3M LOC. Meskipun beberapa tim mengabaikan laporannya, sebagian besar menggunakannya untuk mengarahkan proses refactoring. Ini berfungsi dengan baik, meskipun secara pribadi saya lebih suka alat yang sederhana dan tidak terintegrasi, seperti Findbugs.
Dibbeke

Dan di sini saya berpikir bahwa tinjauan kode melibatkan memeriksa apakah kode tersebut cocok dengan dokumen desain: - /
Mawg

1
Terima kasih, inilah yang sedang saya lakukan saat ini. Saya akan memperbarui dalam beberapa minggu bagaimana pengaruhnya.
guy mograbi

0

Saya akan memberi tahu Anda bagaimana tim saya dengan cepat mengintegrasikan tinjauan kode ke dalam alur kerjanya.

Pertama, izinkan saya mengajukan pertanyaan kepada Anda. Apakah Anda menggunakan sistem kontrol versi (mis. Mercurial, Git)?

Jika jawaban Anda adalah ya, maka lanjutkan.

  1. melarang semua orang mendorong sesuatu (bahkan perbaikan kecil) langsung ke cabang master (trunk) *
  2. mengembangkan fitur baru (atau perbaikan) di cabang yang terpisah
  3. ketika pengembang percaya bahwa cabang siap untuk diintegrasikan dalam master, mereka akan membuat "permintaan tarik"
  4. melarang semua orang menggabungkan permintaan tarik mereka sendiri *
  5. minta pengembang lain mengevaluasi permintaan tarik dan meninjau kode baru
  6. jika kode lolos ulasan, bagus, permintaan tarik dapat digabungkan, jika tidak perbaikan dapat diterapkan
  7. ulangi langkah 6 hingga kode cukup matang (dapat dilakukan tanpa memulai kembali) **
  8. selesai, semua kode baru Anda ditinjau (setidaknya secara ringkas), oleh seseorang dengan nama

Sekarang Anda memiliki titik yang tepat dalam alur kerja Anda di mana peninjauan kode dilakukan.

Bertindak di sana.

* dapat diberlakukan secara otomatis, dengan kait sisi server

** prosedur ini didukung sepenuhnya oleh GitHub (antara lain), dan cukup mudah digunakan, periksa saja


2
Bahkan dengan proses seperti itu (yang seharusnya saya benar-benar terjadi dari uraian dalam pertanyaan), Anda kadang-kadang membuat pengembang berpikir "ah, saya cukup memercayai kolega saya dan memiliki terlalu banyak hal untuk dilakukan sendiri, jadi saya hanya akan menggabungkannya tanpa benar-benar membaca detail, atau bahkan mengomentarinya ". (Kami memiliki proses serupa di tim kami, dengan dua persetujuan yang diperlukan (dari orang-orang selain penulis PR), sebelum dapat digabung. Kadang-kadang perubahan dapat dilalui tanpa peninjauan menyeluruh.)
Paŭlo Ebermann

1
@ PaŭloEbermann, begitu. Saya khawatir itu adalah hasil dari keadaan yang tak terhindarkan, jika Anda tidak memiliki cukup waktu untuk melakukan semua yang Anda butuhkan, kualitas akan menurun, dengan satu atau lain cara. Sill, jika tidak bekerja "kadang-kadang", itu berarti ia bekerja "sebagian besar waktu", bukan?
Agostino

1
Ya, itu sedikit membantu dengan memungkinkan penggabungan hanya untuk sekelompok orang terbatas, yang memiliki tugas untuk memeriksa apakah tinjauan yang sebenarnya dilakukan dengan benar.
Paŭlo Ebermann

Saya memiliki larangan serupa, dan tidak perlu dikatakan: perkembangannya hampir berhenti. Aturan itu berlangsung 2 minggu penuh, setelah itu manajer harus menyesuaikan rencana mereka.
BЈовић

@ BЈовић apakah tim Anda melakukan tinjauan kode secara teratur sebelumnya ? Teknik ini digunakan oleh banyak orang, terutama di ekosistem Open Source. Fakta bahwa itu tidak berhasil untuk tim Anda tidak berarti jika tidak bisa bekerja untuk orang lain.
Agostino

-2

Saya pikir Anda harus membuat template dan meminta anggota tim Anda untuk memperbaruinya setiap kali mereka melakukan review kode. Tetapi meskipun begitu, Anda harus berpartisipasi dalam proses peninjauan pada awalnya.

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.