Agile - Code Review (Berapa Lama)

Kembali lagi kepada definisi Code Review sebelumnya Code Review:

Code Review adalah aktifitas mengecek dan memberikan feedback untuk source code. Dilakukan oleh satu atau lebih orang selain penulis source code.

Berapa lama waktu yang dibutuhkan ?

Aktifitas Code Review sebenarnya sederhana :

Coba kita lihat

Kalau dilihat dari prosesnya, maka yang akan memakan waktu lama adalah :

1. Review code
   
   Ini merupakan aktivitas utama nya. Ya tentu saja merupakan yang paling lama.
   
   Menghabiskan waktu untuk review code adalah hal yang wajar, mengingat yang melakukan review bukanlah si pembuat code, tetapi orang lain. Dengan kata lain, dia harus mengerti mengenai pola pikir si pembuat code agar bisa melakukan review dan memberikan saran dan usulan kepada pembuat code.
   
   Membaca code merupakan salah satu kesulitan tersendiri. Apalagi ketika seseorang Software Engineer menulis code, ada unsur style, paradigma pemrograman yang dipakai, kebiasaan, pengalaman, dan kebutuhan eksplorasi darinya.
   
   Yang tentunya bisa saja berbeda dengan style, paradigma pemrograman yang dipakai, kebiasaan, pengalaman dari orang yang melakukan review.
   
   Yang akan susah dikompromikan biasanya adalah yang bersifat style (gaya penulisan, indentasi, kurung, dll), paradigma pemrograman, dan kebiasaan/best practice yang bisa berbeda.
   
   Sementara pengalaman dan kebutuhan eksplorasi mungkin masih cukup enak untuk didiskusikan dan dikompromikan.
   
   Nah, sebenarnya code review ini pada dasarnya tidak berfokus kepada mereview style, paradigma pemrograman, dan kebiasaan/best practice yang bisa berbeda.
   
   Kalaupun mau menyeragamkan dan mereview hal-hal tersebut, maka sebenarnya bisa memanfaatkan aplikasi pengecekan otomatis seperti Checkstyle, Tslint, Sonarcube, Checkmarx, dll.
   
   Sehingga menghabiskan waktu untuk mereview sesuatu yang bersifat style, paradigma pemrograman yang disukai, dan kebiasaan yang berbeda sebenarnya kurang efektif.
   
   Akan lebih bermanfaat kalau yang dilihat dan direview adalah sesuatu yang disepakati oleh penulis code dan yang mereview. Contohnya :
   
   a. Alur logika untuk proses bisnis atau proses teknis nya, yang notabene adalah alur yang diketahui kedua pihak, atau bahkan merupakan tugas untuk tim .
   
   b. Kesepakatan untuk penomoran/iterasi untuk versioning.
   
   c. Kesepakatan untuk penggunaan library tertentu dan penggunaan pola logika dan alur yang dipakai bersama.
   
   

2. Diskusi tentang hasil review/feedback.
   
   Ini merupakan aktifitas setelah melakukan review code. Berdiskusi antara pembuat code dan yang mereview, apakah sifatnya meminta konfirmasi atau penjelasan tentang code nya, ataupun kemudian meminta perubahan terhadap code yang direview.
   
   Disinilah diperlukan semangat membangun, menerima saran dan usulan, belajar dari pengalaman orang lain, dan juga keingintahuan.
   
   Berdiskusi untuk hasil review ini bukanlah untuk memperlihatkan siapa yang paling benar, atau siapa yang salah, atau siapa yang lebih berpengalaman.
   
   Akan tetapi harus dilihat sebagai diskusi bersama mengenai sebuah produk yang dianggap sebagai milik dan karya bersama.
   
   Sehingga dalam proses ini, banyak sekali yang akan didiskusikan, termasuk didalamnya flow bisnis dan teknis, teknologi yang digunakan, eksplorasi,pengalaman.
   
   Tetapi kalau semua didiskusikan pada waktu Merge Request ini, maka waktu yang kita habiskan untuk berdiskusi bisa jadi lebih lama dari aktifitas membuat code itu sendiri.
   
   Oleh karena itu harus ada prioritas diskusi yang harus diutamakan dalam melakukan diskusi ini, yaitu diskusi flow bisnis, flow teknis, teknologi yang digunakan, best practice, dan terakhir adalah pengalaman, dan eksplorasi.
   
   Dengan membuat prioritas dan pilihan diskusi yang kita inginkan, maka kita bisa menentukan apakah diskusi kita tentang eksplorasi teknologi cocok dengan situasi sprint yang sedang berlangsung atau tidak.
   
   . Mengupas mengenai teknologi yang digunakan, dimana sprint yang sedang berlangsung mungkin sedang fokus untuk release, merupakan sesuatu yang tidak tepat.
   
   Akan lebih tepat kalau diskusi itu dilakukan di sesi tertentu di waktu senggang, atau sprint yang lebih lega.
   
   Dengan menentukan prioritas diskusi, waktu yang dibutuhkan untuk merge request ini bisa lebih efektif dan efisien.

Kesimpulan

Waktu yang digunakan untuk proses merge request adalah relatif terhadap 2 aktifitas utama, yaitu review code dan diskusi hasil review/feedback.

Kalau kita bisa menentukan prioritas di dua aktifitas tersebut, maka proses merge request ini akan bisa lebih efektif.