Haruskah kita mencoba meninjau semua kode kita?


18

Kami saat ini sedang memodifikasi proses pengembangan dan saya bertanya-tanya apakah kami harus mencoba untuk menjaga 100% dari komitmen rekan kami ditinjau.

Apa pengalaman Anda tentang ulasan kode?

  • Apakah Anda cenderung menghabiskan "banyak" waktu pada mereka (katakanlah 1/2 jam per hari), atau hanya membaca skim selama 5/10 menit?
  • Apakah Anda memiliki jumlah waktu yang tetap untuk dihabiskan per hari / minggu / sprint / proyek?
  • Yang paling penting menurut Anda apakah targetnya 100% dari kode harus ditinjau sejawat atau 100% tidak perlu?

Cobalah untuk menyentuh 80% dari kode dengan 20% dari upaya. Investasikan dalam alat otomatis terbaik yang dapat dibeli dengan uang.
Pekerjaan

2
Alat otomatis sangat bagus, tetapi menjadi tidak berguna kecuali Anda memiliki waktu dan sumber daya untuk mempertahankan semua tes sebagai yang terbaru.
Kieren Johnstone

Jawaban:


19

Kami memiliki tugas 'Tinjauan Kode' di setiap cerita. Seseorang yang idealnya tidak terlibat dalam pengembangan cerita itu akan meninjau semua perubahan kode yang terkait dengan cerita itu. Itu bekerja dengan baik.

Banyak waktu? Tidak terlalu banyak, tergantung pada seberapa banyak kode - kami sedang mencari kesalahan yang jelas, kesalahan ketik, pengecekan logika dasar, pengecualian tanpa tertangkap, dll.

Ini adalah langkah kualitas yang tidak menemukan bug, oleh karena itu memiliki beberapa nilai. Mengalokasikan waktu mungkin bukan cara terbaik untuk melakukannya - bagaimana jika ada sesuatu yang cukup kompleks, itu harus ditinjau kode?

Ngomong-ngomong, penting bahwa orang lain melakukan review kode ..


3
"Ngomong-ngomong, penting bahwa orang lain melakukan review kode ..", apakah pertanyaannya menyiratkan bahwa orang yang sama yang menulis kode harus memeriksanya? Jika ada di mana? Saya ingin memperbaikinya :)
Simeon

4
Tidak, saya komprehensif dan mengatakan itu penting
Kieren Johnstone

5
@Simeon sebenarnya kesalahpahaman yang paling umum bahwa pemilik dapat meninjau kode mereka sendiri. Itu merusak seluruh operasi
Tom Squires

5
@ Tom meminta: Tepat. Ketika Anda telah bekerja dengan sepotong kode untuk waktu yang lama, Anda bisa menjadi "buta" terhadap kekurangan yang jelas di dalamnya, karena Anda melihatnya sebagai apa yang seharusnya bukan apa itu. Masalah-masalah ini akan lebih mudah dikenali bagi seseorang yang belum pernah melihat kode sebelumnya. Penulis memiliki masalah yang sama, dan seperti halnya buku yang tidak dirilis tanpa proofreading, kode tidak boleh dirilis tanpa ulasan. Ada juga manfaat lain untuk melakukan tinjauan kode, misalnya itu baik untuk mentransfer pengetahuan antara anggota tim Anda.
hammar

@hammar - tentu saja mencoba menemukan seseorang yang tidak menulis kode yang memiliki waktu untuk menjadi begitu akrab dengannya sehingga mereka dapat membantu memeriksanya, adalah sebuah tantangan
Peter Ajtai

12

Masalah yang lebih penting adalah seberapa banyak kode Anda ditanggung oleh ulasan, adalah seberapa efektif ulasan tersebut. Jika ulasan Anda menemukan sedikit atau tidak ada masalah, maka mencapai cakupan penuh akan sia-sia.

Pertama-tama usahakan agar ulasan Anda lebih berpengaruh, lalu tentukan cakupannya.

Ulasan harus dilakukan tidak hanya pada kode, tetapi juga pada desain.



