diskusi.tech (beta) Community

loading...
Cover image for Membuat Pull Request yang Efektif & Efisien

Membuat Pull Request yang Efektif & Efisien

wildan profile image Wildan S. Nahar Originally published at blog.wildan.us ・5 min read

Sebagai seorang programmer, pekerjaan sehari-hari kita adalah untuk menyelesaikan masalah yang umumnya dilakukan via coding. Beberapa tahun lalu, kita terbiasa menggunakan FTP (File Transfer Protocol) untuk memindahkan sumber kode lokal kita ke server. Namun praktik tersebut sangatlah tidak praktis, kurang aman, dan sulit untuk melakukan pengecekan siapa melakukan perubahan apa. Jadi disinilah perlunya version control, sebuah alat yang digunakan untuk melacak perubahan kode (siapa, file apa, keterangan, dan waktu) dan memudahkan kolaborasi di antara programmer. Dan langkah terbaik untuk memperkenalkan perubahan kode adalah melalui fitur Pull Request atau dapat kita singkat dengan PR.

Pull Request bagi saya adalah sebuah "platform diskusi" dimana setiap orang bisa berkontribusi dengan mengulas perubahan kode dan menyetujui/meminta perbaikan terhadap perubahan tersebut. Tetapi seringkali, kita tidak melakukannya dengan cara yang sesuai sehingga "memusingkan" pembuat perubahan kode dan pengulas. Pada tulisan ini, saya akan berbagi pengetahuan yang didapat dari pengalaman membuat PR di beberapa projek di dalam perusahaan saya.

Mengapa ini penting

Sebelum kita memasuki hal detail dan lebih teknis, saya pikir kita perlu mempertanyakan hal yang fundamental berikut:

Mengapa kita perlu membuat Pull Request yang efektif dan efisien ?

Itu adalah pertanyaan yang menarik. Pada awalnya, saya berpikir bahwa itu tidak diperlukan jika kita hanya bekerja dengan 1 programmer lain (1 pasang) dan duduk berdekatan. Artinya, koordinasi bisa dilakukan secara langsung melalui percakapan. Kita hanya perlua meminta dia untuk mengulas kode kita di mesin lokal kita, tanpa perlu membuat PR. Atau kalaupun kita memang perlu membuat PR, kita tidak perlu mengikuti praktik-praktik terbaik.

Tetapi, bagaimana bila suatu hari perusahaan kita berkembang, tim bertambah, jumlah programmer meningkat sampai puluhan bahkan ratusan, tersebar di berbagai daerah (atau bahkan beda negara) dengan zona waktu yang berbeda-beda? Standar dari masing-masing tim tentunya pasti akan berbeda: strategi percabangan (branching strategy), tes unit minimal, pedoman umum koding, dan proses mengulas PR. Disinilah membuat PR dengan efektif dan efisien berguna.

PR yang efektif dan efisien terdiri dari seperangkat aturan dasar yang dimaksudkan untuk bersifat umum, sehingga diharapkan setiap orang dapat mengikutinya tanpa perlu banyak kustomisasi. Pendekatan PR ini memiliki beberapa karakter diantaranya adalah ukuran PR yang beralasan, fokus, dan tidak memiliki efek samping. Hal-hal tersebut diperlukan untuk mengoptimalkan waktu pengulasan, tidak menimbulkan kerusakan (bug / defect), dan pada akhirnya menyelesaikan masalah yang sebenarnya.

Ide dasar

Hal pertama yang harus diperhatikan ketika membuat PR adalah fokus pada tujuan. Apa tujuan dari PR ini? Apakah memperbaiki bug? Atau mengenalkan kode error yang baru? Dan seterusnya. Saat kita sudah menentukan tujuan dari PR, kita dapat membuat solusi yang diimplementasikan dalam bentuk kode sumber (bisa penambahan atau penghapusan). Dan kode tersebut harus merefleksikan solusi yang telah ditentukan di awal. Tidak kurang tidak lebih. Jadi bagaimana kita dapat melakukannya? Inilah beberapa tips yang dapat saya bagikan 😃

1) Fokus untuk menyelesaikan masalah

