Empat Jenis Tinjauan Kode

Peninjauan kode telah berlangsung jauh sebelum model permintaan tarik. Berikut empat metode yang perlu diketahui untuk membantu tim Anda meninjau kode

Banyak insinyur yang telah membaca blog saya akan mengetahui bahwa saya berbicara banyak tentang tinjauan kode. Saya sangat yakin bahwa praktik peninjauan kode yang sehat adalah alat penting untuk membangun tim yang hebat. Membangun perangkat lunak yang hebat akan lebih mudah jika orang merasa cukup aman untuk mengajukan pertanyaan, bermurah hati dalam berbagi pengetahuan, dan menerima masukan. Tinjauan kode membantu membangun semua hal tersebut.

Namun banyak insinyur berasumsi bahwa satu-satunya cara untuk meninjau kode adalah melalui model permintaan tarik. Permintaan tarik adalah metode default untuk meninjau kode — "tulisan tentang tinjauan kode" saya juga berpusat pada model permintaan tarik, termasuk "buku saya yang akan datang!" — tapi ini bukan satu-satunya cara untuk meninjau kode.

Dalam artikel ini, saya ingin memberikan ikhtisar singkat tentang empat jenis tinjauan kode yang pernah saya lihat digunakan oleh tim. Tujuannya bukan untuk menunjukkan bahwa yang satu lebih baik atau lebih buruk dari yang lain; tujuannya adalah untuk menunjukkan bahwa masing-masing berbeda. Sebagai seorang insinyur, mengetahui kapan dan bagaimana memanfaatkan masing-masing metode ini dengan benar akan membantu karier Anda. Saya tahu mereka telah membantu saya.

Dimensi Tinjauan

Untuk membantu membandingkan masing-masing metode peninjauan kode ini, saya telah membuat beberapa grafik batang sederhana untuk membantu mengilustrasikan kinerja masing-masing metode pada beberapa dimensi. Berikut gambaran apa yang saya maksud dengan setiap dimensi yang saya visualisasikan.

Kecepatan

Kecepatan adalah kombinasi waktu tunggu dan waktu siklus. Waktu tunggu adalah waktu sejak penulis meminta peninjauan kode hingga mereka mendapatkan peninjauan pertama. Waktu siklus adalah total waktu antara saat peninjauan pertama kali diminta dan saat kode digabungkan. Semakin lambat metode peninjauan kode, semakin lama waktu yang dibutuhkan kode untuk mencapai produksi.

Ketelitian

Ketelitian adalah seberapa lengkap atau detail suatu metode peninjauan kode. Ketelitian berkorelasi langsung dengan ketelitian metode. Proses yang lebih rinci dan bersifat preskriptif sering kali lebih ketat dibandingkan proses yang aturan atau arahannya lebih sedikit. Semakin tinggi ketelitiannya, semakin besar kemungkinan review menemukan cacat atau bug.

Kolaborasi

Kolaborasi adalah seberapa baik metode memfasilitasi kolaborasi antara penulis dan reviewer. Hal ini tidak memperhitungkan apakah metode tersebut menggunakan alat online atau hanya mendorong orang untuk berbicara bersama. Sebaliknya, terlihat apakah metode ini memudahkan para insinyur untuk memberi dan menerima umpan balik satu sama lain.

Pelestarian Pengetahuan

Ini adalah seberapa baik metode tersebut mendokumentasikan keputusan atau hasil dari tinjauan kode. Misalnya: jika dua insinyur memutuskan untuk menerapkan implementasi tertentu dibandingkan yang lain, seberapa mudah insinyur lain dapat mengetahui mengapa keputusan tersebut dibuat? Pelestarian pengetahuan juga penting bagi para insinyur masa depan untuk mempelajari dan memahami basis kode baru.

Tarik Permintaan

Permintaan tarik adalah standar di industri. Awalnya diterapkan oleh GitHub, proses ini memungkinkan pengembang untuk mengelompokkan serangkaian perubahan kode (biasanya ke cabang) dan meminta agar pengelola (atau kolaborator) menarik atau menggabungkan kode mereka ke dalam cabang jalur utama.

Pengembang dapat mendiskusikan kode dengan meninggalkan komentar pada baris kode tertentu atau kode secara keseluruhan. Peninjau juga dapat menyetujui atau menolak perubahan dan memerlukan sejumlah persetujuan sebelum diizinkan untuk menggabungkan kode.

