Mempersingkat Code Review dalam tim global, bagian 2

Di saat kritis, proses code review harus semakin cepat.

Sebelum membaca tulisan ini, silakan membaca tulisan saya sebelumnya mengenai latar belakang kami melakukan Code Review di Cookpad Global.

Waktu adalah aset yang berharga bagi sebuah perusahaan, apalagi jika memiliki tim yang terdistribusi secara global. Namun kode yang berkualitas juga tak kalah penting. Jangan sampai proses code review malah dihindari hanya untuk mempercepat waktu rilis. Code review memang harus teliti, namun tidak selalu memakan banyak waktu.

Apa saja hal yang bisa kita lakukan untuk mempersingkat waktu code review namun tetap menjaga kualitasnya?

Meminta tinjauan dari rekan dalam zona waktu yang tidak jauh berbeda

Kendala umum bagi tim yang terdistribusi global adalah perbedaan zona waktu antara yang meninjau dan yang ditinjau. Engineer yang berdomisili dengan perbedaan waktu 5 jam masih wajar dimintai code review. Namun jika tidak direncanakan secara matang, waktu untuk meninjau bisa memakan waktu hingga berhari-hari.

Kapankah waktu yang tepat untuk mengajukan Pull-Request? Saya biasanya menghindari waktu seperti:

• Terlampau pagi.
  Biasanya waktu pagi hari digunakan untuk ngopi, melihat dan membalas email, atau aktifitas lainnya untuk memulai hari
• Waktu makan siang
  Karena engineer juga butuh makan.

Situs timeanddate.com memiliki fitur meeting planner yang bisa dimanfaatkan untuk menentukan waktu Pull-Request.

Untuk kasus-kasus luar biasa yang membutuhkan tinjauan dari engineer di belahan bumi yang lain, saya biasanya membuat sebuah Pull-Request dengan status WIP (Work-In-Progress) di pagi harinya dan menghapus status WIP untuk meminta tinjauan di malam harinya, sebelum saya pulang. Dengan demikian, peninjau akan melihat Pull-Request saya ketika baru memulai harinya. Pull-Request berstatus WIP berarti belum siap untuk ditinjau.

Remote Pair Programming

Code review dalam tim global umumnya tidak berlangsung seketika itu juga. Untuk mendapatkan balasan dalam dua atau tiga jam itu lumrah terjadi. Namun code review secara seketika masih dapat dilakukan dengan remote pair programming (remote pairing).

Cara yang paling mudah untuk melakukan remote pairing adalah dengan melakukan video chat dan mengaktifkan fitur screen sharing. Di Cookpad Global kami menggunakan aplikasi Zoom yang punya reputasi bagus untuk koneksi Indonesia yang kurang stabil. Yang menjadi pengemudi (Driver) biasanya yang melakukan screen sharing.

Walaupun remote pairing itu adalah cara yang paling cepat untuk melakukan code review, tentunya ini menjadi cara yang paling mahal karena membutuhkan komitmen waktu dari kedua belah pihak untuk melakukannya.

Biasanya kami mengalokasikan 30 menit atau lebih cepat untuk remote pairing guna menghemat waktu. Tujuannya untuk menggali konteks yang lebih dalam atau dalam keadaan darurat untuk memecahkan masalah dengan segera.

Meminta tinjauan sebelum ngoding

Bayangkan sebuah situasi ketika seorang rekan akan memperkenalkan fitur baru. Untuk mempermudah pengembangan, fitur tersebut membutuhkan sebuah pustaka (library) sumber terbuka yang sudah dia pilih. Ia telah menghabiskan waktu 1 minggu untuk mempelajari dokumentasinya dan mengaplikasikannya ke dalam fitur ini. Ketika Pull-Request sudah dibuat, sebagai peninjau, apa yang akan kamu tinjau terlebih dahulu?

Sebagai peninjau, saya akan mempelajari deskripsinya untuk mengetahui:

• mengapa fitur ini dibuat, dan
• mengapa ia memilih pustaka tersebut dibandingkan dengan pustaka lainnya

