Code Review Bisa Jadi Lebih Baik

• Banyak pengembang merasa tidak puas dengan pengalaman code review di GitHub, dan ada upaya baru untuk memperbaikinya
• Alat eksperimental bernama git-review dirancang agar code review ditangani langsung bersama kode di lokal, bukan melalui antarmuka web browser
• Review dikelola sebagai satu commit tunggal, dengan komentar review ditinggalkan seperti komentar di dalam kode, lalu reviewer dan penulis bersama-sama mengedit commit ini
• Namun, jika kode diubah atau di-rebase di tengah review, muncul ketidaknyamanan besar dalam penanganan konflik dan penggunaan --force-with-lease, sehingga pendekatan ini tidak meraih keberhasilan besar
• Pada akhirnya kembali ke review berbasis web, tetapi gagasan memasukkan status review langsung ke dalam repositori tetap menarik, dan dengan perbaikan Git di masa depan seperti adopsi Change-Id ala Gerrit, ada kemungkinan muncul alternatif yang lebih baik

---

Kesadaran akan masalah pada sistem code review

• Saat ini banyak orang merasa tidak puas terhadap proses code review GitHub
• Masalah utamanya adalah kurangnya dukungan untuk stacked pull request dan interdiff review, ditambah lagi bahwa
  • status review tidak disimpan di dalam repositori
  • review wajib dilakukan melalui antarmuka web yang mengutamakan remote
• Masalah yang saya rasakan adalah kurangnya desentralisasi review dan ketidakefisienan antarmuka

Perbandingan alur kerja penulisan kode dan review

• Saat menulis kode, orang menggunakan editor di lingkungan lokal
  • latensi memori dan NVMe rendah, serta lingkungannya dioptimalkan untuk alur kerja khas masing-masing pengguna
• Untuk code review pun, lebih disukai cara kerja dengan menarik source branch ke lokal
  • melalui alat seperti Magit, kita bisa menelusuri bukan hanya diff tetapi juga keseluruhan konteks kode
  • juga bisa memanfaatkan lingkungan pengembangan yang kuat seperti menjalankan test, melompat ke definisi kode, atau mencoba refactoring
• Sebaliknya, untuk meninggalkan feedback di PR, kita harus berpindah ke browser dan menggunakan antarmuka web yang lambat, dan pada diff besar bahkan terjadi lag saat mengetik

Antarmuka code review dan struktur penyimpanan yang ideal

• Dalam praktiknya, yang paling alami adalah meninggalkan komentar inline di dalam kode atau langsung memperbaiki kodenya

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• Karena data disimpan di DB remote, bukan di repositori git lokal, muncul juga masalah latensi dan vendor lock-in

Ide git-review dan pengalaman nyata