Banyak alat juga bekerja dengan baik dengan model permintaan tarik. Linter, pengujian otomatis, dll., semuanya dapat dijalankan dan melaporkan kembali status setiap tindakan pada permintaan penarikan — semuanya dengan tautan dan antrean visual. Pemeriksaan proses (apakah penulis ingat untuk memperbarui log perubahan atau menerapkan tag yang tepat) juga berguna di sini.

Permintaan tarik semakin populer karena bermanfaat untuk proyek sumber terbuka karena memfasilitasi kode dengan kepercayaan rendah dari repositori bercabang. Calon kontributor melakukan fork pada repo, membuat perubahan pada repo mereka, dan meminta pengelola untuk memasukkan kode mereka ke dalam repositori asli.

Dalam beberapa hal, permintaan penarikan serupa dengan tinjauan formal, karena setiap baris kode dapat ditinjau oleh peninjau. Namun, hal ini sangat bergantung pada ketelitian peninjau, karena prosesnya tidak ketat dalam menegakkan setiap baris yang ditinjau. Oleh karena itu, penilaiannya cukup tinggi dalam hal ketelitian tetapi di bawah tinjauan formal.

Permintaan penarikan umumnya cepat (walaupun ini merupakan perdebatan hangat) selama ukuran permintaannya tidak terlalu besar. Semakin besar permintaannya — biasanya diukur dengan perubahan total baris — semakin lama waktu yang dibutuhkan untuk menjalani peninjauan.

Permintaan tarik juga mendapat skor yang bagus dalam kolaborasi. Sebagian besar kolaborasi ini difasilitasi oleh alat yang dikembangkan oleh GitHub (atau penyedia SaaS git lainnya) untuk dengan mudah menyarankan perubahan baris atau mengomentari perubahan secara keseluruhan. Namun, banyak insinyur yang tidak menyukai “proses permintaan tarik”, dengan alasan bahwa sifat permintaan tarik yang tidak sinkron menyebabkan kelambatan tambahan dalam sistem (yang memang benar). Namun menurut pengalaman saya, waktu tunggu ini hanya berlaku ketika tim belum bekerja sama.

Salah satu bagian terbaik dalam menggunakan permintaan tarik adalah percakapan dapat dilihat oleh tim, dan bahkan berlangsung setelah peninjauan selesai. Hal ini memiliki manfaat yang sangat besar secara keseluruhan karena tim dapat (dan sering kali akan) memanfaatkan pull request untuk melihat perubahan apa yang terjadi dan juga menemukan pembelajaran atau diskusi seputar perubahan tersebut. Ini bukanlah rekor yang sempurna, tapi tentu saja membantu.

Ulasan Resmi

Tinjauan formal adalah bentuk peninjauan kode yang paling menuntut. Dalam tinjauan formal, tim insinyur memeriksa kode baris demi baris, mencari cacat atau kesalahan. Terkadang tim menggunakan salinan kode yang dicetak, meskipun praktik ini kurang umum di dunia yang sadar lingkungan.

Pendekatan umum terhadap tinjauan formal disebut “inspeksi Fagan” — sebuah proses yang dinamai insinyur perangkat lunak Micheal E. Fagan. Fagan adalah peneliti IBM dan pelopor inspeksi perangkat lunak. Tekniknya bersifat metodis dan preskriptif untuk setiap tahapan tinjauan dan cara pelaksanaannya, termasuk langkah-langkah sebelum dan sesudah setiap pertemuan di mana tinjauan sebenarnya dilakukan. Tidak semua tinjauan formal bersifat preskriptif seperti tinjauan Fagan, namun sering kali tinjauan tersebut memerlukan lebih banyak biaya daripada “hanya meninjau kode”.

Overhead ini menyebabkan tinjauan formal memakan waktu lebih lama dan kurang kolaboratif dibandingkan format tinjauan lainnya. Kita semua pernah merasakan betapa sulitnya menjadwalkan pertemuan dengan empat atau lima peserta yang menyebabkan waktu tunggu bertambah. Selain itu, setelah umpan balik diberikan, seorang insinyur mungkin dikirim untuk bekerja sendiri untuk menerapkan perubahan yang diperlukan. Mereka kemudian mengadakan pertemuan lain yang dijadwalkan untuk peninjauan putaran kedua. Rasanya seperti birokrasi yang tidak berguna di dunia perangkat lunak Agile modern…

