Waktu yang dialokasikan untuk ulasan kode


14

Jika Anda melakukan tinjauan kode

  • Berapa banyak waktu yang Anda habiskan untuk review kode, dibandingkan dengan implementasi?
  • Berapa banyak perubahan yang menjalani tinjauan kode?
  • Anda pikir itu terlalu / harus lebih?

Apakah ada studi tentang efektivitas?

Terima kasih atas jawabannya, sulit untuk memilih "pemenang" untuk pertanyaan seperti itu, ada banyak info berharga di balasan lain juga.


2
Jawaban saya untuk ketiga pertanyaan itu adalah "tidak ada", "tidak satu pun dari mereka" dan "itu harus lebih." :-)
Carson63000

4
Pertanyaan bagus, saya sedang dalam proses memulai perang salib pribadi untuk memperkenalkan ulasan kode pada pekerjaan saya. Jadi jawaban untuk ini bisa membantu.
Kevin D

Pertanyaan berikutnya adalah "Mengapa" - Sebagian besar berpikir tentang kualitas, tetapi keuntungan besar datang ketika Anda memahami nilai pendidikan kode melebihi nilai kualitas.
mattnz

Jawaban:


7

Di pekerjaan saya, kami memiliki prosedur berikut untuk ulasan kode. Sejauh ini, ini telah bekerja dengan baik untuk kami, dan kami menemukannya sangat efisien waktu, terutama dalam hal jam kerja. Kami tidak benar-benar memiliki waktu khusus yang dialokasikan untuk ulasan. Setiap komit atau penggabungan ke trunk harus ditinjau, dan dibutuhkan selama yang dibutuhkan resensi untuk memperbaikinya.

Sunting: Waktu yang dibutuhkan, tentu saja, tergantung pada besarnya perubahan. Fitur kecil dan perbaikan bug membutuhkan waktu beberapa menit. Fitur besar baru, perbaikan, atau perubahan yang mempengaruhi banyak bagian dari sistem dapat memakan waktu setengah hari untuk meninjau dan hari lain untuk mengatasi semua masalah yang muncul sebagai hasilnya.

Untuk membuat sistem ini berfungsi, penting untuk sering mengkomit ke trunk, sehingga perubahannya bisa diatur. Anda tidak ingin memiliki situasi ketika Anda harus meninjau kode seseorang selama setahun.


1
Apakah Anda tahu berapa banyak yang dibutuhkan?
peterchen

5

Berkenaan dengan studi, perangkat lunak Smart Bear akan mengirimkan kepada Anda sebuah buku kecil, Best Kept Secrets of Peer Code Review , gratis. Ini memiliki sejumlah artikel di dalamnya tentang berbagai aspek tinjauan kode, termasuk studi tentang berapa lama mereka harus mengambil dan seberapa efektif mereka.


Saya baru saja memesan buku ini. Semoga semoga menjadi bacaan yang menarik.
Kevin D

3
Memesannya juga. Sungguh aneh menunggu 20 hari untuk mendapatkan buku " gratis " - dari perusahaan yang menjual perangkat lunak melalui internet, tidak kurang.
peterchen

Buku itu telah melakukan putaran di tempat kerja saya selama beberapa tahun. Salinan kami dibaca dengan baik dan diikuti dengan beberapa poin kunci penandaan postit. Ini kecil (Dapat membacanya dalam satu jam) tetapi dikemas dengan informasi yang bagus. Tujuan yang jelas adalah meyakinkan Anda untuk melakukan review kode, lalu meyakinkan Anda untuk menggunakan alat, lalu meyakinkan Anda untuk membeli alat mereka - cukup adil, mereka memberi Anda buku itu.
mattnz

4

