Code Review Best Practices: How to Review (and Be Reviewed) — txt1.ai

Saya masih ingat ulasan kode yang hampir membuat saya berhenti dari rekayasa perangkat lunak. Itu tahun 2012, saya sudah enam bulan bekerja di pekerjaan pertama saya di sebuah startup fintech, dan saya baru saja mengirimkan apa yang saya anggap sebagai refactoring brilian dari sistem pemrosesan pembayaran kami. Ulasan dari insinyur senior kembali dengan 47 komentar—kebanyakan dari mereka variasi dari "ini salah" tanpa penjelasan. Saya menghabiskan tiga hari untuk menulis ulang semuanya, hanya untuk mendapatkan persetujuan dari peninjau yang sama dengan satu kata: "Baiklah." Pengalaman itu tidak mengajarkan saya apa pun tentang menulis kode yang lebih baik, tetapi semuanya tentang bagaimana TIDAK melakukan ulasan kode.

Maju dua belas tahun, sekarang saya adalah Insinyur Utama di sebuah perusahaan SaaS Seri C, setelah meninjau lebih dari 8.000 permohonan tarik dan membimbing lebih dari 40 pengembang melalui proses ulasan kode. Saya telah melihat ulasan kode menyelamatkan perusahaan dari bug bencana, dan saya telah melihatnya menghancurkan moral tim begitu parah sehingga seluruh departemen teknik berganti dalam waktu enam bulan. Perbedaannya? Bukan kualitas kode yang ditinjau, tetapi kualitas proses ulasan itu sendiri.

Ulasan kode adalah salah satu alat paling kuat dalam pengembangan perangkat lunak dan sering disalahgunakan. Menurut laporan Status Ulasan Kode 2023 dari SmartBear, tim yang menerapkan proses ulasan kode yang terstruktur menangkap 60-90% cacat sebelum produksi, namun penelitian yang sama menunjukkan bahwa 73% pengembang melaporkan pengalaman negatif dengan ulasan kode yang merusak kepercayaan diri atau hubungan dengan rekan tim. Paradoks ini ada karena kebanyakan tim fokus pada APA yang harus ditinjau daripada BAGAIMANA cara meninjaunya.

Psikologi Ulasan Kode: Mengapa Kebanyakan Ulasan Gagal Sebelum Dimulai

Inilah yang tidak ada yang memberi tahu Anda tentang ulasan kode: mereka tidak terutama tentang kode. Mereka tentang orang. Setiap permohonan tarik mewakili jam-jam usaha intelektual seseorang, pemecahan masalah yang kreatif, dan identitas profesional. Ketika Anda meninjau kode, Anda tidak hanya mengevaluasi logika dan sintaksis—Anda sedang berinteraksi dengan produk kerja orang lain dengan cara yang akan membangunnya atau menghancurkannya.

Saya belajar ini dengan cara yang sulit setelah melakukan wawancara keluar dengan seorang pengembang junior berbakat yang meninggalkan tim kami. Dia memberi tahu saya bahwa satu komentar ulasan kode yang meremehkan—"Mengapa Anda bahkan melakukannya dengan cara ini?"—membuatnya mempertanyakan apakah dia layak berada di bidang rekayasa. Peninjau itu bermaksud baik sebagai pertanyaan yang tulus, penasaran tentang alasannya. Dia menafsirkannya sebagai penilaian. Saat itulah saya menyadari bahwa media teks yang asinkron menghilangkan nada, ekspresi wajah, dan bahasa tubuh, hanya menyisakan kata-kata yang dapat ditafsirkan dalam pandangan terburuk.

Penelitian psikologis mendukung hal ini. Sebuah studi 2021 yang diterbitkan dalam IEEE Transactions on Software Engineering menemukan bahwa komentar ulasan kode yang dianggap keras atau meremehkan meningkatkan waktu untuk bergabung rata-rata 3,2 hari dan mengurangi kemungkinan penulis berkontribusi perbaikan di masa depan sebesar 34%. Sebaliknya, ulasan yang mencakup pujian spesifik bersamaan dengan umpan balik konstruktif menghasilkan siklus iterasi 28% lebih cepat dan kualitas kode 41% lebih tinggi dalam pengiriman berikutnya dari penulis yang sama.