Juga, ulasan bukan pengganti untuk tes dan alat:

  • Ulasan bisa mengeringkan kode yang dijalankan
  • Ulasan dapat mencakup analisis kode
  • Ulasan memeriksa penggunaan kembali dan keterbacaan
  • Ulasan dapat memeriksa beberapa aspek efisiensi, namun, ini tidak menggantikan pengukuran aktual waktu berjalan dan menemukan leher botol
  • Ada alat untuk analisis kode statis
  • Ada alat untuk menguji konvensi pengkodean, jangan buang waktu ulasan untuk ini
  • Unit, sistem dan tes integrasi kode run basah
  • Tes unit, sistem dan tes integrasi dapat diulang secara otomatis, review kode biasanya hanya sekali saja
  • Tes unit harus memiliki cakupan kode yang tinggi dan menguji skenario keberhasilan utama dan kondisi akhir, ulasan kode hanya dapat melakukan sebagian
  • Tes integrasi menguji kemampuan unit atau sistem untuk bekerja bersama, tinjauan kode tidak dapat menggantikan ini
  • Tes sistem menguji fungsionalitas seluruh sistem, tinjauan kode tidak dapat menggantikan ini



Cobalah mendedikasikan jumlah waktu tertentu per bulan (atau per sprint) untuk ulasan. Pilih kode yang ingin Anda tinjau di slot khusus berikutnya menggunakan heuristik seperti:

  • Kode yang mungkin mengandung bug yang tidak dikenal yang dilaporkan
  • Kode dengan bug baru-baru ini telah diidentifikasi di dalamnya
  • Kode dengan masalah kinerja (leher botol)
  • Kode ditulis oleh pengembang baru
  • Kode lama yang baru saja diperbarui oleh seseorang yang sebelumnya tidak terbiasa dengannya
  • Kode di area baru
  • Kode yang ada yang Anda ingin pelajari dari pengembang baru
  • Kode yang memecahkan masalah kompleks
  • Kode yang diidentifikasi kompleks oleh alat analisis

Dan ingat, Anda meninjau kode (atau desain atau tes) dan bukan penulis.



Saya merekomendasikan bahan bacaan berikut:

Ulasan Homeworkless Selektif,
Best Kept Secrets of Peer Code Review


5

Tergantung.

Tergantung pada apa yang dilakukan perangkat lunak Anda:

  • Jika itu mengendalikan alat pacu jantung elektronik atau pesawat ulang-alik, maka pasti ya.

  • Jika itu adalah prototipe sekali pakai, maka mungkin tidak.

Itu juga tergantung pada seberapa baik sumber daya Anda, seberapa berpengalaman pengembang Anda, dan apa yang Anda cari dalam ulasan kode. (Ingatlah bahwa pengembang rata-rata meninjau kode orang lain mungkin akan melihat masalah gaya dan kehilangan bug algoritme yang halus ... terutama mengingat bahwa peninjauan kode adalah sesuatu yang sulit.)

Saran saya adalah untuk menyimpan upaya tinjauan kode Anda untuk kode di mana kebenaran sangat penting dan biaya kesalahan tidak terdeteksi tinggi.


5

Pertama, Anda perlu menjawab pertanyaan ini: Mengapa Anda meninjau kode?

Dengan jawaban itu di tangan, Anda dapat mengetahui kode mana yang perlu ditinjau.

Beberapa ulasan kode menyelesaikan persis apa yang dilakukan atau akan dilakukan pengujian. Jika itu adalah tujuan ulasan Anda, maka mendekati 100% adalah ide yang baik jika Anda memiliki sedikit pengujian. Namun, membiarkan alat uji melakukan ini akan mengurangi kebutuhan semua kode untuk ditinjau.

Sebagian besar ulasan yang baik tampaknya difokuskan pada berbagi pengetahuan dan meningkatkan kemampuan pengembang dalam ulasan (baik yang menulis kode atau yang meninjau kode). Dengan ini sebagai alasan utama untuk ulasan, pastikan untuk meninjau 100% dari kode mungkin berlebihan.


3

Dalam dunia yang sempurna, semuanya akan secara eksplisit dibaca oleh penulis dan rekan sejawat ditinjau oleh setidaknya satu orang lain, dari spesifikasi persyaratan untuk buku petunjuk hingga kasus uji. Tetapi ulasan, bahkan pemeriksaan meja sederhana, membutuhkan waktu dan biaya uang. Ini berarti bahwa Anda perlu memilih apa yang harus Anda tinjau dan kapan Anda harus memeriksanya.

