Bagaimana saya memilih kode apa yang akan ditinjau?


14

Saya adalah bagian dari tim yang terdiri dari tujuh pengembang di perusahaan perangkat lunak kecil dan saya mencoba memperkenalkan kode grup dan ulasan desain. Kami telah melakukan beberapa ulasan di masa lalu, tetapi sudah sporadis. Saya ingin menjadikannya hal yang lebih biasa.

Saya telah membaca Kode Lengkap dan sumber daya serupa lainnya dan mereka berbicara tentang mekanisme bagaimana melakukan tinjauan kode tetapi saya tidak dapat menemukan praktik terbaik tentang cara memilih apa yang akan ditinjau. Kami memiliki basis kode yang berusia lebih dari delapan tahun dan mencakup berbagai bahasa, jadi ada banyak yang bisa dilihat.

Berikut adalah beberapa faktor yang dapat saya pikirkan yang mungkin mempengaruhi pilihan:

  • Bahasa: C, Java, SQL, PL / SQL
  • Usia kode: Kode baru vs kode lama
  • Penggunaan kode: Kode yang sering digunakan vs (efektif) kode mati / sedikit digunakan
  • Kode penting: Kode kritis vs kode tidak kritis
  • Pengembang: Kode pengembang junior vs. Kode pengembang senior

Saya mengerti bahwa ini bukan pertanyaan dengan jawaban pasti yang absolut, tetapi panduan apa pun akan bermanfaat.

Beberapa pertanyaan terkait perifer:

Jawaban:


12

Secara umum, Anda harus meninjau semuanya . Jika aplikasi baru memiliki 2.000 LOC, semua 2.000 LOC harus ditinjau.

Itu sebabnya tidak ada praktik terbaik tentang cara memilih apa yang akan ditinjau.

Jika Anda mendekati basis kode besar yang ada, tidak pernah ditinjau sebelumnya, maka itu adalah hal yang sama ketika Anda harus menulis ulang basis kode besar yang ada , dan untuk memilih dari mana harus memulai. Itu sangat tergantung:

  • pada basis kode (kode monolitik tunggal akan lebih sulit untuk ditulis ulang / ditinjau daripada sekumpulan komponen yang terpisah, dll.),

  • konteks Anda (dapatkah Anda menghentikan semua yang Anda kerjakan dan menghabiskan tiga bulan (tiga tahun?) hanya bekerja pada penulisan ulang / ulasan, atau Anda harus melakukannya dengan penyimpangan kecil, hanya ketika Anda memiliki waktu luang)?

  • jenis ulasan yang Anda lakukan (apakah Anda memiliki daftar periksa hal-hal untuk ditinjau? Tergantung pada item daftar periksa, Anda mungkin ingin meninjau beberapa bagian terlebih dahulu).

Jika saya jadi Anda, saya akan:

  • ikuti prinsip 80% -20%, yang disebutkan dalam komentar pertama dari pertanyaan kedua yang Anda tautkan.

  • memperhitungkan bahwa 100%, menjadi ideal, tidak mungkin sepadan. Ini seperti cakupan kode 100% untuk pengujian unit, kecuali bahwa cakupan kode seperti itu sebagian besar tidak mungkin atau sangat mahal.

  • Mulailah dengan bagian-bagian kode yang paling sering Anda gunakan dan mana yang paling penting. Jika basis kode memiliki perpustakaan yang mengotentikasi dan mendaftarkan pengguna baru di situs web perusahaan Anda, tinjau lebih dulu, karena Anda tentu ingin menemukan celah keamanan sebelum peretas melakukannya.

  • gunakan metrik yang ada untuk menentukan apa yang lebih penting untuk ditinjau. Jika bagian dari basis kode tidak memiliki tes unit sama sekali, sedangkan bagian lain, yang sama pentingnya, memiliki cakupan kode 85%, mulailah dengan meninjau bagian pertama. Jika bagian dari basis kode ditulis oleh pengembang yang diketahui tidak berpengalaman dan memperkenalkan lebih banyak bug daripada rekan-rekannya, mulailah dengan meninjau kodenya terlebih dahulu.


Jika Anda melakukan TDD dengan benar, maka cakupan 100% tidak hanya mudah, tetapi juga tidak terhindarkan, dan ternyata benar-benar menjadi bar yang sangat rendah.
Jonathan Hartley

