Mempersingkat Code Review dalam tim global, bagian 1

Code Review oleh rekan dalam satu ruangan saja bisa memakan cukup banyak waktu, bagaimana dengan yang tinggal di belahan bumi yang lain?

Sebagai perusahaan berskala internasional, Cookpad Global memiliki software engineer yang tinggal di berbagai kota di dunia. Sebagian besar berdomisili di Bristol dan Tokyo, namun ada juga yang tinggal di Bangalore, Beirut, Alicante, Panama City dan ibukota republik tercinta, Jakarta ❤️!

Perbedaan tempat bisa memperlambat laju komunikasi. Walau untuk berbicara tatap muka bisa menggunakan video call, tapi kesempatan itu terbatas hanya di waktu-waktu tertentu. Karena untuk menemukan waktu kerja yang beririsan itu cukup sulit. Baru-baru ini saya melakukan video call dengan rekan dari Panama, perbedaan waktu 12 jam mengharuskan saya melakukan video call pada jam 7 pagi!

Tetap melakukan code review walau tanpa waktu khusus

Ilustrasi di atas sudah cukup memberikan alasan bahwa tidak ada waktu yang tepat untuk melakukan code review. Walaupun demikian, kami tetap bersikukuh untuk tetap melakukan code review.

Code review as an integrated part of writing software.
Code review is how we share knowledge and learn from each other, not an afterthought or meaningless signoff ritual.
 —dikutip dari web-chapter’s handbook of Cookpad Global

Code review yang tertuang ke dalam Pull-Request, adalah satu-satunya tempat di mana kami bisa melihat bagaimana sebuah fitur dilahirkan. Semacam arsip yang mengkombinasikan antara dokumentasi spesifikasi dan kode. Tidak hanya dibaca oleh engineer, tetapi juga dapat dibaca oleh rekan non-engineer lainnya.

Sebagai contoh, dengan Pull-Request kami bisa mengetahui bahwa:

• sebuah fitur hasil diskusi dengan product manager dan designer akan dibuat,
• sebuah bug yang dilaporkan oleh community manager sedang diperbaiki,
• sebuah eksperimen perlu dimonitor oleh data scientist, dan lain-lain

Untungnya perkembangan GitHub akhir-akhir ini (kanban board) semakin mempermudah kami untuk menjadikan Pull-Request sebagai sumber utama untuk dokumentasi. Proses code review menjadi semakin penting.

Sebelum saya membagikan cara bagaimana kami mempercepat Code Review, ketahuilah bahwa kami masih terus mencari cara untuk mempercepat proses ini.

Mengotomatiskan Code Review sebanyak mungkin

Kurang indentasi, kelebihan spasi, penamaan variabel tidak sesuai kaidah, method yang tidak berguna, ukuran kelas yang terlalu besar, atau kelebihan tanda koma pada hash adalah beberapa contoh aspek yang kita nilai dari sebuah kode yang rapi.

Tentunya tidak semua orang mampu untuk menguasai dan menghafal semua aturan tersebut. Oleh karena itu kami berusaha mengotomatiskan aturan-aturan tersebut ke dalam static code analyzer. Di dunia Ruby 💎 umumnya mengenal Rubocop. Kami merasa banyak orang akan terbantukan dengan konfigurasi Rubocop kami, oleh karena itu kami membagikannya di repository kami:

cookpad/global-style-guides
Official style guides for Cookpad Global. Contribute to cookpad/global-style-guides development by creating an account…github.com

Selain rubocop kami juga menggunakan SCSS dan Coffeescript linter.

Membuat deskripsi Pull-Request layaknya seperti blog

Treat the description as a well-written blog post: The diff and the contents of the description together decide how easy it will be to review.
 — dikutip juga dari web-chapter’s handbook of Cookpad Global

Kami menyarankan setiap engineer menulis deskripsi layaknya sebuah blog. Layaknya sebuah blog, deskripsi Pull-Request akan sangat mudah dibaca jika memiliki struktur tulisan yang baku.

Untuk Pull-Request, kami mempunyai beberapa aturan tak tertulis sebagai berikut:

• Memiliki ringkasan
• Memberikan konteks tambahan untuk justifikasi perlunya sebuah Pull-Request
• Memberikan snapshot atau animasi GIF singkat jika terjadi perubahan secara visual

Ini bukan berarti Pull-Request dengan deskripsi yang panjang malah lebih baik. Justru sebaliknya, deskripsi yang terlalu panjang akan membuat proses review menjadi lama. Namun deskripsi yang kurang jelas akan menimbulkan pertanyaan yang tidak fokus pada pokok masalah yang ingin dipecahkan, alih-alih mempertanyakan keberadaan (latar belakang dan sebab) Pull-Request. Diskusi yang seharusnya sudah disimpulkan sebelum Pull-Request dibuat 😀.

Walau memakan banyak waktu, ketahuilah bahwa waktu yang dipakai untuk menulis deskripsi jauh lebih singkat daripada waktu untuk berdiskusi karena deskripsi yang kurang jelas. Terutama jika rekan kerja tinggal di zona waktu yang berbeda.

Diff yang kecil

Meninjau 100 Pull-Request seukuran seekor bebek lebih manusiawi daripada 1 yang seukuran seekor kuda
 — Didik Wicaksono, 2018

Deskripsi yang jelas akan memudahkan peninjau untuk memahami asal muasal dan tujuan Pull-Request. Sedangkan Diff yang kecil akan memudahkan peninjau untuk mempelajari perubahan kode dengan cepat.

Di Cookpad Global, kami menyarankan sebuah diff yang baik memiliki kurang dari 100 baris dari sisi penambahan jumlah baris kode. Jumlah baris ini tentunya dihitung setelah refactor. Tentunya kita tidak bisa memampatkan kode dalam satu baris 😆. Lagipula jika baris melebihi 120 karakter akan langsung ketahuan oleh Rubocop.

Kenapa dibatasi?

Berdasarkan pengalaman kami meninjau Pull-Request selama beberapa tahun, kami menyimpulkan bahwa jika Diff sudah terlampau besar, maka besar kemungkinannya untuk dapat dipecah menjadi beberapa Pull-Request kecil.

Apa yang terjadi jika Diff untuk penambahan lebih besar dari 100 baris?

Diff yang besar memang tidak dapat dihindari, dalam beberapa kesempatan kami memakluminya. Misalnya ketika kita mengubah sebuah berkas berisi terjemahan teks ke dalam berbagai bahasa, ratusan baris sudah menjadi norma. Dalam hal ini diperlukan kesepakatan antara peninjau dan penulis bahwa: proses peninjauan akan berlangsung lebih lama. Sehingga tidak ada tekanan untuk meninjau dengan segera.

Ngomong-ngomong soal pembatasan diff, kami tidak memberikan batasan untuk pengurangan baris kode 😆. Kami menyambut baik segala bentuk pengurangan, asalkan tidak mengurangi tes dan CI tetap hijau.

Inilah beberapa cara yang kami lakukan untuk mempercepat Code Review untuk tim yang terdistribusi secara global. Pada tulisan berikutnya saya akan menjelaskan bagaimana meresensi kode secara instan.