Dalam proyek kami, setiap perubahan signifikan pada sistem ditinjau oleh pemimpin tim atau bersama dengan pengembang lain yang akan menjadi "konsumen" utama dari modul baru. Kami berbicara tentang skype dan menggunakan Rudel di Emacs (sebuah plugin untuk mengedit kolaboratif, pada dasarnya memungkinkan beberapa pengguna untuk mengedit file yang sama secara langsung), atau TypeWith.me (Piratepad), atau salah satu dari kami berbagi layarnya dalam skype.

Sulit untuk mengukur ini, karena perubahan biasa, seperti tampilan baru, halaman, dll. Tidak ditinjau. Kami meninjau modul baru, pembaruan besar dan refactoring. Sedangkan untuk perubahan besar, tinjauan kode bisa memakan waktu dari 10% hingga 30% dari waktu, tetapi itu sepadan.

Saya dapat mengatakan berpasangan pemrograman, ketika 2 programmer melakukan mengedit file yang sama pada saat yang sama, tidak hanya duduk di komputer yang sama, jauh lebih baik daripada praktik kantor yang biasa duduk di belakang bahu seseorang.

Untuk hal-hal sederhana seperti konvensi penamaan dan kesalahan cakupan, kami menggunakan alat otomatis milik kami sendiri atau open source (jslint, pylint, pyflakes, pep8). Dan kami tidak membatasi komitmen dan dorongan: kami menggunakan Mercurial yang memiliki percabangan dan penggabungan yang sangat mudah (harus saya katakan, lebih mudah daripada di Git). Bug bukan masalah ulasan kode.

Kami melakukan pertemuan tim di mana perubahan dan hal-hal baru diumumkan, tetapi di sana, tidak semua orang benar-benar memperhatikan. Mungkin kita harus melakukan sedikit review kode.


2

Tidak ada jawaban benar atau salah untuk ini. Tetapi seperti yang banyak disarankan oleh saya sebelumnya - jika peninjauan kode dilakukan oleh anggota tim eksternal [metode yang sangat direkomendasikan] mungkin jumlahnya mencapai sekitar 30% hingga 35% dari upaya pengembangan. Tetapi jika ini dilakukan oleh anggota tim proyek internal yang merupakan bagian dari tim pengembangan [tidak direkomendasikan] ini dapat diselesaikan dalam waktu sekitar 20% dari waktu yang dibutuhkan untuk upaya pengembangan.

Catatan: Saya menemukan utas ini ketika mencari sesuatu yang lain dan saya pikir saya mungkin dapat menambahkan beberapa nilai di sini. Btw, semua perkiraan upaya di atas ini didasarkan pada pengalaman kerja saya sebagai manajer keterlibatan di berbagai proyek. Semoga ini bisa membantu.


terima kasih - dan tanpa keringat, saya menghargai melihat angka untuk pertanyaan "berapa banyak"!
peterchen

0

Setiap organisasi dan basis kode berbeda, sehingga sulit untuk mendapatkan nilai industri yang luas.
Jika Anda benar-benar serius maka Anda harus mulai mengumpulkan metrik. Yaitu Lakukan review kode sampai selesai dilakukan termasuk pengerjaan ulang. Mulai kumpulkan ini dalam database (LOC, kompleksitas kode, bahasa pemrograman, waktu dll.). Kemudian, kumpulkan juga metrik pada tingkat kerusakan Anda selama pengujian. Selama Anda dapat mengurangi review kode ini harus membayar dengan sendirinya. Jika cacat muncul kembali dari pengujian, kumpulkan metrik tentang berapa banyak waktu yang dihabiskan untuk memperbaiki cacat. Bangun data ini di organisasi Anda, buat garis dasar, dan Anda dapat memperkirakannya dengan cukup akurat. Istilah untuk mencari pembelajaran lebih lanjut adalah Biaya Kualitas dan Biaya Kualitas Buruk.

Satu-satunya peringatan adalah bahwa ini dapat mulai menjadi birokratis dan tergantung pada budaya organisasi.


Saya mencari beberapa data praktis, jadi saya mendapat gambaran tentang kisaran yang diharapkan.
peterchen
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.