Seorang pengembang membuka permintaan pull request yang menambahkan perhitungan diskon ke layanan pembayaran. Tes berhasil dan perbedaannya kecil. Seorang peninjau menyetujuinya dalam dua menit dengan "LGTM". Tiga bulan kemudian, seorang rekan tim perlu mengubah fungsi yang sama dan menemukan bahwa fungsi tersebut mencampur aturan penetapan harga, pembulatan, dan akses basis data di satu tempat. Tidak ada yang dapat mengatakan dengan yakin apa yang diperbolehkan untuk dilakukan.
Ini adalah skenario ilustratif, bukan insiden yang terdokumentasi. Ini menunjukkan apa yang harus dihasilkan oleh tinjauan kode sejawat ketika berfungsi sebagai aktivitas pembelajaran: seorang peninjau yang dapat melihat perubahan yang masuk akal, menemukan masalah yang belum menjadi bug, dan menjelaskannya dengan cara yang dapat ditindaklanjuti oleh penulis.
Panduan ini ditujukan untuk pimpinan pemberdayaan teknik dan manajer teknik. Panduan ini menunjukkan cara mendesain. latihan tinjauan kode yang membangun keterampilan itu secara sengaja, alih-alih berharap peninjau akan menemukannya secara otomatis. Ini mencakup masalah kinerja, celah yang perlu didiagnosis, cara menyusun persiapan dan latihan, satu contoh yang dikerjakan, dan cara memeriksa apakah keterampilan tersebut dapat diterapkan pada peninjauan sebenarnya. Mintalah insinyur senior untuk memvalidasi setiap kasus, cacat, dan kriteria sebelum Anda menggunakannya.
Apa itu latihan tinjauan kode?
Latihan tinjauan kode adalah tugas praktik terstruktur di mana seorang pengembang meninjau perubahan yang telah disiapkan, menjelaskan apa yang mereka temukan dan mengapa hal itu penting, serta mendapatkan umpan balik tentang kualitas penjelasan tersebut. Latihan ini berbeda dari tinjauan yang dilakukan tim Anda setiap hari. Perubahan dipilih terlebih dahulu, masalah yang ada di dalamnya diketahui, dan tujuannya adalah untuk meningkatkan kemampuan peninjau, bukan untuk langsung merilis perubahan tersebut.
fakta cepat
| Pertanyaan | Jawaban singkat |
|---|---|
| Apa tugasnya? | Jelaskan temuan ulasan dan berikan umpan balik yang dapat ditindaklanjuti oleh penulis. |
| Berapa skor Anda? | Keakuratan temuan dan seberapa bermanfaat penjelasannya. |
| Apakah menghitung cacat saja sudah cukup? | Tidak. Ulasan bukan hanya tentang kekurangan, jadi latihan yang hanya memberi penghargaan berdasarkan jumlah bug akan melatih kebiasaan yang salah. |
| Apa tuntutan kognitifnya? | Analisis dan evaluasi sebuah desain, lalu buatlah saran yang lebih baik. |
| Siapa yang memvalidasi kasus tersebut? | Seorang manajer teknik atau insinyur senior yang bertanggung jawab atas basis kode tersebut. |
| Apa yang tidak bisa diperbaiki oleh olahraga? | Waktu peninjauan, kepemilikan yang tidak jelas, dan tekanan untuk segera melakukan merger. |
| Bagaimana Anda tahu itu berhasil? | Perubahan baru yang belum pernah dilihat sebelumnya ditinjau berdasarkan kriteria yang disepakati, ditambah tindak lanjut dari tinjauan yang sebenarnya. |
1. Jelaskan masalah kinerja tersebut
Mulailah dengan tugas, dalam satu kalimat: jika ada perubahan, peninjau menjelaskan apa yang mereka temukan, mengapa itu penting, dan apa yang dapat dilakukan penulis untuk mengatasinya. Kata "menjelaskan" adalah kata kunci. Menemukan masalah adalah setengah dari keterampilan. Menyampaikannya sehingga kolega dengan pandangan berbeda dapat memahaminya, mempertimbangkannya, dan bertindak adalah setengah lainnya.
Penelitian tentang tinjauan kode modern mendukung upaya untuk melihat lebih dari sekadar pencarian bug. Dalam sebuah studi di Microsoft, Bacchelli dan Bird mengamati, mewawancarai, dan mensurvei pengembang dan manajer. Mereka menemukan bahwa menemukan cacat masih menjadi motivasi utama untuk tinjauan, tetapi tinjauan tersebut kurang berfokus pada cacat daripada yang diharapkan orang. Tinjauan tersebut juga memberikan manfaat lain, seperti berbagi pengetahuan, kesadaran tim, dan solusi alternatif, dan para peneliti menggambarkan pemahaman kode dan perubahan sebagai aspek kunci dari tinjauan.Bacchelli dan Bird, ICSE 2013Ini adalah studi tentang tim-tim di satu perusahaan, jadi gunakanlah sebagai alasan untuk merancang agar mudah dipahami, bukan sebagai tolok ukur untuk perusahaan Anda.
Standar peninjauan yang diterbitkan Google menunjukkan hal yang sama. Standar tersebut menyarankan para peninjau untuk lebih memilih menyetujui perubahan jika perubahan tersebut secara pasti meningkatkan kesehatan kode secara keseluruhan, meskipun tidak sempurna, dan menyatakan bahwa peninjauan dapat mengajarkan sesuatu yang baru kepada pengembang, sehingga komentar yang membantu seseorang belajar sangat disamb欢迎.Praktik Rekayasa GoogleKedua sumber tersebut mendeskripsikan peninjauan sebagai tempat di mana penilaian dilakukan dan diteruskan. Itulah yang harus Anda latih dalam latihan Anda.
2. Mendiagnosis kesenjangan pembelajaran dan konteks.
Bandingkan tugas tersebut dengan apa yang dipraktikkan dan dinilai dalam program Anda saat ini.
- Apakah praktik saat ini menggunakan tugas yang sebenarnya? Jika reviewer baru belajar dengan membaca panduan gaya dan kemudian meninjau permintaan perubahan (pull request) yang sedang berjalan, mereka berlatih pada pekerjaan nyata tanpa ada tempat aman untuk melakukan kesalahan. Jika penilaian berupa kuis tentang etika peninjauan, itu hanya mengukur kemampuan mengingat aturan, bukan kemampuan untuk menerapkannya pada suatu perubahan.
- Apa tuntutan kognitifnya? Dalam taksonomi Bloom yang direvisi, menilai apakah suatu desain itu baik dan mempertimbangkan komprominya berada pada tingkat analisis dan evaluasi, sedangkan mengusulkan struktur yang lebih baik mencapai tingkat kreasi. Jika latihan Anda hanya menanyakan "apa yang dilakukan kode ini?", maka latihan tersebut berhenti pada pemahaman. Panduan kami untuk Mencocokkan aktivitas pembelajaran dengan Taksonomi Bloom Menunjukkan cara mencocokkan aktivitas dengan level.
- Apakah ada hal lain selain keterampilan yang menjadi penghalang? Periksa waktu peninjauan, alat bantu, kepemilikan, dan norma tim. Jika peninjau hanya memiliki lima menit per permintaan perubahan, tidak akan ada penjelasan yang matang. Jika penulis menganggap setiap komentar sebagai kritik, peninjau akan melunakkan temuan mereka hingga akhirnya tidak mengatakan apa pun. Laporkan penyebab ini kepada orang-orang yang dapat memperbaikinya.
3. Persiapan desain, praktik, dan umpan balik
Berikan tugas terpisah untuk setiap tahapan.
Persiapan. Periksa apa yang dibutuhkan peninjau sebelum mereka mulai: daftar periksa peninjauan tim, prinsip-prinsip desain yang digunakan, dan cara membaca perbedaan (diff) dalam alat bantu Anda. Lakukan ini dengan kecepatan sendiri dan singkat. Pemeriksaan ulang hanya mengkonfirmasi prasyarat, dan bukan bukti bahwa seseorang mampu melakukan peninjauan.
Praktek. Gunakan perubahan yang sudah disiapkan dengan sejumlah kecil masalah yang telah ditentukan sebelumnya dari berbagai jenis: bug kebenaran, masalah pemeliharaan seperti tanggung jawab yang bercampur dalam contoh pembuka, nama yang tidak jelas atau pengujian yang hilang, dan beberapa kode yang baik. Mintalah peninjau untuk menulis komentar yang akan mereka berikan, memberi peringkat pada masalah tersebut, dan menyatakan informasi lebih lanjut apa yang mereka inginkan. Pelajaran praktik CodeRefinery menunjukkan bentuknya: orang membuka permintaan pull yang berisi kesalahan ketik kecil dan kesalahan yang lebih besar, kemudian meninjaunya sebagai rekan sejawat (CodeRefinery, Mempraktikkan tinjauan kodeBangunlah milik Anda dari basis kode Anda sendiri sehingga konvensi dan pertimbangannya benar-benar nyata.
Umpan balik. Hubungkan dengan keputusan yang dibuat oleh penilai. "Anda memperhatikan masalah pembulatan tetapi komentar Anda mengatakan 'ini terlihat salah' tanpa menyebutkan input apa yang menyebabkan kesalahan" lebih bermanfaat daripada "menemukan 2 dari 4".
Masukan langsung atau tinjauan asinkron? Masukan langsung memberikan nilai tambah terbesar ketika suatu masalah bersifat ambigu dan peninjau belajar dari penjelasan seorang insinyur senior tentang mengapa mereka mengangkat masalah tersebut, atau mengabaikannya. Peninjauan asinkron sudah cukup untuk membandingkan komentar dengan peninjauan ahli yang diberi anotasi.
4. Kerjakan contoh yang realistis.
Sebagai ilustrasi. Manajer teknik harus memvalidasi kasus dan kriteria jawaban sebelum digunakan.
Kasus. Perubahan ini menambahkan perhitungan diskon ke layanan pembayaran. Perubahan ini lolos uji. Dalam satu fungsi, perubahan ini menerapkan diskon persentase dan diskon tetap, membulatkan hasilnya, menulis ke basis data, dan mengirimkan sebuah event. Perubahan ini memiliki satu pengujian, untuk diskon persentase tunggal.
Tugas tersebut. Peninjau menuliskan komentar yang akan mereka berikan, memberi peringkat pada kekhawatiran mereka, dan menyatakan apa yang perlu mereka ketahui sebelum menyetujui.
Upaya pertama. "Terlihat baik-baik saja, tesnya lolos. Mungkin bisa dipisah-pisahkan?" Peninjau telah memperhatikan sesuatu tetapi belum mengatakan apa, mengapa itu penting, atau apa yang harus dilakukan. Penulis tidak dapat mengambil tindakan atas hal ini.
Berikan masukan dan coba lagi. Fasilitator bertanya: perubahan apa di masa mendatang yang berisiko merusak fungsi ini? Apa yang akan Anda minta penulis tambahkan sebelum Anda menyetujuinya? Percobaan ulang meminta komentar spesifik untuk setiap masalah, beserta alasannya dan sebuah saran.
Upaya yang lebih baik. "Fungsi ini menerapkan dua jenis diskon, pembulatan, penyimpanan, dan mempublikasikan sebuah event, jadi perubahan pada pembulatan dapat mengubah apa yang kita simpan dan apa yang kita publikasikan secara bersamaan. Saya ingin meminta agar aturan penetapan harga dipindahkan ke fungsi murni yang dapat kita uji sendiri. Tes tunggal hanya mencakup diskon persentase. Saya ingin meminta diskon tetap dan pesanan yang membuat totalnya menjadi nol. Saya tidak yakin apakah event tersebut dimaksudkan untuk dijalankan ketika totalnya nol, jadi saya akan menanyakan hal ini kepada penulis." Perhatikan bahwa komentar ini menyebutkan masalahnya, memberikan alasannya, memberikan saran konkret, dan menyatakan apa yang tidak diketahui oleh pengulas.
5. Menilai kemampuan dan merencanakan transfer
Bukti kemampuan adalah kinerja pada perubahan baru yang belum pernah dilihat oleh penilai. Beri nilai pada keakuratan temuan dan kegunaan penjelasan. Rubrik sederhana menggunakan skala 0 hingga 2 per kriteria:
| Kriterium | Bukti yang dapat diamati |
|---|---|
| Eksekusi tugas | Mengidentifikasi hal-hal yang menjadi perhatian terkait perubahan tersebut dan mencatat bukti untuk setiap hal yang menjadi perhatian. |
| Pemikiran | Menjelaskan mengapa setiap kekhawatiran itu penting, menawarkan alternatif, dan menyebutkan apa yang masih belum pasti. |
| Batas | Mematuhi aturan peninjauan tim dan meminta bantuan atau informasi ketika wewenang atau konteks tidak tersedia. |
Nilai acuan: 0 berarti tidak ada atau tidak didukung, 1 berarti sebagian dengan kekurangan yang relevan, dan 2 berarti lengkap dan dibenarkan berdasarkan kriteria yang disepakati. Definisikan kesalahan kritis secara terpisah, misalnya menyetujui perubahan dengan risiko kehilangan data, sehingga skor keseluruhan yang baik tidak dapat menyembunyikan satu kesalahan. Sesuaikan kriteria dengan manajer teknik; rubrik ini adalah usulan awal, bukan standar kesiapan yang telah divalidasi. Untuk informasi lebih lanjut tentang penalaran penilaian, lihat panduan kami tentang merancang praktik interaktif dengan umpan balik yang bermanfaat.
Rencanakan transfer. Setelah latihan, periksa sampel ulasan sebenarnya dari penilai beberapa minggu kemudian, menggunakan kriteria yang sama. Bandingkan dengan data dasar yang diambil sebelum pelatihan dan tentukan populasi serta waktunya di awal. Perhatikan perubahan lain yang terjadi pada periode yang sama, seperti alat peninjauan baru atau perubahan staf, sebelum memberikan kredit pada latihan tersebut.
6. Lakukan latihan secara langsung atau sesuai kecepatan Anda sendiri dengan AhaSlides.
Anda dapat menjalankan latihan ini dalam lokakarya atau membiarkan peninjau mengerjakannya sendiri. Dalam sesi langsung, tunjukkan perubahan yang telah disiapkan dan gunakan slide interaktif untuk diskusi:
- Pilih Jawaban Untuk pertanyaan "kekhawatiran mana yang akan Anda sampaikan terlebih dahulu?", dengan kekhawatiran yang telah ditentukan sebagai pilihan. Tunjukkan sebaran jawabannya sebelum Anda mengungkapkan peringkat Anda sendiri.
- Terbuka Berakhir untuk "tulis komentar yang akan Anda berikan". Peninjau dapat membandingkan susunan kata mereka dengan yang lain, di situlah kemampuan menjelaskan terlihat.
- Skala Peringkat untuk pertanyaan "seberapa parahkah ini?", sehingga kelompok tersebut dapat melihat di mana penilaian berbeda dan mendiskusikan alasannya.
Bagi peninjau yang tidak dapat hadir, urutan yang sama dapat digunakan secara mandiri, dengan ulasan ahli yang diberi anotasi ditampilkan setelah setiap tanggapan. Perlakukan setiap klaim tentang eksekusi kode, integrasi, atau fitur AI sebagai belum terkonfirmasi sampai Anda mencobanya dengan materi Anda sendiri.
Jika Anda juga melatih peninjau kode yang ditulis oleh AI, lihat panduan pelengkap kami tentang hal tersebut. Pelatihan peninjauan kode yang dihasilkan AIPostingan itu membahas tentang audit output yang dihasilkan. Postingan ini membahas tentang bagaimana orang meninjau pekerjaan satu sama lain, dan bagaimana mereka menjelaskan temuan mereka.
Kendala yang mungkin masih ada
- Waktunya ulasan. Komentar yang bij thoughtful membutuhkan waktu lebih lama daripada "LGTM", dan tenggat waktu mendorong versi yang lebih singkat.
- Norma tim. Jika umpan balik dibaca sebagai kritik pribadi, para penilai akan melunakkan atau mengabaikan temuan mereka.
- Liputan kasus. Satu latihan menunjukkan beberapa jenis kekhawatiran. Skor tidak menggambarkan penilaian penilai secara umum.
- Transfer. Performa di sebuah lokakarya tidak sama dengan performa di antrian yang ramai, jadi periksa juga ulasan yang sebenarnya.
Sebutkan hal-hal ini kepada sponsor sejak dini dan rencanakan perbaikan terpisah. Latihan meningkatkan apa yang dapat dilihat dan dijelaskan oleh peninjau. Latihan tidak menciptakan waktu atau norma.
Pertanyaan yang sering diajukan
Apa itu latihan tinjauan kode?
Ini adalah tugas latihan yang telah disiapkan di mana seorang pengembang meninjau perubahan dengan masalah yang diketahui, menulis komentar yang akan mereka berikan, dan mendapatkan umpan balik tentang keakuratan dan kegunaannya. Tujuannya adalah untuk membangun keterampilan peninjau, bukan untuk merilis perubahan tersebut.
Bagaimana Anda menilai apakah penilaian seorang pengulas telah membaik?
Berikan perubahan baru yang belum pernah mereka lihat dan beri nilai pada temuan dan penjelasannya berdasarkan kriteria yang telah disepakati. Kemudian periksa sampel ulasan nyata beberapa minggu kemudian. Kuis tentang aturan ulasan hanya mengkonfirmasi prasyarat.
Apakah peninjauan kode oleh rekan sejawat terutama bertujuan untuk menemukan bug?
Menemukan cacat tetap menjadi motivasi utama, tetapi sebuah studi di Microsoft menemukan bahwa ulasan ternyata kurang berfokus pada cacat daripada yang diperkirakan, dan juga memberikan berbagi pengetahuan serta kesadaran tim. Rancang latihan yang memberikan penghargaan atas penjelasan dan pemahaman serta jumlah cacat.
Mulai dari mana
Pilih satu jenis perubahan yang sering ditinjau tim Anda. Tulis pernyataan kinerja, minta seorang insinyur senior untuk menyiapkan satu perubahan dengan tiga atau empat masalah yang telah ditentukan, dan susun rubrik tiga kriteria dengan skala 0 hingga 2 dan daftar kesalahan kritis. Uji coba dengan kelompok kecil, lalu bandingkan tinjauan sebenarnya berikutnya dengan tolok ukur tersebut.
Untuk melihat bagaimana latihan peninjauan dapat dijalankan secara langsung dengan tim Anda sendiri, dan digunakan kembali secara mandiri setelahnya, jelajahi AhaSlides.