Keunggulan tinjauan formal terletak pada ketelitian dan pelestarian pengetahuannya. Proses menelusuri kode secara metodis baris demi baris sering kali dapat menghasilkan pemahaman mendalam tentang basis kode dan penemuan kasus edge baru yang awalnya tidak terpikirkan. Proses peninjauan formal akan memastikan untuk mendokumentasikan setiap temuan ini — tidak hanya untuk diterapkan oleh pembuat kode tetapi juga untuk diketahui oleh pemilik produk, penguji, dan pemangku kepentingan lainnya.

Tinjauan formal kini sering kali dilakukan hanya untuk basis kode yang paling kritis dan sadar akan keselamatan. Mobil tanpa pengemudi, peralatan medis, dll., semuanya merupakan kandidat untuk tinjauan semacam itu.

“Di Atas Bahu”

Yang seharusnya adalah apa yang terdengar seperti ini: seorang insinyur mengundang seorang kolega untuk mengintip dari balik bahu mereka untuk memeriksa ulang pekerjaan mereka atau melihat masalah tertentu dengan mereka.

Meskipun metode ini mungkin tidak terasa seperti peninjauan kode, namun sebenarnya demikian. Seorang insinyur meminta insinyur lain untuk meninjau kode mereka untuk mendapatkan bantuan, arahan, atau bahkan persetujuan cepat.

Tinjauan menyeluruh dilakukan dengan cepat dan sering kali memerlukan upaya yang sangat rendah. Hal ini menjadikannya ideal untuk tim kecil dan erat yang bekerja bersama dalam produk atau proyek yang sama.

Namun, kecepatan ini juga mengakibatkan detailnya sering terlewat karena teknisi peninjau biasanya hanya berkata, “Hei, bisakah Anda segera melihat ini bersama saya?” Tergantung pada konteksnya, hal ini mungkin tidak perlu dikhawatirkan. Sebagian besar tim akan menggunakan metode peninjauan tambahan sebelum menggabungkan kode.

Menariknya, karena tinjauan menyeluruh sering kali berfokus pada kebutuhan atau masalah tertentu, tinjauan tersebut tidak mendorong banyak kolaborasi. Namun, hal ini mungkin mengarah pada penyusunan sesi pemrograman berpasangan, yang (seperti yang akan kita lihat selanjutnya) sangat kolaboratif.

Yang paling dirugikan dalam tinjauan over-the-shoulder adalah di bidang pelestarian pengetahuan. Jika sepasang insinyur menemukan sedikit pengetahuan baru saat bekerja bersama, tidak ada tempat alami untuk menyimpan pengetahuan tersebut (setidaknya tidak ada tempat yang dekat dengan kode). Bahkan jika ada, mungkin sulit untuk membuat pengetahuan tersebut dapat ditemukan oleh anggota tim lain karena konteksnya – perubahan yang sedang mereka kerjakan – dapat dengan mudah hilang.

Pemrograman Berpasangan

Pemrograman berpasangan mirip dengan tinjauan over-the-shoulder tetapi membutuhkan lebih banyak resep dan ketelitian. Dalam pemrograman berpasangan, dua insinyur bekerja sama pada bagian kode tertentu dengan peran dan tanggung jawab yang ditetapkan untuk bekerja sama. Mereka sering kali berada di lokasi yang sama, berbagi satu komputer tetapi masing-masing memiliki mouse dan keyboard sendiri.

Peran-peran ini sering disebut sebagai Pengemudi dan Navigator. Pengemudi bertanggung jawab untuk menulis kode, sedangkan Navigator mencari kesalahan kecil dan berpikir secara strategis tentang arah yang diambil kode tersebut. Seringkali sepasang insinyur bergiliran menjalankan peran masing-masing.

Salah satu ide utama pemrograman berpasangan adalah dengan meninjau kode pada saat penulisan, ada peluang lebih tinggi untuk mengetahui kerusakan lebih awal. Mengetahui kerusakan lebih awal berarti tim membangun kualitas ke dalam kode sejak awal, bukan mencoba memeriksa kode setelah kejadiannya. Ini berasal dari gagasan bahwa meninjau kode setelah ditulis sudah terlambat. Kutipan terkenal dari W. Edwards Demming membantu memperkuat perspektif ini.

