Sebagian pengembang lebih memilih code review "interdiff"

 (gist.github.com/thoughtpolice)
3 poin oleh GN⁺ 2024-09-12 | 1 komentar | Bagikan ke WhatsApp

Mengapa sebagian orang menyukai code review "interdiff"

Evaluasi alat code review Gerrit

  • Gerrit adalah alat code review open source yang bekerja bersama repositori Git
  • Anda dapat menulis patch di repositori dan mengirimkannya untuk ditinjau
  • Anda dapat meninjau kode yang ditulis orang lain dan menunjukkan masalah yang perlu diperbaiki
  • Code review pada umumnya merupakan ide yang baik
  • Dalam proyek open source, kode dapat di-merge, dan hal ini meningkatkan tanggung jawab serta utang teknis

Berbagai alat code review

  • Ada berbagai alat seperti Gerrit, GitHub, Phabricator, mengunggah file .patch ke bug tracker, atau mengirim email melalui git send-email
  • Masing-masing alat tersebut dapat bekerja dengan tingkat kemampuan yang berbeda-beda

Seri patch yang ideal

  • Seri yang terdiri dari 3 patch menunjukkan evolusi codebase secara bertahap
  • Perubahan harus dipisahkan secara logis, dan setiap patch harus bisa dibaca seolah-olah diterapkan secara terpisah
  • Melalui code review, seri ideal seperti ini dapat ditinjau

Cara code review GitHub: "diff soup"

  • GitHub pada dasarnya mendorong review dengan menambahkan commit baru di atas commit yang sudah ada
  • Hal ini terjadi karena desain UX dan berbagai alasan lainnya
  • Jika beberapa commit ditambahkan selama proses review, hubungan implisit antar-commit menjadi rumit
  • Penggunaan alat git blame dan git bisect menjadi lebih sulit

Cara yang lebih baik: review "interdiff" (AKA git range-diff)

  • Alih-alih menambahkan commit baru, versi baru dari commit asli dipublikasikan
  • git range-diff digunakan untuk membandingkan perbedaan antar-versi commit
  • Reviewer dapat melakukan review inkremental tanpa harus membaca ulang seluruh diff
  • Alat git blame dan git bisect bekerja dengan lebih andal

Penjelasan tambahan: strategi merge patch

  • Metode di atas tidak bergantung pada strategi merge (misalnya git rebase vs commit git merge dengan multi-parent)

Penjelasan tambahan: apakah git rebase itu jahat

  • git rebase tidak masalah. Hanya saja, sebaiknya jangan digunakan pada branch publik yang commit-nya akan dijadikan dasar oleh orang lain

Catatan lain

Kesimpulan

  • Sistem review interdiff mendorong patch yang lebih kecil dan lebih cepat di-merge ke branch utama
  • Sistem ini memberikan pengalaman code review yang lebih baik bagi reviewer maupun penulis

Ringkasan GN⁺

  • Artikel ini memberikan analisis mendalam tentang alat dan metodologi code review
  • Metode review interdiff dapat sangat meningkatkan efisiensi code review
  • Ini membantu menyelesaikan masalah "diff soup" di GitHub
  • Artikel ini menyajikan faktor-faktor penting yang perlu dipertimbangkan saat memilih alat code review
  • Alat dengan fungsi serupa antara lain GitHub, Gerrit, dan Phabricator

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-12
Komentar Hacker News

  • Alur kerja yang umum digunakan di GitHub sebagian besar menambah beban kerja dan kurang jelas bagi kolaborator

    • Memungkinkan reviewer melihat perbedaan yang mengintegrasikan umpan balik tanpa merusak git blame dan git bisect
    • Saat mengintegrasikan umpan balik reviewer, gunakan git commit --fixup <hash commit yang akan diperbarui>
    • Setelah PR disetujui, gunakan git rebase --interactive origin/main --autosquash untuk menggabungkan commit fixup ke commit aslinya
    • Terakhir, lakukan merge dengan git push --force-with-lease
    • Gunakan fitur pelengkapan otomatis agar perintah panjang lebih mudah diketik

  • Cara GitHub menangani code review tidak efisien, jadi sebelumnya hal itu ditangani secara manual dengan Phabricator

    • Akan lebih baik jika ada UI yang eksplisit

  • Menginginkan sistem yang lebih baik daripada cara GitHub menangani code review

    • Ingin cepat menggabungkan patch perbaikan bug kecil dan mempersempit cakupan review
    • Ada yang berpendapat agar dibuat sebagai review/PR terpisah, tetapi itu menimbulkan masalah dependensi antar patchset

  • Selalu menarik melihat pendekatan baru untuk code review

    • Pernah mempertimbangkan untuk membagi patch menjadi PR terpisah yang saling bergantung
    • Dengan alat seperti GitContext, PR bisa tetap kecil sambil mempertahankan dependensi
    • AI dapat digunakan untuk merangkum PR dan review serta menghasilkan pesan commit yang akurat
    • Reviewer hanya bisa melihat perubahan sejak review terakhir

  • Interdiffs pertama kali diperkenalkan di Review Board, dan ini sangat berguna dalam code review

    • Commit fix-it bukan alternatif yang tepat
      1. Tidak menunjukkan perubahan upstream
      2. Membuat graf commit menjadi rumit
      3. Tidak semua orang menggunakan Git
    • Interdiffs memungkinkan reviewer mengikuti semua pembaruan sejak permintaan review pertama
    • Berguna saat beberapa commit dipublikasikan sebagai satu permintaan review

  • Pernah menggunakan sistem code review Gerrit, dan code review GitHub tidak efisien

    • Gerrit mendukung penumpukan beberapa patch, sehingga patch kecil mudah direview
    • Antarmuka GitHub terlihat seperti thread forum dan tidak bisa melacak rebase

  • Pernah menggunakan berbagai sistem code review, dan masing-masing punya kelebihan serta kekurangan

    • Critique dioptimalkan untuk monorepo Google dan VCS kustom
    • Gerrit bagus untuk reviewer, tetapi kurang nyaman bagi penulis
    • GitHub ramah bagi penulis, tetapi tidak efisien untuk reviewer dan tim
    • Penting menggunakan alat code review yang lebih baik

  • Setelah menggunakan sistem code review Gerrit, stacked PR di GitHub terasa merepotkan

    • GitHub tidak menampilkan perubahan terhadap komentar code review dengan baik
    • Beberapa skrip digunakan untuk mempermudah pekerjaan dengan stacked PR
    • Alat seperti ejoffe/spr dan spacedentist/spr berguna