Apakah baik untuk meninjau program dengan senior dan bos bahkan jika itu berfungsi dengan baik?


18

Di perusahaan saya, sebelum pengiriman proyek apa pun, bos saya meminta senior saya untuk meninjau program yang ditulis oleh saya atau anggota tim lain atau kadang-kadang bos juga duduk bersama kami untuk diperiksa.

Saya pikir itu adalah cara yang baik untuk mendapatkan pengetahuan, tetapi kadang-kadang ketika program bekerja dengan baik, mereka tidak bekerja sama setelah ditinjau dan saya perlu melihat kembali ke dalam program saya.

Mereka mengatakan bahwa tinjauan membantu untuk mengoptimalkan eksekusi program dan permintaan, tetapi dapatkah kita lebih memilih optimasi daripada fungsi aktual dari program?


6
bagaimana Anda bisa yakin apakah itu berfungsi dengan baik tanpa ulasan oleh seseorang yang tidak tahu keanehan yang Anda terbiasa ketika melakukan pengujian Anda sendiri
ratchet freak

karena mereka meninjau kode setelah pengujian penuh modul oleh tim pengujian.
Himanshu

15
@ Himanshu: Tinjauan setelah pengujian sudah pasti terlambat . Review harus dilakukan pada pekerjaan yang sedang berlangsung.
Jan Hudec

3
Rangkul praktik ini. Saya sangat berharap kami melakukan ini di tim saya. Ini membantu menghilangkan silo pengetahuan (masalah besar bagi kami), dan memastikan rekan kerja Anda dapat bekerja dengan kode Anda. Jika ulasan Anda berarti kode Anda kadang-kadang ditulis ulang, itu hal yang baik. Bahkan programmer hebat terkadang menulis kode buruk; sebagian dari kita akan lebih suka waktu untuk kembali dan membersihkannya. Ini harus menjadi kesempatan untuk memiliki pengalaman belajar yang hebat dengan orang-orang yang lebih berpengalaman daripada Anda. Jangan menganggapnya sebagai orang yang menyerang kode Anda; anggap sebagai orang yang mencoba membantu Anda tumbuh menjadi programmer yang lebih berpengalaman.
jpmc26

1
Jika sudah umum bahwa kode yang "berfungsi dengan baik" dirobek berkeping-keping selama peninjauan kode sejauh anggota tim merasa bahwa banyak momentum yang hilang, maka Anda mungkin harus mempertimbangkan pemrograman pasangan, sehingga kode ditinjau saat sedang tertulis.
Buhb

Jawaban:


38

"Bekerja dengan baik" memang metrik yang hebat, tetapi jika Anda adalah satu-satunya di tim yang dapat menguraikan apa yang Anda tulis, dan dengan demikian mempertahankannya, kode itu hampir tidak berharga bagi perusahaan untuk jangka menengah atau panjang.

Kode yang baik setidaknya adalah:

  • bekerja sebagaimana dimaksud
  • dapat dibaca manusia / jelas
  • mudah dirawat
  • mudah diperluas untuk perubahan di masa depan
  • aman
  • tanpa ketergantungan yang tidak dibutuhkan
  • menangani dengan benar kasus yang tidak nominal
  • dll

(Beberapa persyaratan ini sebenarnya tumpang tindih tetapi bagus untuk dipertimbangkan secara individual ...)

Ulasan kode melayani tujuan di luar bagian "kerja", yang dapat dilakukan melalui tes otomatis.

Saya pribadi tahu ini menjengkelkan karena ada sesuatu yang bekerja terpisah, dan harus membangunnya kembali dari bawah ke atas. Tetapi, seringkali, ini disebabkan oleh miskomunikasi dari pimpinan senior / teknologi. Jadi, jika Anda berpikir Anda harus menulis ulang terlalu sering, lain kali, pergi ke resensi sebelum menulis satu baris dan mencoba untuk mendapatkan informasi sebanyak mungkin tentang apa yang dia harapkan, dalam setiap detail. Ini juga bisa menjadi luar biasa jika tim peninjau kode meringkas harapan mereka dalam dokumen formal yang dapat dirujuk oleh setiap pengembang.

Di sisi yang lebih positif, sesi juga bisa menjadi kesempatan untuk berbagi praktik / desain hebat.


1
Saya akan menambahkan bahwa pengujian kode tidak menyiratkan tidak ada bug, batasi kasus di mana perangkat lunak akan crash misalnya.
dyesdyes

3
Saya setuju, dan tes otomatis juga harus ditinjau kode untuk memastikan mereka menguji hal yang benar ... Turtles sepanjang jalan.
Xavier T.

12

Saya menginterpretasikan pertanyaan Anda sebagai "Dapatkah kode saya berfungsi dijagal dalam review ke titik di mana itu bahkan tidak dikompilasi lagi?" .

Ya bisa. Secara umum, selama ulasan Anda melihat bagaimana kode Anda melakukan apa yang dilakukannya. Ketika Anda ingin menyerahkan kode Anda, Anda mengatakan telah menyelesaikan bagian tertentu dari program.

Anda mengatakan itu berhasil. Pengujian kemudian dilakukan untuk memverifikasi ini. Modul yang lulus tes tidak berarti bahwa modul tidak boleh disentuh lagi.

Modul yang tampak fungsional masih bisa menjadi bencana yang menunggu untuk terjadi, baik saat runtime atau dalam beberapa bulan ketika Anda atau orang lain harus melakukan pemeliharaan atasnya. Dengan mengubah kode Anda dalam ulasan dan menunjukkan apa yang salah dengannya, pengulas Anda (semoga) berusaha untuk benar-benar mengajari Anda sesuatu.


3

Ulasan rekan tidak diragukan lagi cara belajar yang bagus. Seseorang mungkin melihat sesuatu yang berbeda, mereka memiliki pengalaman berbeda untuk Anda dan harus dapat berkontribusi perbaikan. Ini seharusnya tidak meremehkan, saya berharap setiap pengembang dapat berkomentar dan mengkritik secara konstruktif kode siapa pun!

Bagi saya sepertinya beberapa "perbaikan" ini benar-benar membuat perubahan karena (seperti yang Anda harapkan) pengembang peninjau memiliki lebih sedikit pengalaman dengan perangkat lunak daripada penulis.

Tren ini berupa umpan balik sendiri, mungkin kode Anda sulit diikuti atau dipelihara? Apakah ulasan Anda berharga? Benar! Saya bisa melihat bagaimana hal itu bisa membuat frustasi, memiliki kode kerja yang oleh rekan-rekan Anda tampaknya rusak, Anda tidak boleh berkecil hati - Anda harus bekerja untuk melindungi kode Anda terhadap perubahan ini.

Pertanyaannya kemudian menjadi bagaimana melindungi fungsionalitas program Anda sehingga Anda tahu fungsionalitasnya masih berfungsi setelah Anda menyelesaikan ulasan Anda. Saran saya adalah untuk memastikan Anda memiliki cakupan tes unit yang layak. Dengan begitu setiap kali Anda / pengulas Anda / pengganti Anda mengubah kode mereka dapat yakin bahwa perubahan yang mereka buat aman.

ETA: Saya baru saja melihat salah satu komentar Anda, saya yakin ini tidak perlu dikatakan tetapi ulasan kode harus dilakukan sebelum tim penguji mengambilnya. Kalau tidak, mereka tidak menguji produk akhir.


1
Tes integrasi juga sangat berguna untuk mendeteksi kerusakan.
jpmc26
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.