Ini tidak berarti kami harus menyembunyikan segalanya atau menghindari menunjukkan masalah. Ini berarti kami perlu mendekati ulasan kode dengan niat tentang manusia di sisi lain. Sebelum menulis komentar ulasan apapun, saya mengajukan tiga pertanyaan kepada diri sendiri: Apakah ini benar? Apakah ini perlu? Apakah ini baik? Jika saya tidak bisa menjawab ya untuk ketiganya, saya menulis ulang komentarnya. Penyaring sederhana ini telah mengubah bagaimana tim saya berkomunikasi dan telah mengurangi waktu siklus PR rata-rata kami dari 4,3 hari menjadi 1,8 hari selama dua tahun terakhir.

Daftar Periksa Peninjau: Apa yang Sebenarnya Dicari

Ketika saya melatih peninjau baru, mereka selalu bertanya pada pertanyaan yang sama: "Apa yang harus saya cari?" Jawabannya bukanlah daftar sederhana aturan sintaksis atau pedoman gaya—itu harus diotomatiskan. Tugas Anda sebagai peninjau manusia adalah mengevaluasi hal-hal yang tidak bisa dilakukan mesin: keputusan desain, pemeliharaan, dan kebenaran logika bisnis.

Saya menggunakan sistem prioritas empat tingkat yang membantu saya memfokuskan energi ulasan saya di tempat yang paling penting. Masalah Tingkat 1 adalah penghalang: kerentanan keamanan, risiko kehilangan data, atau perubahan yang merusak yang akan menyebabkan insiden produksi. Ini segera ditandai dengan penjelasan jelas tentang risikonya. Dari pengalaman saya, masalah Tingkat 1 yang sebenarnya muncul dalam kurang dari 5% permohonan tarik, tetapi saat muncul, menangkapnya adalah satu-satunya alasan kami melakukan ulasan kode.

Masalah Tingkat 2 adalah masalah arsitektur: kode yang berfungsi tetapi memperkenalkan utang teknis, melanggar pola yang sudah ditetapkan, atau akan menyulitkan perubahan di masa mendatang. Ini adalah yang tersulit untuk ditinjau karena memerlukan pemahaman baik kode yang ada maupun arah masa depan tim. Saya menemukan bahwa menganggap ini sebagai pertanyaan daripada perintah lebih berhasil: "Saya khawatir pendekatan ini mungkin menyulitkan penerapan fitur X pada kuartal depan—apakah Anda mempertimbangkan untuk menggunakan pola Y sebagai gantinya?" Ini mengundang diskusi daripada bersikap defensif.

Masalah Tingkat 3 adalah perbaikan keterbacaan dan pemeliharaan: nama variabel yang tidak jelas, kurangnya komentar pada logika kompleks, atau fungsi yang bisa dipecah untuk kejelasan. Ini penting, tetapi tidak mendesak. Saya biasanya membatasi diri pada tiga komentar Tingkat 3 per ulasan, fokus pada area yang akan memiliki dampak terbesar pada pemeliharaan di masa depan. Lebih dari itu, dan penulis akan kewalahan dan berhenti terlibat dengan umpan balik.

Tingkat 4 adalah semua hal lainnya: preferensi gaya, pendekatan alternatif yang tidak selalu lebih baik, atau nitpicks tentang format. Berikut adalah pendapat kontroversial saya: Anda hampir tidak pernah harus meninggalkan komentar Tingkat 4. Jika cukup penting untuk distandarisasi, tambahkan ke linter atau pedoman gaya Anda. Jika tidak cukup penting untuk diotomatiskan, tidak cukup penting untuk memperlambat permohonan tarik. Saya telah melihat tim menghabiskan berjam-jam berdebat apakah harus menggunakan tanda kutip tunggal atau ganda saat mengirimkan kode dengan kesalahan logika yang nyata. Jangan jadi tim itu.

Seni Komentar Konstruktif

Perbedaan antara komentar ulasan kode yang membantu dan yang meruntuhkan moral sering kali bergantung pada beberapa kata. Bandingkan dua komentar ini pada potongan kode yang sama:

"Fungsi ini terlalu panjang dan melakukan terlalu banyak hal." "Fungsi ini menangani baik validasi maupun transformasi data, yang membuatnya lebih sulit diuji setiap kepentingan secara terpisah. Pertimbangkan untuk membaginya menjadi validateUserInput() dan transformToApiFormat()—sehingga kami bisa menguji logika validasi tanpa perlu memalsukan transformasi, dan sebaliknya."

Komentar pertama secara teknis benar tetapi tidak berguna. Ini memberi tahu penulis apa yang salah tetapi tidak mengapa itu penting atau bagaimana cara memperbaikinya. Komentar kedua menjelaskan masalah, menggambarkan dampaknya, dan menyarankan solusi spesifik. Ini membutuhkan waktu saya