4

Mulailah dengan meninjau semua perubahan yang Anda lakukan pada kode; itu akan menghentikan masalah semakin buruk. Kemudian mulailah meninjau kode berdasarkan frekuensi perubahan; ini akan menjadi area 'masalah'.

Anda harus mencari cara untuk melacak bahwa Anda telah meninjau bagian kode sehingga Anda dapat menganalisis cakupan ulasan kode Anda relatif terhadap masalah lain.

Jika Anda dapat menentukan kode apa yang tidak tercakup oleh pengujian Anda, itu menjadi prioritas yang lebih tinggi untuk ditinjau.


3

Tinjau semua perubahan baru yang telah dibuat sebelum mereka menghasilkan. skrip instalasi, kode sumber, perubahan basis data, semuanya! Inti dari tinjauan kode adalah untuk menghentikan kode buruk dari membuatnya menjadi produksi. Baik itu skema organisasi yang buruk atau sekadar bug yang diperkenalkan karena ada sesuatu yang terlewatkan.

Refactoring kode yang sedang Anda kerjakan berjalan seiring dengan review kode. Misalnya, ketika saya meninjau kode, jika ada kode duplikat di kelas yang berisi perbaikan bug, bahkan jika pengembang tidak mengubah kode itu dalam perbaikan mereka, saya tidak akan meneruskannya. Saya ingin mereka kembali dan menghapus kode duplikat.

Jika Anda refactor tanpa henti maka review kode menjadi berguna. Kalau tidak, itu buang-buang waktu.

Jika Anda memasukkan proses peninjauan kode sebagai langkah dalam proses pengembangan Anda, basis kode akan menjadi lebih baik seiring waktu. Lebih baik lagi, Anda tidak boleh membiarkan pengembang Anda mengambil pekerjaan fitur baru atau perbaikan bug sampai backlog ulasan kode kosong. Ini memastikan bahwa review kode dilakukan.

Jika ada area yang diketahui yang perlu di refactored, tetapi akan membutuhkan waktu lama untuk melakukannya (yaitu 1 minggu atau lebih). Kemudian buat item kerja untuk refactoring itu sendiri dan tambahkan item itu untuk dikerjakan.


1
Saya tidak setuju - biarkan kode masuk ke produksi, dan tinjau kalau bisa. Triknya adalah mempercayai pengembang Anda dan menganggap mereka tidak melakukan kesalahan besar. Jika mereka melakukannya (kita semua melakukannya) maka Anda dapat memperbaiki dan memperbaiki masalah setelah checkin. Mencoba menghentikan semua kode dari mencapai produksi sebelum ditinjau biasanya berarti tidak ada kode yang masuk ke produksi (menurut pengalaman saya). Tentu saja, jika Anda tidak mempercayai devs Anda, maka silakan menguncinya bersama dengan gunting tajam di lemari stasioner.
gbjbaanb

"Tinjau semua perubahan baru yang telah dibuat sebelum mereka membuat produksi" Saya sebagian besar setuju dengan ini. "Lebih baik lagi, Anda tidak boleh membiarkan pengembang Anda mengambil pekerjaan fitur baru atau perbaikan bug sampai backlog peninjauan kode kosong." Saya ingin melakukan ini, tetapi mengingat realitas tekanan komersial, sayangnya itu tidak realistis.
Burhan Ali

Saya selalu percaya devs saya. Para dev adalah yang melakukan peninjauan kode. Juga, menempatkan proses di tempat untuk memastikan bahwa tinjauan kode dilakukan dengan cara apa pun tidak mencerminkan kurangnya kepercayaan pada kemampuan pengembang. Para pengembang, manajer proyek, dan pemilik bisnis semua harus lebih lega bahwa ada satu hal yang kurang perlu dikhawatirkan, yaitu: mengingat untuk melakukan review kode.
Charles Lambert

@ BurhanAli - Sangat realistis. Pelanggan kami adalah pelanggan kelas atas (pikirkan Microsoft) dan siklus rilis kami sangat cepat. Ini akan memakan waktu sekitar 30 menit, mungkin satu jam pada kesempatan, bagi pengembang untuk meninjau perubahan. Jika itu membutuhkan waktu lebih lama dari itu, maka kemungkinan besar Anda tidak membagi pekerjaan Anda menjadi bagian-bagian yang cukup kecil, yang merupakan masalah yang sama sekali berbeda.
Charles Lambert