Sayangnya, ketika meninjau, saya menemukan bahwa ternyata kita tidak memerlukan pustaka tersebut karena masalah yang ingin dipecahkan cukup sederhana (Overkill).

Sang rekan bisa menerima usulan saya dan akhirnya memperbaharui kodenya dalam waktu beberapa jam.

Seandainya sang rekan berdiskusi terlebih dahulu, tentunya waktu yang diperlukan bisa lebih singkat. Misalnya dalam bentuk RFC (Request for Comment). Dalam kisah nyata, sayalah rekan tersebut 😂.

Di Cookpad Global, kami memiliki beberapa panduan untuk membuat RFC:

• Membangun sesuatu yang baru dari nol, misalnya API, komponen, aplikasi, pustaka, dan lain lain
• Berencana untuk menulis ulang sebuah bagian penting dari aplikasi (misalnya proses registrasi)
• Menambahkan layanan pihak ketiga (misalnya perangkat untuk memonitor aplikasi)
• Berencana untuk mengganti pustaka atau menambahkan aplikasi baru ke dalam stack yang ada
• Tidak yakin akan implementasi yang akan dibuat dan ingin memperoleh pendapat dari rekan
• Ingin memperkenalkan cara penulisan kode yang baru
• Ingin menerapkan ide baru yang dapat meningkatkan efisiensi kerja tim

Jika ditulis dengan baik, RFC dapat menghemat waktu ketika code review. Karena peninjau sudah menyepakati solusi yang akan diterapkan sebelum kodenya dibuat. Sehingga ketika Pull-Request diunggah, mereka hanya perlu meninjau tes dan hal minor lainnya saja.

Meminta review secara gamblang, dibantu dengan rekomendasi GitHub

Komunikasi yang kurang jelas seringkali memperlambat code review.

“Apakah saya harus meninjau ini?”

“Apakah ada yang tergugah untuk meninjau kode saya?”

“Saya ingin meninjau kode ini, namun siapakah yang sedang meninjau ini?”

Jika kamu menghadapi pertanyaan seperti di atas, besar kemungkinan kode tersebut tidak dalam peninjauan.

Mintalah tinjauan kepada seseorang secara gamblang. Di GitHub, jika kode yang sedang kamu kerjakan pernah diubah oleh orang lain, orang tersebut akan muncul di rekomendasi peninjau. Ini sangat membantu karena orang tersebut punya sejarah mengerjakan kode yang sedang kamu ubah. Tentunya kamu juga bisa memilih orang lain secara langsung:

Orang yang dirujuk akan menyempatkan dirinya untuk meninjau atau mereka bisa merekomendasikan orang lain jika tidak memiliki kapasitas.

"Memaksa” untuk membuat PR yang lebih kecil

Pada artikel sebelumnya saya menjelaskan mengenai manfaat sebuah Pull-Request dengan diff yang kecil. Kami kemudian membuat sebuah eksperimen sederhana dengan menggunakan sebuah bot. Bot ini kami beri nama CP-8 (atau cookp8).

cookpad/cp8
Cookpad GitHub App. Contribute to cookpad/cp8 development by creating an account on GitHub.github.com

Cara kerja bot ini cukup sederhana:

Jika PR dibuat dengan penambahan kurang dari 100 baris, maka beritahukan peninjaunya (melalui Slack) bahwa PR ini berukuran kecil:

Jika lebih, maka tidak perlu menyebut peninjaunya:

Hasilnya, setiap PR yang berukuran kecil memperoleh tinjauan lebih cepat, bahkan instan 🚀 untuk beberapa kasus. Ini juga mendorong timbulnya kebiasaan baru untuk membuat Pull-Request dengan ukuran kecil.

Patut diingat sekali lagi bahwa ukuran Pull-Request yang kecil bukanlah tolok ukur kualitas. Namun ukuran yang kecil dapat membantu proses code review supaya lebih cepat.

Inilah beberapa metode yang kami lakukan untuk mempersingkat Code Review di Cookpad Global. Saat ini ada beberapa eksperimen terkait produktifitas yang saat ini kami jalankan. Jika materinya sudah terkumpul cukup banyak akan saya bagikan kembali dalam tulisan berikutnya 😊.