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