2
@ gbjbaanb Anda membiarkan kode yang tidak ditinjau masuk ke produksi? Wow. Ini bukan tentang tidak mempercayai pengembang Anda (Anda bisa meminta salah satu pengembang Anda untuk meninjau kode orang lain), ini tentang menemukan kesalahan yang sangat jelas
Rob

2

Mulailah dengan meninjau semua kode baru, dan modifikasi pada kode yang ada.

Saat meninjau modifikasi kode yang ada, pengembang harus mengikuti aturan boyscout. Tinggalkan kodenya lebih baik daripada yang dia temukan.

Itu tidak berarti bahwa Anda harus memperbaiki seluruh file agar sempurna. Tapi itu seharusnya tidak menambah kekacauan, itu harus membuatnya sedikit lebih baik. Mungkin dengan memindahkan modifikasi ke kelas-kelas baru yang terstruktur dengan benar, dan meninggalkan sisa file kode asli apa adanya (setelah semua, ini 'berfungsi).

Setelah Anda mulai meningkatkan kode dengan meninjau semua kode baru dan modifikasi, sebagai pengembang, Anda harus tahu bidang aplikasi mana yang paling membutuhkan perubahan. Kemudian, tinjau semua itu, diskusikan bagaimana mereka dapat ditingkatkan, sedikit demi sedikit.

Meninjau kode yang ditulis 10 tahun yang lalu, demi memeriksanya, tidak ada gunanya, pengembang harusnya meningkat selama 10 tahun itu. Jadi, tidak ada gunanya meninjaunya hanya untuk mengetahui apa yang Anda semua tahu.

Tujuan tinjauan kode adalah untuk meningkatkan dan memperbaiki kesalahan yang Anda buat saat ini dan untuk membagikan pengetahuan itu di antara tim.


+1 untuk "Tinggalkan kode lebih baik daripada yang ditemukannya." Saya selalu berusaha mendorong itu. Adapun meninjau kode lama 10 tahun hanya demi itu, saya setuju dengan apa yang Anda katakan. Tetapi apakah mungkin ada beberapa manfaat dalam melakukannya untuk membuat tim lebih nyaman dengan gagasan peninjauan? Tidak banyak bahaya orang-orang bersikap defensif terhadap kode yang tidak mereka tulis (atau sudah terlalu tua mereka lupa bahwa mereka menulisnya.)
Burhan Ali

1

Dalam proyek saya, kami memasukkan tinjauan kode sebagai yang harus dimiliki dalam banyak kasus untuk setiap tugas / cerita pengguna / bug yang sedang dikembangkan. Kami menggunakan proses scrum / agile dan tiket / cerita tidak dipindahkan ke build (yang merupakan jaminan untuk QA) sampai unit test ditulis dan pengkodean kode selesai.

Kami menggunakan analisis Atlassian FishEye dengan ulasan kode Crucible yang terintegrasi dengan JIRA + SVN untuk tujuan ini.

Ketika pengembang memeriksa kode untuk cerita tertentu, ia membuat ulasan kode baru di FishEye, di mana ia memilih anggota tim lainnya untuk melakukan pemeriksaan.

Setelah peninjauan kode selesai, (alat menyoroti perubahan yang diajukan dan memungkinkan untuk meninggalkan komentar untuk baris kode tertentu) pengembang mengoreksi masalah yang disebutkan / mengimplementasikan perbaikan yang disarankan dan memindahkan tiket ke kolom Dibangun di JIRA - yang berarti cerita adalah siap untuk diuji dan tidak ada lagi perubahan kode yang diharapkan untuk item kerja spesifik ini.

Ini juga memastikan QA tidak menguji apa pun yang mungkin diubah dan berpotensi rusak saat melakukan refactoring kode setelah peninjauan kode .

Singkatnya, semua kode harus ditinjau - ini mendukung kode berkualitas tinggi, yang biasanya menghasilkan desain yang lebih baik, keterbacaan, rawatan dan kemampuan uji kode dan meningkatkan kinerja pengembangan dalam jangka panjang.

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.