Inspeksi terlambat. Kualitas baik atau buruk sudah ada pada produknya.

Pemrograman berpasangan adalah tentang bekerja bersama secara real-time untuk secara kolaboratif menemukan dan menyempurnakan kode berkualitas tinggi sebelum dimasukkan ke dalam basis kode. Seperti yang dikatakan Dragan Stepanović, “waktu optimal untuk meninjau setiap baris kode adalah segera setelah ditulis.”

Pemrograman berpasangan juga cenderung berjalan seiring dengan Pemrograman Ekstrim atau XP. Di XP, tim menggunakan integrasi berkelanjutan, pengembangan berbasis trunk, dan metode lain untuk mengoptimalkan kode pengiriman ke produksi secepat dan seaman mungkin. Pemrograman berpasangan bekerja dengan baik di XP karena dua insinyur dapat bekerja sama dalam sebuah pekerjaan kecil, memutuskan bahwa pekerjaan itu sudah siap, dan memasukkannya ke pekerjaan utama setelah selesai — mengandalkan rangkaian pengujian otomatis mereka untuk menggagalkan pembangunan sebelum melanjutkan ke produksi.

Seperti disebutkan sebelumnya, pemrograman berpasangan dapat dilihat sebagai tinjauan menyeluruh yang diformalkan. Oleh karena itu, ia memiliki peringkat kecepatan yang tinggi karena terdapat putaran umpan balik yang cepat. Hal ini lebih baik daripada tinjauan menyeluruh mengenai kolaborasi, meskipun hal ini lebih dari sekedar pemeriksaan singkat terhadap satu baris solusi lengkap yang ditulis oleh kedua peserta.

Ia juga memiliki banyak kelemahan yang sama. Pemrograman berpasangan cenderung tidak selengkap tinjauan formal atau permintaan tarik. Ya, kode tersebut segera ditinjau, dan kedua teknisi sedang mencari bug. Namun, karena percakapan sering kali terjadi dalam waktu nyata, dan rasa lelah itu nyata, saya telah melihat banyak sesi penyandingan yang berfokus pada menyelesaikan sesuatu sehingga kasus tepi terabaikan atau sudut terpotong . Hal ini tidak selalu salah, namun memiliki buffer waktu dapat memungkinkan pemikiran yang lebih mendalam tentang kode dan implikasinya terhadap produk dan dapat mendasari bahwa loop umpan balik real-time mungkin tidak mengizinkannya.

Memasangkan juga tidak menyelesaikan masalah pelestarian pengetahuan. Dua insinyur (atau mungkin lebih jika memanfaatkan [pemrograman massa]) dapat memutuskan kode untuk memfaktorkan ulang sesuatu tetapi tidak pernah mempublikasikan ke seluruh tim mengapa keputusan itu dibuat. Jika anggota tim lain mencoba memahami perubahan tersebut, mereka mungkin harus meminta salah satu teknisi tersebut untuk menjelaskan alasannya.

Gunakan Setiap Metode Saat Dipanggil

Fiuh! Itu banyak sekali! Terima kasih sudah bertahan di sana.

Semua ini berarti bahwa masing-masing metode memiliki kekuatan dan kelemahan yang berbeda. Terserah Anda dan tim Anda untuk menggunakannya sesuai kebutuhan saat Anda membangun perangkat lunak. Tim Anda mungkin tertarik pada permintaan tarik (yang umum terjadi) dan menggunakan pemasangan pada pekerjaan yang kompleks atau untuk mempercepat pekerjaan tertentu. Tinjauan formal hanya dapat digunakan pada sesuatu yang baru dan seluruh tim memerlukan pemahaman mendalam tentang apa yang dilakukan kode tersebut.

Tapi mereka semua berharga dalam dirinya sendiri.

Selamat membuat kode! (dan mengulas!)

Berikut adalah perbandingan berdampingan mengenai peringkat masing-masing metode dalam hal kecepatan, ketelitian, kolaborasi, dan pelestarian pengetahuan:

Awalnya diterbitkan di https://dangoslen.me.