Ketika membuat program yang dikembangkan oleh lebih dari satu pengembang, aktivitas code review umumnya pasti terjadi. Namun sebelum kita membahas lebih lanjut tentang itu, mari kita bahas tentang bagaimana jika tidak melakukan code review?

Berbicara secara pribadi, tidak sedikit teman-teman di kampus dulu yang belum familiar dengan code review.

Mungkin beberapa ada yang sampai sekarang?

Dan itu dapat dimengerti.

Mari kita ilustrasikan.

Kamu sedang mengembangkan sebuah program, misal aplikasi kasir.

Kamu buka Sublime Text 3, membuat beberapa berkas kode, mungkin {index,model,view,controller}.php, lalu membuat fitur utama: Otentikasi.

Di hari setelahnya, kamu membuat fitur-fitur lain seperti sistem inventory; analitik, dsb.

Lalu kamu sudah mulai kesulitan, kode semakin banyak; fitur semakin berkembang, dan fokus kamu mulai banyak dihabiskan ke bagian bisnis. Kamu membutuhkan pengembang lain yang membantu untuk mengembangkan aplikasi yang sedang dikembangkan tersebut.

Setelah mendapat pengembang lain, proses pengembangan berjalan seperti biasa.

Sekarang kamu bisa fokus ke kebutuhan bisnis, dan pengembang tersebut yang menerjemahkannya ke hal teknis.

Lalu si pengembang utama mulai kesulitan sebagaimana apa yang terjadi pada pengembang pertama. Ketika mendapatkan pengembang tambahan, pertanyaan pertama yang muncul adalah: Bagaimana cara agar program ini dapat dikembangkan oleh 2 pengembang?

Mungkin dengan cara kode tersebut disimpan di remote (dev) server lalu para pengembang tinggal ssh dan attach ke sesi tmux yang sama?

Anggap pertimbangan diatas berjalan dengan baik. Lalu setelah 3 bulan, kita memutuskan untuk mencari pengembang lain.

Mungkin sekarang butuh 2 pengembang tambahan?

Total pengembang sekarang ada 4, dengan 1 sesi tmux yang sama, proses pengembang seperti sedang melakukan peer programming yang dilakukan selamanya.

...yang bedanya, tidak ada pengemudi dan penumpang. Semuanya menjadi pengemudi!

Lalu beberapa masalah teknis yang tidak berhubungan dengan bisnis secara langsung mulai muncul. Baik di skala kecil ataupun besar, yang paling umum adalah 'Siapa yang menulis kode ini?'. Bukan untuk menyalahkan, hanya untuk mengetahui apa alasan melakukan hal tersebut, entah karena kode tersebut menyebabkan kesalahan; sudah tidak digunakan lagi, menyebabkan penurunan performa, apapun.

Dan tentu saja menggunakan 1 sesi tmux yang sama hanyalah sebuah mimpi indah bila tidak ada masalah, karena sekali seseorang membuat kesalahan—yang padahal salah satu pengembang sedang tidak menyentuh kode tersebut—maka dampaknya dirasakan oleh semua pengembang.

Lalu alur kerja mulai berubah, setiap pengembang menyimpan sumber kodenya di mesin lokal mereka, dengan sebuah sihir (baca: rsync) kode yang mereka tulis di lokal akan disingkronisasi ke tempat "sentral" yakni di remote (dev) server sebelumnya.

Pengembang merasakan pengalaman yang seperti sebelumnya, namun dengan lingkungan pengembangan yang ter-isolasi!

Tentu saja pendekatan menggunakan alur kerja diatas terlalu indah untuk terjadi dengan tanpa ada masalah. Banyak masalah yang dapat ditulis disini, namun yang paling pasti terjadi adalah 'konflik' terhadap berkas yang berubah, dan biasanya, perubahan terakhirlah yang menang!

Lalu pada sekitar Juli 2005, seorang random bernama Linus mengembangkan sebuah program bernama git, yang meskipun program serupa sudah ada terlebih dahulu seperti Subversion pada Februari 2004 dan Mercurial pada April 2005.

Program tersebut adalah sebuah sistem kontrol versi, atau pengatur versi bila menggunakan bahasa sederhananya. Alur kerja dari program tersebut hampir sama ketika menggunakan rsync, bedanya, setiap perubahan selalu terlacak dan karena itu dapat menyelesaikan masalah 'konflik' tersebut.

Jadi, sudah tidak berlaku lagi 'the last wins' melainkan menjadi 'yang terakhir lah yang akan pusing' karena harus berurusan dengan konflik hahaha.

Ketika menggunakan git, alur kerja menjadi berubah. Setiap pengembang sekarang peduli dengan perubahan yang terjadi. Dan kabar baiknya (atau buruk?), setiap pengembang dapat mengetahui siapa yang melakukan apa.

Jadi tidak perlu melakukan emergency meeting untuk mencari pelaku!