Saya merekomendasikan memprioritaskan hal-hal untuk ditinjau, memilih bagaimana Anda ingin memeriksanya, dan mencoba meninjau sebanyak mungkin dengan tingkat detail yang sesuai. Prioritas dapat didasarkan pada jenis artefak, seperti menyatakan bahwa persyaratan harus ditinjau, desain dan kode produksi harus ditinjau, dan kasus uji dapat ditinjau. Di dalamnya, Anda juga dapat menentukan bahwa komponen berisiko tinggi atau bernilai tinggi menerima prioritas dalam peninjauan, atau mungkin peninjauan yang lebih formal.

Sejauh waktu, itu semua kembali ke seberapa tinggi prioritas komponen itu. Ada saat-saat di mana saya menghabiskan 10-15 menit untuk meninjau, dan di lain waktu ketika beberapa orang telah membaca kode secara individual kemudian pergi ke sebuah ruangan untuk melakukan proses pemeriksaan yang lebih formal yang berlangsung 30-45 menit (tergantung pada ukuran modul).

Pada akhirnya, ini adalah keseimbangan antara waktu, biaya, ruang lingkup, dan kualitas. Anda tidak dapat memiliki semuanya, jadi Anda harus mengoptimalkan di mana Anda bisa.


3

Sebagai saran, jika Anda berencana untuk melakukan tinjauan sama sekali, miliki beberapa pedoman bersama tentang ruang lingkup dan tujuan ulasan untuk memastikan bahwa ulasan tidak menyebabkan gesekan yang tidak perlu antara anggota tim.

Tim yang koheren membangun proyek yang lebih baik. Orang mungkin kehilangan hubungan karena omong kosong atau karena permintaan kesempurnaan. Selalu ada satu orang yang akan mengeluh tentang ini atau itu dan mengganggu orang lain hanya karena dia seperti itu ...


2

Saya memesan satu jam per hari untuk melakukan peer review, tetapi tidak selalu membutuhkannya. Basis kode kami dibagi di antara beberapa lusin produk. Kebijakan kami adalah bahwa perubahan sepele dalam kode yang unik untuk satu produk boleh saja masuk tanpa ulasan. Perubahan satu produk yang lebih kompleks memerlukan peninjauan, tetapi mungkin tidak formal seperti memanggil rekan kerja di meja Anda untuk memberikannya sekali. Perubahan dalam kode bersama memerlukan peninjauan yang lebih formal, termasuk pengembang pada produk lain. Saya pikir kebijakan kami memberikan keseimbangan yang cukup baik dibandingkan dengan perusahaan lain tempat saya bekerja.

Saya menghabiskan lebih banyak waktu per hari untuk ulasan daripada beberapa rekan saya dengan peran yang kurang penting, tetapi saya tidak menganggapnya sebagai jumlah waktu yang tidak masuk akal, karena sebelum kebijakan peninjauan saya dapat dengan mudah membuang lebih banyak waktu daripada melacak bug yang dikembangkan oleh pengembang. pada produk lain yang diperkenalkan.


Apakah itu rata-rata? Membatasi ulasan yang rumit menjadi satu jam terasa aneh, dan jika tidak banyak yang mengulasnya ... yah, saya tidak bisa melihat bagaimana satu jam sehari bisa diterapkan?
Kieren Johnstone

Itu bukan batas. Saya mengatur waktu berdasarkan berapa lama, bukan sebaliknya. Saya biasanya dapat menyelesaikan 2 ulasan dalam satu jam. Jika butuh lebih lama dari itu, info masuk Anda terlalu besar, Anda tidak mendapatkan cukup ulasan desain sebelumnya, atau alat peninjau kode Anda terlalu rumit. Ulasan kode adalah cek, bukan desain ulang.
Karl Bielefeldt

2

Kami telah melakukan 100% ulasan untuk kode. Ini jauh lebih murah daripada pengujian, terutama pengujian cakupan kode 100%. Kami tidak menghabiskan terlalu banyak waktu untuk mereka, meninjau lebih dari satu jam per hari menjadi kurang produktif. (30 menit tidak banyak).

Saat Anda memusatkan perhatian pada proses, catat. Apa yang kamu temukan? Apa yang ditemukan QA nanti? Apa yang ditemukan pelanggan Anda? Mengapa serangga itu lolos dari Anda?