• Ide di balik git-review adalah sebagai berikut:
  • code review dilakukan sebagai satu commit tunggal di puncak branch PR
  • pada commit itu ditambahkan komentar kode dengan marker khusus
  • reviewer dan penulis bergantian mengedit commit tersebut, lalu berkolaborasi berdasarkan push --force-with-lease
  • semua komentar diberi tanda resolved (//? resolved), dan saat review selesai ditambahkan revert commit agar riwayat tetap tercatat
• Idenya sederhana dan praktis, tetapi dalam kenyataannya muncul masalah berikut
  • saat kode diubah selama review, konflik antara komentar dan commit turunan atau commit baru menjadi sering terjadi
  • proses force-push menimbulkan gesekan kolaborasi dan menambah kerumitan kerja
  • ketidaksesuaian antara riwayat perubahan kode dan kemajuan review membuat pengelolaan konflik merge menjadi sulit

Perubahan baru dan kemungkinan masa depan

• Ke depan, ada kemungkinan Change-Id ala Gerrit diadopsi di Git upstream
  • pelacakan riwayat revisi per commit akan menjadi lebih mudah, sehingga dukungan untuk interdiff review diperkirakan meluas
  • tetapi ini juga diperkirakan akan sedikit berbenturan dengan pendekatan git-review
  • dalam struktur Change-Id baru, bisa dimungkinkan pendekatan berbeda seperti menambahkan komentar review langsung ke commit itu sendiri

Kesimpulan dan pengenalan sistem yang layak dirujuk

• Pada akhirnya, untuk saat ini kembali lagi ke code review berbasis antarmuka web
• Kebutuhan akan solusi yang lebih baik tetap ada
• Pengenalan sistem dan alat terkait yang layak dijadikan referensi
  • Fossil: sistem SCM yang menyimpan semua informasi di dalam repositori
  • NoteDb: mengintegrasikan riwayat penyimpanan status review Gerrit ke git
  • git-bug: menyimpan informasi issue di git
  • git-appraise: menyimpan informasi review di git itu sendiri
  • prr: mengimplementasikan antarmuka review di dalam editor dengan terhubung ke GitHub API
  • How Jane Street Does Code Review: contoh pendekatan nyata yang lebih baik
  • git-pr: proyek yang menggantikan seluruh alur kerja PR dengan fitur native Git

Penutup

• Masih belum ada solusi yang sempurna, dan upaya untuk menghadirkan pengalaman pengembang yang lebih baik terus berlanjut
• Ada banyak harapan terhadap arah perkembangan ke depan

[roxie]

Saya tidak tahu apakah pendekatan git-review itu bagus, tetapi saya setuju bahwa review PR berbasis GitHub itu mengerikan..

[GN⁺]

Opini Hacker News

• Hal yang sudah lama membuat frustrasi dalam code review adalah bahwa umpan balik yang benar-benar berguna—bukan sekadar komentar soal selera sepele—hampir selalu datang terlalu terlambat. Satu-satunya hasil yang sering muncul dari review adalah situasi seperti "ini harus diulang dari awal dengan desain baru" atau "pekerjaan ini sebenarnya tidak perlu dilakukan sejak awal". Rasanya code review adalah satu-satunya saat semua pemangku kepentingan benar-benar ikut serta dan berpikir serius tentang perubahan yang diajukan. Mungkin pernah ada pembahasan di meeting atau tiket Jira, tetapi sering kali orang dari tim/divisi lain baru mengetahui perubahan ini setelah menerima notifikasi code review. Saya sendiri juga sering pertama kali tahu tim lain sedang membuat sesuatu yang aneh lewat notifikasi code review. Tidak realistis mengharapkan semua orang selalu mengikuti semuanya sejak awal. Di perkuliahan tahun 90-an kami juga melakukan design review, tetapi saya belum pernah melihat itu di pekerjaan nyata. Dan saya juga tidak yakin design review bisa menjamin semua masalah tertangkap lebih awal.

  • Di dunia rekayasa perangkat lunak, rekayasanya sendiri sering kali tidak terlalu nyata. Sebagian masalahnya adalah industri ini tidak mau menerima lambatnya proses engineering yang benar. Sebagian besar software tidak bersifat fatal, dan bug atau kesalahan masih bisa diperbaiki nanti. Taruhan dan peluang untuk melakukan patch berbeda dengan bidang lain seperti jembatan, pabrik, atau mesin pesawat, tempat kegagalan tidak bisa ditoleransi.

  • Tim kami adalah kelompok kecil berisi 4–6 developer. Saat membuat fitur baru, begitu ada rancangan kasar di kepala, kami langsung mendiskusikannya dengan rekan kerja. Karena semua orang bekerja seperti ini, code review jadi lebih berfokus pada hal-hal kecil seperti code smell, sementara arsitektur keseluruhan biasanya sudah diputuskan lebih dulu oleh 2–3 orang. Kalau anggota tim tidak setuju dengan kode tertentu, mereka jadi enggan menyentuh bagian kode lain dan situasinya memburuk. Saya yakin ini tetap bisa berjalan baik dalam skala lebih besar selama tanggung jawab dibagi dengan baik.

  • Jika semua pemangku kepentingan hanya terlibat pada saat code review, itu bukan masalah Git atau version control system, melainkan masalah organisasi. Artinya latar belakang PR dibuat, diskusi di tiket, dan proses pengambilan keputusan tidak dibagikan. Ini contoh organisasi yang disfungsional, seperti menyalahkan proses penerbitan karena semua orang baru berkumpul dan benar-benar terlibat saat buku cetak sudah terbit.

  • Organisasi kami mewajibkan penulisan RFC untuk keputusan desain yang mendasar. Apa yang termasuk keputusan desain mendasar ditentukan secara otonom oleh tim dari waktu ke waktu. Jika pada tahap epic di Jira detail implementasinya belum jelas, tugas pertama yang diberikan adalah menulis RFC. RFC bisa untuk internal tim kami saja, atau untuk seluruh tim software; untuk yang kedua, semua orang bisa membacanya dan meninggalkan komentar sebelum meeting dua mingguan. Walau berat, ini jauh lebih baik daripada bekerja di tempat yang tidak punya proses desain kolaboratif berbasis RFC.

  • Dari pengalaman saya, saya setuju soal design review. Dulu kami membuat dokumen desain formal dan mereviewnya, tetapi lalu beralih ke prototyping dan desain iteratif. Kami sering melewatkan detail penting pada tahap desain, dan karena sudah menghabiskan banyak waktu, akhirnya hal-hal itu cenderung dibiarkan begitu saja di tahap berikutnya. Mengumpulkan seluruh tim untuk review juga tidak efisien, jadi isu-isu akhirnya tetap ditemukan saat code review. Banyak juga orang yang tidak pandai menulis dokumen desain atau tidak punya motivasi. Pada akhirnya, dengan lebih dari 5 orang, inefisiensi seperti ini sulit dihindari. Lingkungan ideal adalah PO, pengguna utama, dan sekitar 5 developer yang bekerja bersama.

• Sangat menarik melihat tulisan di HN tentang stacked pull request. Saat dulu memulai graphite.dev, banyak orang yang tidak punya latar belakang FB atau Google bahkan tidak mengenal alur kerja seperti ini. Menarik melihat tren code review berubah sangat cepat dalam 3–4 tahun terakhir.

  • Sebagai pengguna arcanist sejak sebelum mercurial, saya aktif merekomendasikan Graphite kepada tim yang masih kesulitan dengan PR besar dan merge commit. Saya sangat terkesan dengan keberanian dan hasil yang memungkinkan integrasi dengan PR. Akan menarik jika Graphite punya mode preskriptif yang menginisialisasi repo dengan setup hardcore sehingga bisa membuat asumsi yang lebih kuat.

  • Graphite adalah solusi yang keren, tetapi harganya cukup mahal dan sulit meyakinkan pengambil keputusan untuk membelinya. Saya berharap alat sekeren Graphite bisa menjadi open source atau dibangun langsung ke dalam GitHub.

  • Saya juga merindukan fig workflow

  • Insiden keamanan terbaru di CodeRabbit membuat saya enggan mencoba alat baru yang mengintegrasikan LLM dengan codebase. Eksperimen baru yang menarik bisa dengan mudah berubah menjadi masalah keamanan.

  • stacked pull request pada dasarnya menambahkan kompleksitas yang sebenarnya tidak perlu. Perubahan yang kecil dan sering jauh lebih baik sebagai praktik pengembangan. trunk-based development atau continuous integration jauh lebih cocok untuk tujuan itu.

• Semakin banyak developer tampaknya sepakat tentang "seperti apa seharusnya alat review itu". Sekarang yang penting adalah organisasi dan pemain yang bisa membuatnya benar-benar dapat diterapkan di dunia nyata dan berkelanjutan. Adopsi git change-id baru-baru ini adalah perkembangan yang baik (terima kasih untuk jj, git butler, gerrit, dan lainnya). Graphite dan GitHub berfokus pada solusi untuk penggunanya sendiri, bukan arah yang terbuka bagi semua orang. Banyak tool command line berbasis klien juga tidak terlalu berpengaruh. Yang benar-benar dibutuhkan adalah:

  • harus bisa digunakan sepenuhnya secara lokal
  • perlu dukungan resmi dari tim inti untuk vscode (UX yang bagus khusus untuk integrasi vscode)
  • aset UI sebisa mungkin dapat digunakan ulang untuk web UI seperti vscode web dan editor lain
  • fungsi inti tersedia dari CLI atau library, dengan batas yang jelas untuk ekstensi
  • mendukung commit/branch/stacked commit/agent snapshot/review oleh developer sendiri
  • mengintegrasikan sinyal CI/CD secara native, sambil memperkuat fondasi pekerjaan UI bagus yang ditunjukkan Meta
  • harus sangat fine-grained sesuai konteks dan bisa diedit di setiap tahap (contoh: di cursor bisa accept satu baris, review kode oleh manusia juga perlu pengeditan segranular itu)
  • harus sepenuhnya incremental, dan perlu cara mudah untuk hanya mereview perubahan yang dimodifikasi saat PR diperbarui, bukan keseluruhan lagi

• Keluhan terbesar saya tentang Github adalah aplikasinya terlalu lambat. Benar-benar sampai tab browser terasa macet. Azure DevOps adalah alat code review terbaik yang pernah saya gunakan sejauh ini.

  • Saya pernah menggunakan Azure DevOps untuk pengembangan .NET di lingkungan Microsoft, dan itu memang alat yang sangat cocok dengan ekosistem .NET

  • Saya penasaran apakah Anda pernah benar-benar serius memakai GitLab. Bagi saya, dari big 4, GitLab yang paling saya suka.

  • Saya penasaran bagian mana dari DevOps yang sangat Anda sukai. Saya memakainya setiap hari dan rasanya mirip github. Bahkan kadang saya kangen fitur penerapan otomatis untuk perubahan yang disarankan di github.

  • Penggunaan JavaScript dalam skala besar ditambah tekanan rilis cepat menciptakan lingkungan yang lambat seperti ini. Meski begitu, masih lebih baik daripada Atlassian

• Ide menggunakan git secara langsung untuk code review terasa menarik. Bisa langsung menyentuh perubahan secara lokal, yang sangat nyaman. Saya tidak paham kenapa review harus dipaksa terikat pada satu commit saja—pendekatan di mana reviewer langsung meng-commit komentar/perbaikannya ke branch PR juga menarik. Ini seperti hibrida antara github flow tradisional dan alur mailing list/patch ala Linux.

  • Saya penasaran apakah PR github itu read-only. Saya pernah melihat anggota tim memberi usulan perbaikan lewat komentar "suggestion" lalu perubahan itu diterapkan ke commit hanya dengan satu klik

  • Aneh jika review commit harus tunggal. Kalau ada beberapa reviewer, masalah edit bersamaan juga muncul, dan itu tidak cocok dengan kode. Lebih alami kalau review juga dikerjakan masing-masing di branch terpisah, lalu pada akhirnya di-squash & rebase. Kalau diskusinya panjang, comment commit juga bisa saling dirangkai. Yang penting data ini tersimpan di suatu tempat di luar main branch

• Saat mereview kode, saya lebih suka menariknya ke branch lokal, lalu melakukan soft-reset dan melihatnya seolah-olah saya yang menulisnya. Kalau commit-nya tidak dipecah dengan baik, tiap kolaborator harus memecahnya sendiri untuk review dan itu tidak efisien. Jika yang direview terlalu besar, sulit mengatakan siapa yang benar-benar memahaminya secara utuh. Keseluruhan bukan sekadar jumlah dari bagian-bagiannya.

  • Saya membagikan contoh fungsi shell sederhana untuk code review. Dalam kondisi clean tree, ia otomatis checkout branch review yang sudah dipreset, membuka diff di nvim, lalu membersihkan branch setelah selesai

  • Membuat commit yang baik dan PR yang dibangun dari commit itu adalah keterampilan yang sama pentingnya dengan menulis kode yang baik. Namun pada praktiknya, lebih banyak developer daripada yang dibayangkan ternyata lemah dalam memecah PR atau menulis pesan commit

  • Dalam tim kerja paralel data science, kami checkout 2–3 branch untuk code review

  • Untuk review PR saya menggunakan https://github.com/sindrets/diffview.nvim di Neovim. UI-nya mirip diff di vscode sambil memanfaatkan mode diff milik vim. Untuk review ringan, git log -p --function-context juga berguna

• Saya tertarik pada cara kerja di mana satu orang menulis draft pertama, lalu orang lain merapikannya dan melakukan merge. Penasaran apakah ada yang pernah benar-benar menjalankannya.

  • Saya setuju dengan gaya di mana lebih dari 90% coding dikerjakan satu orang, tetapi reviewer bertanggung jawab atas finalisasi dan merge. Di tempat kerja saya sebelumnya, reviewer memang selalu yang melakukan merge, dan kalau perubahannya besar mereka hanya menyampaikan komentar. Ini jauh lebih efisien daripada harus meminta orang lain menekan tombol approve satu per satu

  • Kalau ikut terlibat menulis kode review, saya merasa bisa memberi umpan balik yang jauh lebih mendalam. Struktur seperti ini membantu melihatnya sebagai "kode kita", bukan "kode saya/kode kamu". Ini cocok dengan budaya yang iteratif dan kolaboratif seperti TDD

  • Cara ini mirip asynchronous pair programming

  • Saya kenal orang-orang yang memakai pair programming dalam trunk-based development. Mereka menulis kode berdua, lalu kalau sudah OK langsung merge ke main, dan begitu tes lolos langsung deploy. Dalam praktiknya itu berjalan baik

• Saya memakai plugin ekstensi Github Pull Request di VSCode untuk review secara lokal, dan itu cukup nyaman. Bisa langsung memberi komentar dan melakukan review dari dalam editor.

  • Di web Github, saat file yang berubah banyak, beberapa file disembunyikan, tetapi di VSCode kita bisa bernavigasi dengan bebas sehingga jauh lebih nyaman. Karena fitur ini sudah diwujudkan dalam kombinasi VSCode/Github, saya menduga ini juga bisa diperluas ke editor lain

  • Memang membaik, tetapi tetap saja vendor lock-in dua arah antara Github dan VSCode masih sangat dalam

  • Membuka PR di web Github lalu menekan tombol “.” untuk langsung mereview di VSCode web juga merupakan pengalaman yang jauh lebih baik

• Saya sangat senang mendengar bahwa Git akan memiliki first class change ID! Ini mirip revision tracking untuk diffs di Phabricator milik Facebook. Saya penasaran ada tautan untuk mempelajarinya lebih lanjut

  • Masalah dasarnya adalah git tidak bisa mengelola informasi branch dengan baik. Fossil mengingat commit dibuat di branch mana. task branch itu sendiri berfungsi sebagai change ID. Tentu saja git juga harus tetap mengizinkan manipulasi histori, jadi solusinya tidak mudah

• Saya juga ingin menyebut Sourcehut. Ia mewarisi alur klasik pengiriman patch/issue/bug/diskusi lewat email, dan terintegrasi dengan mailing list serta CI. Drew Devault juga menyediakan sumber daya tentang cara mengirim dan menerima patch di git-send-email.io, git-am.io