Dan itulah tujuan utama git: Mengatur versi.

Karena bukankah setiap perubahan berarti membuat versi yang berbeda, bukan?

Git, idiomatically

Sebelum membahas lebih lanjut lagi, mari kita cari tahu bagaimana git digunakan oleh pembuat dari git.

Git utamanya digunakan untuk mengembangkan kernel, sebuah program random yang mentenagai sebagian besar komputer-komputer yang ada di dunia, dan mungkin termasuk komputer kamu.

Ada lebih dari 48rb berkas kode C yang ada di kernel, dan ada lebih dari 10rb kontributor yang ikut membantu dalam mengembangkan kernel.

Pertanyaannya, bagaimana cara mengatur proses pengembangan dan rilis di skala tersebut?

Siapa yang memastikan program tersebut tetap berjalan sebagaimana mestinya, selain test yang ditulis?

Siapa yang memelihara kode tersebut agar sesuai standar?

Siapa yang menerapkan perubahan yang dilakukan oleh kontributor?

Berbicara spesifik tentang kernel, orang tersebut adalah Linus, seorang pemelihara utama.

Setiap perubahan yang terjadi, akan di review oleh pemelihara yang bertanggung jawab (subsystem maintainers), yang dipercaya oleh Linus.

Yang singkatnya, hanya Linus yang dapat mengubah kode-kode (merge) yang ada di mainline/upstream repositori kernel karena sebuah alasan.

Entah proses merge tersebut dengan cara menerapkan patch files ataupun Pull/Merge request, 2 pendekatan tersebut sama-sama melakukan 1 hal: Code Review.

Tapi kita sedang tidak mengembangkan kernel, jadi, gambaran diatas hanya sebagai ilustrasi sedikit tentang bagaimana git digunakan untuk mengembangkan kernel.

Kita disini tidak membahas tentang git secara mendalam, jika tertarik, bisa baca Git untuk orang sibuk atau buku dari salah dua pemelihara proyek git yang berjudul Pro Git yang bisa dibaca secara daring.

Tentang code review

Kita sudah mulai masuk ke pembahasan utama.

Proses code review biasanya berawal dari pengembang membuat perubahan, menjelaskan perubahan tersebut melalui "commit message", lalu mengirimkan perubahan tersebut ke remote server yang menyimpan repositori/remote repositori.

Lalu setelah perubahan dikirim, pengembang membuat Pull/Merge Request yang menandakan bahwa perubahan tersebut ingin diterapkan ke kode utama yang biasanya berada di cabang bernama main/master.

Di Pull/Merge Request, pengembang umumnya menjelaskan tentang perubahan apa yang dia buat—mungkin menyisipkan video juga sebagai demonstrasi—dan biasanya di PR/MR tersebut dijelaskan commit message apa saja yang terjadi; berkas apa saja yang berubah, dan statistik kecil terkait perubahan yang terjadi.

Yang me-review perubahan tersebut biasanya seseorang yang mengembangkan program tersebut juga. Mungkin tim frontend, backend, engineering, apapun.

Dan tergantung dari budaya yang dimiliki, apa yang membuat perubahan tersebut dapat dianggap sebagai 'dapat diterapkan' ke kode utama. Entah harus diterima oleh 2 pemelihara, entah harus berhasil ketika peladen CI melakukan pengujian, apapun.

Namun pertanyaannya adalah: apa yang terjadi ketika 'code review' dan apa yang dilakukan oleh 'reviewer'?

Mencari kesalahan?

Ini terdengar lumayan menyeramkan, namun tidak 100% salah juga.

Terkadang ada beberapa hal yang kita lewati, dan bukan tanpa alasan beberapa organisasi memiliki tim QA sekalipun proses pengembangan sudah sangat ketat.

Manusia adalah tempat salah dan lupa, katanya.

Jika orang QA biasanya memastikan kualitas secara high-level, tim pengembang memastikannya secara lower-level.

Mungkin pengembang lupa membuat komentar tentang apa yang dia lakukan?

Mungkin pengembang membuat kesalahan penulisan dalam penamaan variabel atau metoda?

Mungkin pengembang terlewat untuk menambahkan perubahan yang belum dikirim ke remote repositori?

Apapun kesalahannya, kecil atau besar, kesalahan tetaplah kesalahan dan itu manusiawi.

Disitu salah satunya reviewer bisa membantu kita, memberitahu letak kesalahan yang ada.

Dan dari situ kita bisa belajar, entah untuk lebih teliti lagi ataupun untuk lebih chill ketika mendapatkan umpan balik.

Belajar sesuatu yang baru

Tidak jarang Code Review berguna untuk belajar dari kode yang ditulis oleh orang lain juga.

Mungkin rekanmu menggunakan API dari JavaScript yang sebelumnya belum kamu ketahui?

Mungkin rekanmu menggunakan teknik yang membuat proses operasi lebih efisien?