7
Bagaimana cara meninjau lebih murah daripada pengujian otomatis? Dengan asumsi Anda menulis tes sekali, meninjau tes sekali, dan memiliki rangkaian tes yang stabil, Anda harus menghabiskan jauh lebih sedikit waktu dan uang untuk melakukan tes daripada yang diperlukan untuk melakukan segala jenis tinjauan (selama umur proyek). Juga, bertujuan untuk cakupan kode 100% adalah pemborosan sumber daya, yang mungkin menjadi alasan untuk waktu / biaya pengujian yang lebih besar. Saya juga mempertanyakan 30 menit dalam ulasan - kita mungkin meninjau modul selama 30 menit, tetapi ada waktu persiapan membaca kode pada awalnya, memahami perannya dalam sistem, dan mengomentarinya.
Thomas Owens

Klaim @Malters 'tidak pernah terdengar, meskipun saya juga skeptis dengan hanya membutuhkan waktu 30 menit .. Saya hanya membaca satu tempat di mana pemeriksaan lebih hemat biaya daripada pengujian unit otomatis dan itu adalah NASA. Dalam hal itu mereka akhirnya membatalkan pengujian unit karena lebih murah untuk memeriksa kode secara manual. Tentu saja, NASA masih memiliki rasio penguji: pengembang: 12: 1, jadi mereka juga melakukan banyak pengujian lainnya ...
Michael

2
@ Thomas Owens: unit test menemukan bug sederhana. Bug yang mahal adalah bug yang menggabungkan banyak unit dengan cara yang tidak terduga. Jenis lain dari bug adalah kasus sudut terjawab. Seorang pengembang yang melewatkan sebuah case tidak akan menulis unit test untuknya, tetapi sepasang mata kedua akan menemukannya.
MSalters

@MSalters Itu sebabnya Anda menulis integrasi otomatis dan pengujian sistem serta pengujian unit. Sungguh, satu-satunya tes yang mungkin perlu dilakukan secara manual adalah tes penerimaan. Dan dengan meninjau tes pada saat penciptaan akan membantu memastikan bahwa kasus yang paling kritis diuji.
Thomas Owens

2

Memiliki ulasan kode reguler kebanyakan untuk membangun tim dan berbagi ide tentang implementasi Anda bisa belajar banyak dari rekan kerja dengan cara ini.


Ini hanya menunjukkan beberapa manfaat. Apakah menurut Anda menemukan kesalahan itu penting? Jika ya, berapa banyak?
JeffO

Tentu saja menemukan kesalahan itu penting tetapi manfaat yang lebih besar adalah pengetahuan jangka panjang yang diperoleh dari ulasan kode. Mungkin bug diciptakan oleh pendekatan buruk yang dapat dicegah di masa depan
coder

2

Kami memerlukan peninjauan kode rekan untuk setiap check-in. Jika tidak ada rekan kerja yang tersedia, kami mengatur pemeriksaan setelah check-in. Peninjau dicatat dalam komentar check-in kontrol sumber.

Ini tidak memakan banyak waktu, dan karena dilakukan di antara teman sebaya, tidak ada aspek dewasa-anak yang beracun bagi mereka.


2

Diperlukan Peninjauan Kode, IMO. Anda 99,999 ...% dari waktu tidak selalu benar, jadi Anda harus memastikan itu benar. Apakah saya memiliki waktu yang ditentukan? Tidak. Tapi saya meluangkan waktu untuk memeriksa kode saya. Biasanya saya memiliki kolega melakukan hal yang sama.


1

Ulasan kode mungkin tampak menakutkan, tetapi mereka adalah alat yang berharga ketika dilakukan dengan benar. Mereka akan menjadi garis pertahanan pertama Anda terhadap kesalahan desain dan implementasi. Jika Anda tidak melakukan tinjauan kode pada setiap fitur yang Anda tempatkan, Anda harus mulai ASAP.

Adapun berapa banyak waktu yang dihabiskan untuk tinjauan sejawat, praktik yang baik adalah menyisakan 5-10% dari total perkiraan waktu pengembangan Anda untuk melakukan dan merespons tinjauan kode.

Kami memiliki whitepaper tentang melakukan ulasan kode efektif yang dapat membantu Anda memulai dengan langkah yang benar. Ini adalah panduan langkah demi langkah dan membahas perangkap umum yang mungkin Anda hadapi dan cara mengatasinya. Anda dapat mengunduhnya dari situs web kami.

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.