7 Tips untuk meningkatkan kualitas Pull Request/Merge Request agar disukai oleh Code Reviewer pada tahun 2021
Sebagai programmer/developer, Pull Request/Merge Request (berikutnya akan disingkat sebagi PR) adalah makanan harian. Tak jarang PR menjadi bentrok/debat/diskusi/masalah antara programmer dan pengulas. Ini wajar terjadi, justru jika tidak pernah ada masalah antara programmer dan pengulas yang tidak wajar. Dengan adanya debat/diskusi ketika melakukan PR, disitulah terjadinya saling belajar, saling bertukar ide, saling membangung hubungan sehat yang akan berguna baik untuk tim maupun untuk perusahaan. Jika PR kalian selalu mulus, semulus pantat bayi, disitulah terdapat masalah yang tidak terlihat, yaitu tidak adanya pertukaran ilmu, tidak saling belajar, dan tidak adanya standar kualitas.
Akan tetapi, PR dapat membuat masalah juga. Tidak jarang programmer dan pengulas bertengkar gara-gara PR. Bahkan ada yang tidak pernah di merged (mengakibatkan fitur terlambat untuk di deploy yang berimbas pada bisnis perusahaan). Hal ini bisa dibilang cukup “wajar” dan terjadi bukan hanya di perusahaan lokal, bahkan Google pun juga mengalaminya. Berbeda dengan hard skill yang ada ilmu bakunya, PR adalah soft skill yang (sialnya) harus dimiliki tetapi tidak ada yang mengajarkan. Kebanyakan artikel yang ada juga mengenai cara memberikan review/ulasan. Oleh karena itu, artikel kali ini akan memberikan 7 tips agar PR lebih disukai oleh pengulas, dan harapannya, mengurangi masalah yang biasanya hadir:
- Bersikap rendah hati
Ada perbedaan antara rendah hati dengan minder (rendah diri). Terdapat pula perbedaan antara percaya diri dengan sombong/arogan. Ketika melakukan PR, programmer biasanya akan merasa bangga dengan ide/kreasi yang diciptakannya dengan susah payah. Bangga dengan kode sendiri memang bagus, wajib malahan, akan tetapi hal ini cenderung berubah menjadi sombong/arogan dan merasa bahwa solusinya adalah yang paling benar. Inilah yang tidak boleh terjadi.
Tidak ada manusia yang sempurna, solusi yang ditemukan bisa saja kurang optimal atau bahkan mengandung bug. Dan memang karena itulah dibuat tahap untuk review (PR). Tidak jarang PR justru memberikan solusi yang lebih baik. Ketika melakukan PR, programmer meminta waktu, emosi, dan pikiran pengulas untuk membantu mengecek/mengulas solusi yang dibuat, oleh karena itu be humble.
- Jangan bersikap defensif
Ketika ide/solusi diberikan komentar, ada beberapa orang yang merasa bahwa itu merupakan serangan dan langsung bersikap defensif. Disinilah biasanya developer salah kaprah. Ketika pengulas memberikan ulasan di PR, yang diulas adalah solusi/kode yang dibuat, bukan developer/orangnya. Bersikap defensif pada saat PR justru akan menghambat diri sendiri karena tidak dapat memperbaiki (atau mengoptimalkan) solusi yang telah ditemukan dengan susah payah.
Jika merasa ada komentar/ulasan yang tidak sejalan/tidak setuju, ungkapkan ketidaksetujuan dengan anggun. Dan ingat, berpikir sebelum bereaksi. Respectfully disagree and think before reacting.
- Reviewer/Pengulas bisa salah
Pengulas adalah manusia biasa yang sibuk, yang memiliki pekerjaan selain mengulas. Sehingga, wajar jika pengulas bisa salah. Ketika pengulas salah, jangan menyalahkan/bertengkar seolah-olah pengulas tidak boleh salah — jangan menabur garam diatas luka. Tanya, dengan sopan dan sabar, apa maksud/tujuan dari pengulas, bisa saja itu dapat membantu untuk perkembangan diri. Bisa saja pengulas salah membaca/memahami solusi/kode yang dibuat, yang berarti menjadi red flag (tanda bahaya) karena bisa jadi orang lain yang berusaha memahami solusi/kode tersebut akan mengalami kesalahan yang sama dengan pengulas. Ask for clarification.
- Berikan tanggapan untuk setiap komen yang diberikan
Penulis sering mengalami skenario ketika pengulas memberikan ulasan, kemudian programmer memperbarui kodenya untuk menjawab beberapa ulasan, tetapi mereka tidak menulis balasan apa pun. Sekarang, pengulas berada dalam kondisi ambigu. Apakah programmer melewatkan ulasan yang lainnya atau programmer masih mengerjakannya? Jika pengulas memulai babak baru pengulasan, pengulas berpotensi membuang-buang waktu untuk membuat daftar perubahan yang setengah jadi. Jika pengulas menunggu, pengulas mungkin akan membuat jalan buntu di mana pengulas dan programmer sama-sama mengharapkan pihak yang lain untuk melanjutkan.
Tetapkan konvensi di tim untuk memperjelas siapa yang “memegang tongkat estafet”. Misal programmer sedang menindaklanjutkan ulasan, atau pengulas sedang menulis umpan balik. Tidak boleh ada situasi dimana proses terhenti karena tidak ada yang tahu siapa yang melakukan apa. Kalian dapat melakukannya dengan mudah dengan menuliskan komentar balasan yang menunjukkan kendali diserahkan ke pengulas.
Untuk setiap ulasan yang membutuhkan tindakan/follow up, tanggapi secara eksplisit untuk mengonfirmasi bahwa kalian telah menanganinya. Beberapa alat peninjau kode memungkinkan untuk menandai komentar sebagai terselesaikan/done. Jika tidak, gunakan konvensi sederhana, seperti, “Done”, untuk setiap ulasan. Jika kalian tidak setuju dengan ulasan tersebut, jelaskan dengan sopan dan elegan argumen kalian.
Sesuaikan response/tanggapan kalian berdasarkan upaya/effort dari pengulas. Jika pengulas menulis ulasan secara detail untuk membantu kalian mempelajari sesuatu yang baru, jangan hanya menandainya sebagai selesai/done. Respond thoughtfully to show gratitude for reviewer’s effort.
- Lakukan Pull Request dengan unit terkecil (Atomic)
Bayangkan kalian menjadi pengulas dan menerima permintaan ulasan dengan 1000+ perubahan file (dan penulis beberapa kali mengalami hal ini). Tentunya pengulas akan kewalahan dan kebanyakan pengulas akan langsung approve jika lolos dari tes. Ini menjadi anti-pattern dari filosofi PR sendiri, yaitu untuk menjaga kualitas kode. Alangkah baiknya jika PR yang dilakukan sedikit demi sedikit. Memang akan memakan waktu lebih lama, tetapi hal ini akan membantu kedepannya misal meminimalisir kemungkinan ada bug, bisa mengembalikan/revert sebagian fitur. Definisi PR yang sedikit adalah atomic commit, artinya commit tersebut harus dapat dijalankan (dan tanpa meninggalkan masalah). Do one thing and do it very well.
- Gunakan Pull Request Template
Ketika melakukan PR, biasakan untuk menambahkan deskripsi tentang PR tersebut. Bayangkan jika kalian menjadi pengulas, sedang pusing coding lalu diminta mengulas dan hal pertama yang kalian temukan adalah PR tanpa deskripsi. Pengulas memang biasanya lebih senior — bisa peer juga yang sama-sama tahu, tetapi bukan berarti pengulas adalah dukun yang tahu semuanya — termasuk maksud dari PR kalian.
Banyak programmer yang kurang memerhatikan hal ini, padahal ini sangatlah penting baik untuk pengulas, maupun untuk programmer dimasa depan yang perlu membaca sejarah kode/solusi kalian. Penulis selalu memanfaatkan PR template untuk mempermudah tim dalam memberikan deskripsi PR, terutama untuk membantu programmer yang bingung harus memberikan deskripsi apa.
Repositori-repositori git memiliki template yang dapat digunakan ketika melakukan PR. Sebagai contoh, ini tautan untuk Github template. Beberapa poin deskripsi yang diperlukan oleh reviewer biasanya:
1. Deskripsi permasalahan
2. Apa solusi yang dilakukan
3. Dokumen/referensi untuk membantu memahami masalah dan solusi
4. Cara untuk mengetes solusi tersebut
- Alat terbaik untuk Pull Request? Kursi
Ini adalah idiom/ungkapan yang artinya solusi terbaik untuk masalah PR adalah duduk bersama-sama untuk berdiskusi. Tentunya ungkapan ini diciptakan sebelum pandemi. Perlu ditegaskan sekali lagi, ini ungkapan bukan sebenarnya, jadi jangan melempar kursi ke pengulas ya!
Akhir kata, tidak ada PR yang sempurna. Debat, diskusi, saling merasa benar, dll tetap akan terjadi. Asumsikan saja PR itu seperti cinta, deritanya tiada akhir. Yang penting adalah menjaga hubungan (baik), tetap belajar dan meningkatkan kualitas diri.
Begitulah artikel kali ini. Kalian boleh comment untuk berbagi cerita pengalaman/pendapat kalian mengenai Pull Request. Clap jika kalian suka, share jika tutorial ini membantu buat kalian, dan comment ketika ada pertanyaan. See you next time!
Hyperjump Update!
We just launched our free and open source synthetic monitoring tool called Monika on Product Hunt! Your review and upvote are greatly appreciated! 🤝
Hyperjump is an open-source-first company providing engineering excellence service. We aim to build and commercialize open-source tools to help companies streamline, simplify, and secure the most important aspects of its modern DevOps practices.