Apapun itu, code review berguna untuk belajar sesuatu yang baru juga.

Menyamakan pikiran

Jangankan orang lain, terkadang kita sendiri saja mudah lupa ketika menulis sesuatu.

Anggap kamu ditugaskan untuk mengembangkan sebuah fitur, misal proses singkronisasi. Lalu kamu menulis kode, yang singkatnya, sebelum melakukan singkronisasi harus memastikan dulu status tersebut bukan PENDING ataupun UPDATING.

Terkadang menulis komentar saja tidak cukup, karena komentar sebatas menjadi dokumentasi singkat, sekalipun kamu menulis komentar yang "why" daripada "what".

Siapa tau sekarang sudah bisa singkronisasi meskipun sekarang PENDING?

Siapa tau singkronisasi tidak bisa juga jika statusnya TRANSFORMING?

Atau, misal kasus lain seperti kita membuat metoda untuk melakukan permintaan ke peladen, namun secara imperatif. Mungkin seseorang yang sudah membuat abstraksinya untuk bisa menulisnya secara deklaratif bisa memberitahu khawatir pengembang tersebut kelupaan.

Menyamakan pikiran juga berguna untuk membuat pengembang dapat lebih mengerti terkait tingkah laku yang ada di program tersebut, baik secara teknis maupun bisnis.

Dan pendekatan tersebut saya rasa sulit dilakukan bila tidak ada Code Review?

Penutup

Code review seharusnya bukan menjadi ajang siapa yang benar dan salah, siapa yang pintar dan berpengalaman, apalagi untuk menyalahkan.

Seperti git-blame(1) yang seharusnya digunakan untuk menganalisa, bukan untuk menyalahkan seseorang.

Sebagaimana sebuah laporan, pasti harus dipertanggungjawabkan. Dan yang bertanggung jawab adalah si pembuat laporan tersebut yang dalam konteks disini adalah si pembuat perubahan.

Dalam mempermasalahkan laporan, kita bisa saja menyalahkan seseorang yang membuat/melakukan kegiatan yang ada di laporan tersebut karena itu menyebabkan sebuah masalah.

Namun tentu saja kita pun bisa untuk tidak menyalahkan seseorang melainkan fokus ke penyelesaian masalahnya saja, dan membuat agar kesalahan tersebut setidaknya tidak terjadi dikemudian hari.

Dalam organisasi, kita bekerja sebagai tim, bukan individual. Ada seksi konsumsi, hubungan masyarakat, dsb, bukan Bagas; Wahyu, Adrin, dan Rin.

Jika ada kesalahan yang misalnya dilakukan oleh salah seorang anggota tim, maka yang bertanggung jawab adalah keseluruhan tim. Begitupula bila mendapatkan kemenangan, semuanya menang.

Dalam proses code review pun sepertinya harus begitu, kita fokus bersama-sama untuk mengembangkan sebuah program yang dapat diandalkan; yang berkualitas, yang stabil, yang aksesibel tanpa tapi.

Dan seluruh lapisan tim, bertanggung jawab untuk dapat tercapainya tujuan tersebut.

Dan sebelum mempertanggung jawabkan ke tingkatan yang lebih tinggi, pertanggungjawaban tersebut dilakukan oleh tingkatan yang lebih rendah, seperti untuk tingkatan tim frontend misalnya sebelum dibawa ke tingkatan divisi engineering.

Nah, di proses code review inilah penentuan tersebut terjadi, sebelum dibawa ke tingkatan yang lebih tinggi.

Sebagai penutup, tidak perlu takut dengan proses code review apalagi kalau sampai menjadi minder setiap ingin meminta/memberikan code review, karena jika ada kesalahan, maka satu tim yang terlibat yang salah.

Dan jika tidak ada kesalahan lalu mendapatkan kemenangan, maka semua tim yang menang!

Jadi, ya, untuk yang merasa senior, don't be jerk.

Membangun mental dengan cara lucu kok dengan menjadi superior pas code review, dengan ospek terus teriak-teriakin pas ada yang ga pake gesper lah.

Mungkin setiap organisasi berbeda-beda dalam melakukan code review, dan juga ada beberapa—including my employer—yang melakukan beberapa pekerjaan yang biasa dilakukan ketika code review dengan cara otomatis seperti terkait coding style & rules.

Tapi, jika kamu bekerja dengan saya, personally speaking, inilah cara saya melakukan code review: Untuk belajar sesuatu yang baru, dan untuk menyamakan pikiran.

Karena bukankah kalau untuk mencari kesalahan yang major biasanya sudah dilakukan oleh linter dan compiler?

Beda cerita kalau kesalahan dalam menerjemahkan kebutuhan bisnis, atau hal-hal minor yang tidak terlalu berdampak ke aplikasi seperti adanya typo dan lupa menulis komentar.

Anyway, terima kasih sudah membaca dan selamat berakhir pekan!