Pada sekumpulan tim berisi programmer, baik itu tim yang memiliki sedikit maupun ratusan programmer. Umumnya disana terdapat pemantau isi kode sebuah project, reviewer. Pemantau ini akan melihat bagaimana perubahan kode yang dilakukan oleh seorang programmer, sekaligus memberikan catatan penting kode yang harus diperbaiki sebelum dilakukan deploy.
Seorang author pada lifecycle Code Review adalah programmer, dan reviewer adalah seorang yang melakukan review terhadap kode yang digubah atau dibuat oleh author.
Secara istilah yang lebih definitif, Code Review adalah sekumpulan aktifitas yang dilakukan untuk membaca kode, memberikan masukan, termasuk komentar mengenai perbaikan kode dari rekan satu tim. Atau dalam beberapa sumber Code Review bisa diartikan sebagai sebuah pertemuan biasanya terdiri dari seluruh anggota tim, untuk membaca secara detail kode baris demi baris dari tim itu sendiri.
Perjalanan sebuah kode hingga bisa sampai pada proses deploy ke production, akan selalu melalui media repository, dalam kasus ini media tersebut adalah Git, SVN, maupun Mercurial.
Sebuah proses Code Review umumnya juga dilakukan pada media repository misalnya Git, karena fitur Git memiliki sebuah fungsi untuk memberikan komentar terhadap baris kode yang dirubah maupun yang ditambahkan pada sebuah project.
Jalan Cerita Sebuah Code Review
Pertama, sebuah tim yang memiliki 2 orang programmer dengan 1 reviewer didalamnya akan melakukan sebuah penambahan fitur baru pada program yang mereka bangun. Karena fitur tersebut merupakan penambahan skala besar, maka tim di breakdown menjadi 2 tim lagi,
- 1 programmer untuk sub fitur A
- 1 programmer lagi untuk sub fitur B
- sisanya 1 reviewer yang akan mereview kedua sub fitur tersebut.
Dari kedua sub fitur A dan B nantinya akan digabungkan menjadi fitur yang akan ditambahkan pada project program yang sudah ada.
Kedua, tim sudah terbagi dan saatnya membuat dua buah Branch pada Git dan dari Branch tersebut dibuatlah sebuah Merge Request (MR) atau Pull Request (PR). MR atau PR adalah sebuah wadah yang berisi deskripsi sub fitur A maupun B selain itu juga berisi perubahan commit per push oleh masing-masing programmer.
Dalam kasus selanjutnya, programmer yang mengerjakan sub fitur A telah menyelesaikan keseluruhan pembuatan sub fitur tersebut menurut pandangan dirinya. Kode telah berada pada Branch sub fitur A dan siap untuk dilakukan review oleh reviewer.
Ketiga, sub fitur A yang telah selesai dilakukan review oleh reviewer pada bagian PR di jendela Git. Reviewer melakukan cloning dan menguji jalannya sub fitur A, sekaligus membaca baris per baris kode. Semuanya tampak lancar dan berjalan sempurna, namun terdapat sebuah bug pada baris tertentu.
Bug tersebut suatu saat akan mengakibatkan sub fitur A kemungkinan terjadi masalah jika dilakukan merge ke Branch utama, yakni Master.
Pada proses ini, seorang reviewer kemudian menandai baris kode yang menjadi bug tersebut. Selain itu juga, reviewer akan meninggalkan komentar tentang bug dan umumnya ditambah dengan komentar bersifat solutif. Semua itu dilakukan pada jendela MR atau PR pada Git.
Proses perubahan maupun penambahan oleh author/programmer pada step ketiga ini dapat diartikan sebagai Changelist, dalam bahasa inggris.
Keempat, bug yang menjadi masalah tersebut dan telah dikomentari reviewer akan dengan mudah diketahui oleh author atau programmer sub fitur A melalui jendela MR / PR. Sehingga programmer akan membaca secara saksama dan melakukan uji coba kembali sub fitur A, diikuti dengan perbaikan.
Perbaikan tersebut akhirnya diterima kembali oleh reviewer pada jendela MR / PR. Setelah diuji dan dilihat kembali oleh reviewer, sub fitur A siap ‘dikapalkan’ menuju branch Master, tentu saja menunggu sub fitur B yang juga memiliki jalan cerita sama persis dengan sub fitur A.
Oleh beberapa pelaku Code Review, step berakhirnya review ini sehingga fitur siap dideploy disebut dengan LGTM, dalam bahasa inggris berarti Looks Good To Me (LGTM). Atau dalam bahasa jawa bisa kita sebut sebagai LeGit To Me. 😀
Kelima, baik sub fitur A dan B telah dibuat oleh masing-masing programmer, kemudian direview oleh reviewer dan semuanya tampak sempurna. Langkah selanjutnya adalah menggabungkan ‘merge’ kedua branch yakni sub fitur A dan B menjadi satu fitur dan kemudian digabungkan kedalam branch Master menuju kepada deployment production ready.
Nilai Plus dan Kegunaan Code Review
Code Review adalah hal yang wajib dilakukan pada sebuah tim yang sangat besar. Sebelum hasil perbaikan maupun penambahan fitur project tersebut disampaikan kepada ‘misalnya’ seorang Product Manager.
Ada beberapa kegunaan dan nilai tambah sebuah project yang memiliki siklus Code Review, diantaranya:
- Bug maupun Fitur dapat terdefinisi dengan baik melalui branch masing-masing pada MR / PR.
- Meminimalisir kesalahan fitur project yang terjadi pada sisi production karena telah dilakukan uji coba, baik oleh author/programmer maupun reviewer.
- Kerapian dan keterjaminan kualitas kode masing-masing fitur sekaligus meminimalisir kesemrawutan pada hasil koding, karena reviewer biasanya memiliki batasan-batasan yang harus dimiliki pada kode yang reviewer terima.
- Siklus project dan penambahan fitur dapat dipertanggung jawabkan secara lebih detail karena adanya MR / PR.
- Tidak ada programmer yang sempurna, untuk itu suatu code review dipakai sebagai proses untuk mengkoreksi, memperbaiki dan merevisi suatu kode yang ditulis programmer.