Sebuah PR harusnya hanya melakukan 1 hal dan melakukannya dengan benar. Misalkan tujuan dari sebuah PR adalah mengenalkan error code baru dan bagaimana cara mengatasinya. Solusi dari tujuan tersebut adalah meregistrasikan error code baru dan tindak lanjut untuk mengatasinya. Untuk tambahan, sebuah unit test untuk memastikan perubahan yang dilakukan bekerja dan tidak merusak kondisi saat ini juga diperlukan.

Sebagai contoh, berikut adalah PR yang sederhana untuk menghapus file deployment yang sudah tidak diperlukan.

pr-goal

2) Perubahan kode harus merefleksikan solusi

Terkadang kita terlalu senang untuk membuat PR sehingga dalam PR tersebut melakukan terlalu banyak hal. Ini tentunya bukan praktik yang bagus. Misalnya, saat membuat sebuah PR terkait fitur tertentu, kita juga melakukan perbaikan typo dan translasi yang tidak ada hubungannya sama sekali dengan fitur tersebut. Daripada membuat PR yang melakukan banyak hal, kita bisa membuat PR kecil untuk tujuan-tujuan spesifik seperti yang telah disebutkan di atas. Sehingga dengan begitu, perubahan kode tetap sejalan dengan tujuan utama dari PR.

Sebuah contoh dari PR yang sederhana dan terfokus.

pr-changes

Bertentangan dengan contoh di atas, berikut adalah praktik yang tidak baik dimana sebuah PR juga menimbulkan perubahan yang tidak perlu.

pr-changes-unnecessary

Jenis perubahan yang tidak perlu di atas sebenarnya dapat dengan mudah dicegah dengan memiliki git pre-commit hook . Pada hook tersebut, kita dapat melakukan pemformatan seperti menjalankan linter untuk menstandardisasi format kode dan perubahan-perubahan bersifat format dan non-logic yang lain.

3) Membuat sampel PR

Sampel PR hanya tersedia di GitHub (sejauh yang saya tahu), kurang yakin untuk version control platform yang lain seperti GitLab atau Bitbucket.

Sampel PR bisa sangat berguna. Dengan usaha yang relatif kecil untuk membuatnya (di github, bisa membuat file dengan nama PULL_REQUEST_TEMPLATE.md di direktori akar pada sebuah repositori). Kita dapat mendefinisikan tipe dari PR, menambahkan checklist, dan konten-konten pendukung lain yang dirasa perlu untuk memudahkan proses pengulasan. Berikut salah satu contoh penerapan sampel PR pada sebuah repositori.

pr-template

Sekilas, sebagai pengulas, kita dapat melihat rangkuman dari sebuah PR dengan hanya melihat pada deskripsinya. Bahkan lebih baik lagi adalah bila sebuah repositori mempunyai sampel PR yang menyediakan konten yang terstruktur, konsisten, dan mudah dipahami sehingga akan membuat pengalaman PR menyenangkan baik bagi pengulas maupun yang membuat PR.

4) Mengikuti konvensi git commit

Git commit bertindak selaku deskripsi singkat yang merefleksikan perubahan kecil yang kita lakukan pada satu atau beberapa file dalam sebuah konteks. Esensinya, commit harus mempunyai 1 goal dalam sebuah konteks (dan secara pribadi, saya lebih memilih sebuah commit untuk stateless atau tidak terikat waktu). Ada banyak konvensi commit yang bisa diikuti, tapi secara personal saya biasanya mengikuti konvensi dari angular dan commitizen. Commit message yang sesuai akan membantu pengulas ketika dia ingin mencari sesuatu yang spesifik dari sebuah PR dan ingin memahami apa yang ingin dicapai oleh si pembuat PR. Tetapi patokan yang final tentunya adalah perubahan file, bukan commit. Berikut adalah contoh commit message yang mudah dibaca dan dipahami.

pr-commits

Bandingkan dengan commit messages berikut.

pr-commits-2

Kesimpulan

Tulisan ini bermaksud untuk membagikan pemahaman dasar terkait cara membuat pull request yang efektif dan efisien. Dengan PR yang efektif dan efisien, diharapkan proses pengulasan bisa berjalan secara menyenangkan dan dapat fokus pada hal-hal yang substansial dan signifikan.

Discussion

pic
Editor guide