Mengapa Sebagian Developer Lebih Menyukai Review Kode interdiff

• Review PR ala GitHub mudah membuat commit perbaikan terus ditumpuk di atas perubahan awal, sehingga proses review dan riwayat kode final menjadi tercampur
• Patch series yang baik seharusnya bisa dibaca sebagai commit yang dipisahkan secara logis secara berurutan, seperti refactoring, penambahan API baru, dan migrasi pengguna lama
• Jika commit seperti “fix review” atau "minor" menumpuk, maksud perubahan menjadi kabur, dan biaya untuk menemukan penyebab masalah dengan git blame serta git bisect meningkat
• Review interdiff menerbitkan versi baru dari patch series dan membandingkan perbedaan perubahan per commit dengan git range-diff main..v1 main..v2
• Reviewer dapat memeriksa hanya 50 baris tambahan/perubahan tanpa membaca ulang seluruh 500 baris, sementara penulis dapat mempertahankan struktur commit final tanpa commit berisik seperti “address review”

---

Alat review kode dan titik awal

• Gerrit Code Review adalah alat review kode open-source yang bekerja bersama repositori Git, mendukung alur untuk mengirim patch, membuat orang lain meninjau kode, dan meninggalkan komentar
• Cara review kode beragam, bukan hanya Gerrit, GitHub, dan Phabricator, tetapi juga mengunggah file .patch ke bug tracker, git send-email, hingga mendorong implementasi setelah diskusi panjang dengan rekan kerja
• Bahasa pemrograman Go menggunakan Gerrit, KDE dan LLVM pernah menggunakan Phabricator, dan Jujutsu pernah mempertimbangkan penggunaan Gerrit
• Kernel Linux menggunakan workflow berbasis email dengan cara khusus, sementara banyak proyek memilih GitHub karena mudah digunakan dan biaya untuk memulainya rendah
• Masalah utamanya adalah alat-alat tersebut tidak menyediakan model review yang sama, dan pengalaman default GitHub tidak selalu memadai

Syarat patch series yang baik

• Patch series yang ideal adalah bentuk pengiriman satu perubahan besar yang dibagi menjadi tahap-tahap logis
  • Pertama, melakukan pembersihan kode yang kebetulan ditemukan
  • Berikutnya, menambahkan API baru
  • Terakhir, memigrasikan pengguna API lama ke API baru
• Setiap patch harus memiliki alasan yang independen, dan ketika diterapkan secara berurutan, harus terlihat bagaimana kode berevolusi secara bertahap
• Struktur seperti ini menguntungkan bukan hanya penulis dan reviewer, tetapi juga maintainer yang kelak perlu mencari alasan perubahan dengan blame atau bisect
• Ukuran patch sebenarnya bergantung pada situasi
  • Bisa saja tidak ada refactoring
  • Bisa saja 100 baris
  • Jika berupa perubahan API inti yang mengharuskan semua call site diperbaiki, bisa menjadi 500 baris

Riwayat campuran yang dibuat oleh “diff soup” ala GitHub

• Saat menanggapi komentar review, GitHub secara eksplisit maupun implisit mendorong alur untuk menambahkan commit baru di atas commit awal
• Dalam contoh, setelah 3 commit awal, commit untuk menanggapi review Alice dan Bob, penambahan test, serta perubahan implementasi "minor" ditumpuk satu per satu
• Karena grafik commit hanya menyisakan relasi parent-child, tidak terlihat commit perbaikan review itu memperbaiki masalah apa di commit awal yang mana
  • Jika satu commit “fix review” menyentuh beberapa commit awal sekaligus, model konseptualnya menjadi lebih rumit
  • Satu commit perbaikan bisa dibuat agar mencerminkan tepat satu poin yang ditunjukkan, tetapi jumlah commit fixup akan bertambah sebanyak itu
• Bentuk yang mencampur kumpulan perubahan besar dan perbaikan review dalam satu mangkuk seperti ini disebut “diff soup”

Sinyal git blame dan git bisect menjadi kabur

• Karena git blame bekerja per baris, meski commit tanggapan review hanya mengubah sebagian kecil dari baris yang sudah ada, asal baris tersebut bisa terlihat sebagai commit seperti "fix alice review"
• Untuk menemukan alasan perubahan yang sebenarnya, diperlukan arkeologi commit dengan menelusuri lagi commit awal dan commit perbaikan review
• Dalam git bisect, bisa menjadi tidak jelas apakah commit "minor" benar-benar penyebabnya, atau bug yang sudah ada sejak API baru pertama kali ditambahkan baru belakangan terlihat
• Jika API baru memberikan peningkatan performa besar, melakukan revert mungkin tidak diinginkan atau bahkan tidak mungkin
• Jika regresi muncul beberapa minggu kemudian, dalam situasi mendesak seperti rapat P1, akan ada biaya investigasi tambahan hanya karena melihat pesan commit "minor"
• Bahkan dalam contoh dengan hanya dua putaran review, riwayat menjadi rumit; dalam proyek open-source yang review-nya berulang berkali-kali, masalahnya makin besar

Cara UX GitHub memperkuat alur ini

• Untuk melakukan review inkremental di GitHub, cara yang praktis paling mudah adalah menambahkan commit baru di atasnya
  • Bagi reviewer, melihat patch "fix alice review" berukuran +/- 10 baris lebih ringan daripada membaca ulang 500 baris API baru
• Tab diff pada PR secara default menggabungkan semua commit menjadi satu diff
  • Ini mirip dengan melihat git diff master..foo-branch
  • Tidak terlalu cocok dengan cara orang menulis dan membaca perubahan
• UX GitHub sangat disesuaikan dengan model branch bernama, sehingga menyulitkan untuk melihat perbedaan antarunit selain branch
• Setelah force push, diff bisa dilihat lewat tombol “Compare” pada baris “Force Push” di PR
  • Namun itu hanya menampilkan diff keseluruhan antara head branch sebelumnya dan head branch saat ini
  • Untuk perbandingan yang lebih detail, harus mencari ID commit secara manual dan memasukkannya ke URL

Review interdiff dan git range-diff

• Review interdiff tidak menambahkan commit perbaikan di atas 3 commit awal, melainkan menerbitkan versi baru yang terdiri dari 3 commit yang sama
• Misalnya, jika komentar Bob perlu diterapkan pada patch series v1, commit pertama dan ketiga diperbaiki untuk membuat series v2
• Setelah itu, meski komentar Alice, penambahan test, dan perubahan "minor" diterapkan dengan cara yang sama, hasil akhirnya tetap berupa 3 commit
• Jika commit A, B, C pada v1 berevolusi menjadi X, Y, Z pada v2, git range-diff menampilkan perbedaan antar-commit di tiap posisi

git range-diff \
  main..v1 \
  main..v2

• Perintah ini menampilkan diff berpasangan antara 3 commit di branch v1 dan 3 commit di branch v2
  • Commit pertama adalah diff(A, X)
  • Commit kedua adalah diff(B, Y)
  • Commit ketiga adalah diff(C, Z)

Dampak praktis pendekatan interdiff

• Berbeda dari GitHub yang biasanya menampilkan diff seluruh branch seperti diff(main, C) atau diff(main, Z), interdiff menampilkan perbedaan antarversi commit
• Reviewer dapat memeriksa hanya 50 baris yang diubah tanpa membaca ulang perubahan API 500 baris yang sudah pernah dilihat
• Penulis tidak perlu menumpuk 30 commit berisik seperti “address review” di histori
• git blame menjadi lebih mungkin menghubungkan baris ke commit perubahan awal dengan lebih sedikit noise
• git bisect menjadi lebih mungkin menunjuk regresi ke unit yang lebih bermakna seperti commit API baru
• Hasilnya, rasio sinyal terhadap noise pada alat diagnosis dasar menjadi lebih baik

Catatan tentang strategi merge dan rebase

• Penjelasan tentang strategi merge patch masih ditinggalkan sebagai TODO
• Posisinya adalah git rebase tidak masalah selama bukan pada public branch yang diharapkan akan menjadi dasar commit orang lain
• Sistem review interdiff mendorong patch yang lebih kecil dan bisa di-merge lebih cepat
  • Tidak perlu menunggu sampai semua 5 commit siap
  • Jika 3 commit awal sudah baik dan 2 commit belakang masih perlu diperbaiki, cukup merge 3 commit saja
• Tujuannya adalah membuat orang bekerja berbasis branch main, bukan long-lived branch, sehingga mengurangi situasi ketika banyak remote branch saling bertaut dan di-merge satu sama lain
• Ada juga proyek seperti kernel Linux yang me-merge public branch dengan repositori lain atau secara eksplisit memublikasikannya di atas branch lain
  • Developer Linux dapat menggunakan git rebase saat membuat dan memoles patch series
  • Namun setelah membuat public branch, karena branch itu bisa di-merge ke tree seseorang, mereka tidak melakukan force push dan membuat branch baru berisi commit baru

[GN⁺]

Komentar Hacker News

• Di GitHub, saya umumnya memakai alur seperti ini, tetapi kekurangannya adalah pekerjaan saya jadi lebih banyak dan tidak intuitif bagi kolaborator
  Meski begitu, keuntungannya tetap ada: reviewer bisa melihat diff yang hanya berisi perubahan dari feedback mereka, dan git blame serta git bisect tidak rusak
  Saat menerapkan feedback review, saya membuat commit dengan git commit --fixup , lalu setelah push saya meninggalkan hash commit fixup di balasan komentar review
  Setelah PR disetujui dan tepat sebelum merge, saya menjalankan git rebase --interactive origin/main --autosquash untuk menggabungkan commit fixup ke commit asalnya, lalu terakhir git push --force-with-lease dan merge
  Perlu hati-hati melakukan force push sebelum review selesai. Jika begitu, reviewer tidak bisa melihat apa yang ditambahkan sejak review terakhir
  Saya sangat mengandalkan autocomplete terminal, jadi mengetik sekitar git re saja sudah bisa sampai ke perintah yang panjang, tetapi ini agak kasar; akan bagus jika ada tool yang mendukung dan mendorong alur ini. Namun kalau memang terikat pada GitHub, cara ini cukup oke

  • Saya juga hendak mengatakan hal yang sama. Rebase interaktif cukup banyak menyelesaikan masalah “diff soup” yang dikeluhkan penulis
    Namun ini cenderung benar-benar dipakai hanya di tim engineering yang disiplin dan sengaja mempelajari fitur tingkat lanjut git
  • Masukkan konfigurasi berikut ke ~/.gitconfig
[rebase] autosquash = true
    Dengan begitu, setelahnya cukup git rebase -i origin/main, commit fixup/squash akan otomatis diurutkan ulang. Ini pengaturan kecil, tetapi sangat memperbaiki alur kerja
  • https://news.ycombinator.com/item?id=37086022
  • Commit fixup juga pendekatan yang bagus, tetapi secara pribadi saya tidak menyukainya. Menurut saya cara seperti perintah absorb di Sapling, yang secara otomatis menyerap perubahan ke diff terkait di atas SCCS weave internal dan meminta konfirmasi lewat UI interaktif, jauh lebih elegan
    Ini mirip area ketika --update-refs dibutuhkan saat me-rebase rangkaian commit yang ditumpangi beberapa branch. Mengapa manusia harus melacak relasi graf, memasukkan commit sendiri, dan memindahkan branch? Komputer pandai menangani graf, jadi serahkan saja padanya
    Ada juga git absorb, tetapi tidak sekokoh implementasi Sapling[1]
    Masalah sebenarnya bukan soal rebase interaktif atau bukan, melainkan umumnya pengalaman pengguna dari tool review itu sendiri dan struktur siklus yang didorongnya. Misalnya commit fixup tidak menyelesaikan masalah GitHub yang menampilkan diff antar titik acuan, dan jika titik acuannya besar, review bisa benar-benar berantakan. Contohnya ketika rebase di atas 10 commit baru
    Saya juga tidak puas dengan UX Git itu sendiri, tetapi tulisan aslinya lebih terasa sebagai keluhan tentang GitHub
    [1] Contoh yang menunjukkan perbedaan dua algoritma dasarnya ada di issue GitHub ini: https://github.com/martinvonz/jj/issues/170
  • Alias Git benar-benar terasa seperti sihir

• Saya 100% setuju bahwa cara ini ideal. Cara GitHub benar-benar buruk, dan tragedinya adalah terlalu banyak orang jadi menganggapnya sebagai hal wajar
  Dulu kami melakukan ini dengan Phabricator, dan berkat macro command-line yang memperbarui semua review sekaligus, ini sampai batas tertentu bisa dilakukan secara manual. Tetap saja, akan lebih baik jika ada UI eksplisit

  • Saya penulisnya, dan saya sengaja memakai frasa “code review pada umumnya adalah ide yang cukup bagus” di bagian awal. Itu karena dulu frasa tersebut salah satu kalimat promosi di halaman utama Phabricator :) Rindu rasanya

• Betul. Inilah yang saya bayangkan di kepala sebagai gaya code review yang sesungguhnya, bukan cara yang dilakukan GitHub. Senang mengetahui bahwa ini punya nama
  Selain itu, saya ingin sistem review bisa mendorong patch yang sudah siap “keluar” dari review. Perbaikan bug kecil yang dibuat saat mengerjakan fitur besar seharusnya menjadi patch kecil dan independen, dan kemungkinan besar bisa cepat disepakati dengan reviewer
  Lalu saya ingin mengeluarkan patch itu dari keseluruhan series, men-cherry-pick-nya ke main, dan me-rebase review ke atas HEAD baru. Atau bisa juga me-rebase series patch terbaru ke atas main sambil mengurutkan ulang patch yang sudah disepakati ke paling depan, lalu melakukan fast-forward main ke patch itu
  Pada dasarnya maksudnya adalah mempersempit cakupan review ke “bagian yang masih didiskusikan”, tetapi bug fix bisa langsung di-merge begitu siap
  Sanggahannya mungkin “buat saja review/PR terpisah”, tetapi itu menimbulkan kerumitan seperti patchset A bergantung pada patchset B, lalu setelah B di-merge, A bergantung pada main

  • Saya terus-menerus mengulanginya, tetapi Gerrit pada dasarnya melakukan itu :) Di Gerrit, Anda bisa melihat hubungan antara sembarang dua patch, dan yang lebih penting, setiap patch ditampilkan secara individual. Jadi dalam series A -> B -> C, jika B kecil dan oke, B bisa langsung dimasukkan
    Di sini, ide UX cerdas seperti Attention Set juga berperan. Pada dasarnya ini menunjukkan “siapa yang harus melakukan tindakan berikutnya?”, dan bekerja seperti game berbasis giliran. Jika saya baru saja melakukan review, maka saya tidak lagi ada di attention set patch tersebut; yang ada adalah penulisnya
    Jadi di UI Gerrit, item itu turun ke bagian bawah antrean saya. Di bagian paling atas antrean ada item-item yang memasukkan saya ke attention set. Secara alami pekerjaan terkelompok seperti itu
    Ini belum membahas semua masalah kecil lain yang menjengkelkan pada UX GitHub, tetapi bahkan daftar pull request-nya pun lebih buruk daripada alternatif. Anda tidak bisa tahu item mana berada dalam status apa, dan akhirnya harus membaca semuanya
  • Gerrit bisa melakukan persis itu. Jika Anda push rantai x-b-c-d-e, UI akan menampilkannya sebagai tumpukan, tetapi Anda bisa dengan mudah men-cherry-pick b ke main, memastikan CI lulus dan review biasa selesai, lalu me-rebase sisanya ke atasnya
    Kalau yang paling bawah adalah x, Anda bisa langsung submit dan melanjutkan sisanya

• Melihat pendekatan baru untuk code review selalu menarik. GitHub juga punya kelebihan, tetapi masih jauh dari sempurna
  Untuk skenario yang diajukan, bisa dipertimbangkan membagi tiga patch menjadi pull request terpisah yang saling bergantung. GitHub memang tidak mendukungnya secara bawaan, tetapi alat code review yang tepat semestinya bisa menjaga pull request tetap kecil sambil tetap mengelola dependensi. Misalnya, patch 3 bisa bergantung pada patch 2, dan patch 2 bergantung pada patch 1
  Berkat pelacakan dependensi yang disediakan alat tersebut, jika perlu bisa dipastikan semuanya di-deploy bersama
  Jika setiap patch direview terpisah, feedback menjadi lebih jelas dan lebih mudah ditindaklanjuti. Di dalam pull request, commit juga bisa di-squash untuk membuat riwayat commit yang rapi dan secara tepat mencerminkan perubahan individual. Lebih jauh lagi, dengan alat yang tepat, AI bisa merangkum pull request dan review sehingga penulisan pesan commit yang akurat bisa disederhanakan tanpa kerja manual
  Alat code review yang baik seharusnya tidak terpengaruh oleh operasi git seperti rebase, merge, atau force push. Apa pun operasi git rumit yang terjadi di belakang layar, reviewer seharusnya hanya melihat perubahan sejak review terakhir. Dengan begitu mereka bisa fokus pada hal baru tanpa harus mereview ulang diff besar, dan riwayat review tetap bersih serta terpisah dari riwayat commit
  Saya penasaran apakah cara membagi pull request seperti ini dan melacak saling dependensinya akan memenuhi kebutuhan tersebut

  • Ungkapan “pendekatan baru untuk code review” itu terdengar positif dan sopan terhadap pemain lama yang kuat, tetapi ini sama sekali bukan ide baru
    Secara harfiah, ini adalah workflow yang memang dirancang untuk didukung oleh git, dan merupakan inti kritik lama yang terus diajukan sejak GitHub memiliki pull request
    Saya penasaran mengapa ide ini, setelah mengecek kalender, selama lebih dari 15 tahun diremehkan sebagai cara kerja “para dinosaurus mailing list”, lalu baru sekarang naik ke budaya pengembangan yang sedang tren
    Saya dulu berpikir banyak pengembang perangkat lunak sudah lama menolak mempelajari dengan benar salah satu alat yang paling banyak mereka pakai, sehingga mereka sengaja memilih workflow yang buruk. Jadi ketika memindahkan perusahaan ke git, saya memilih dan membuat alat serta alur seperti itu. Bagaimanapun juga, orang tidak akan dipecat karena membeli IBM
  • Setahu saya, cara membagi sebuah seri menjadi PR individual hanya benar-benar bekerja jika punya hak commit ke repositori. Dengan begitu satu PR bisa ditumpuk di atas branch lain di repositori utama, bukan di atas main
    Jika kontributor eksternal memakai fork repositori, tiga PR masing-masing akan berisi A, A+B, dan A+B+C secara bertahap. Akibatnya, pada dua PR terakhir, kode yang sudah direview di PR lain akan muncul lagi di diff, sehingga review menjadi sulit
  • Penulis sudah punya branch beserta commit-commitnya. Kalau begitu, apa tujuan membagi branch itu menjadi tiga pull request yang masing-masing berisi satu commit?
    Setiap commit bisa direview secara independen. Dependensi antar-commit juga bisa dilacak. Ketiadaan AI bawaan juga merupakan hal bagus. Tidak seperti PR, interdiff antar-commit juga bisa dilihat
    Commit adalah bahan dasar Git. Pakai saja commit
  • Seperti juga disebutkan di bagian lain thread ini, ini juga pendekatan yang diikuti Sapling
    Saya penasaran bagaimana GitContext melacak commit yang sudah melalui operasi seperti fixup, rebase, dan pengurutan ulang
  • Tidak bisakah memakai cara lama merge train saja? Pull request A menunjuk ke branch B, B menunjuk ke master, lalu merge B ke master dan setelah itu arahkan lagi A ke master, bukan begitu? Apakah saya melewatkan poinnya?

• Saya penulis artikel ini. Silakan tanya apa saja
  Sebagai tambahan, saya tidak tahu apakah ini melanggar aturan, tetapi belakangan saya membutuhkan pekerjaan baru. Saya suka bekerja di bidang development tools dan masalah-masalah sulit. Kalau Anda menyukai tulisan ini, ingin meningkatkan produktivitas tim developer, atau ingin merasakan dan menikmati selera saya yang luar biasa dan kadang eklektik, email saya ada di profil

  • Terima kasih sudah membuat saya tertawa :)
    Serius, resume Anda mengesankan. Semoga Anda segera mendapatkan tempat yang baik. Dari pengalaman mencari kerja yang sangat baru, pasar rekrutmen saat ini sedang sakit parah. Semakin senior dan berpengalaman seseorang, semakin menyakitkan bagi jiwa praktik wawancara/HR yang gila dan penolakan yang tidak bisa dijelaskan
    Seorang teman mengirimkan tautan-tautan di bawah ini
    https://danluu.com/hiring-lemons/
    https://danluu.com/programmer-moneyball/
    https://danluu.com/algorithms-interviews/
    Semoga beruntung
  • Anda merangkum dengan sangat baik model berpikir gaya review interdiff dan masalah pada pendekatan code review GitHub
    Satu hal yang belum dibahas adalah bahwa karena diff soup, orang bisa terdorong memilih strategi squash merge untuk menghilangkan “noise” dari commit fixup. Akibatnya, tiga commit atomik yang bagus di awal ikut dibuang
    Dalam gaya review interdiff, tiga commit awal tetap dipertahankan, dan apakah masing-masing akan disertakan apa adanya atau di-squash sepenuhnya bisa diputuskan berdasarkan commit itu sendiri dan atomisitasnya yang sebenarnya
  • Dari pengalaman memakai bagian gratis GitHub, istilah diff soup sangat tepat. Apakah versi berbayarnya lebih baik? Bisakah GitLab menjadi lebih mirip Gerrit?
    Ada juga layanan eksternal yang mencoba mengurangi rasa sakit GitHub dan menyediakan dukungan stacked diff, tetapi kelihatannya cukup mahal. Terutama jika dibandingkan dengan Gerrit yang self-hosted. Saya penasaran apakah Anda juga sudah melihat-lihat alat seperti ini
  • Saya penasaran apa pendapat Anda tentang GitLab yang mengatur Merge Request Dependencies dan strategi merge Squash+Merge
    Saya ingat dulu pola seri MR cukup mudah disusun. Jika 3 MR dimerge, akan muncul 3 merge commit yang masing-masing punya satu commit squash untuk tiap MR. Itu tidak bergantung pada riwayat commit MR
    Trade-off-nya adalah jika branch seri yang lebih awal berubah saat review, branch seri yang lebih belakang harus di-merge lagi
    Namun selama review, orang tetap boleh mengelola riwayat commit sesuka mereka. Toh nanti akan di-squash, jadi tidak masalah
    Namun sudah lama sejak saya melakukannya, dan akhir-akhir ini saya terikat pada GitHub, jadi mungkin saya melihatnya dengan kenangan yang terlalu indah

• Review Board [https://www.reviewboard.org] sudah membuat interdiff sejak 2006. Sebenarnya, mungkin akulah yang menciptakan istilah itu, atau bisa juga sampai pada istilah itu secara independen
  Sampai sekarang itu masih menjadi bagian favorit saya dari produk dan proses code review, dan salah satu fitur yang sering saya dengar paling dirindukan orang saat mereka pindah ke sesuatu seperti GitHub
  Commit fix-it tidak pernah terasa sebagai alternatif yang layak
  Pertama, itu tidak memberi tahu bagaimana perubahan di atasnya tercermin dalam rangkaian commit
  Kedua, meski hanya sementara, itu mengacaukan commit graph dan membuat review lebih sulit. Orang yang terus mengikuti review mungkin sudah membaca kode yang diperbaiki commit fix-it, tetapi orang yang baru masuk bisa memulai dengan kesan pertama yang buruk tentang apa yang ingin dilakukan kode itu atau bagaimana strukturnya
  Ketiga, tidak semua orang memakai Git atau sistem manajemen konfigurasi yang bisa menangani banyak commit. Dalam pengembangan game, Perforce sering dipakai, dan di produsen chip ada juga yang memakai sistem manajemen konfigurasi khusus seperti Keysight SOS. Di tempat seperti itu, commit fix-it sendiri bukan opsi
  Dengan sistem code review yang mendukung interdiff dengan benar, seorang reviewer bisa mengikuti semua pembaruan sejak permintaan review pertama dipublikasikan dan hanya melihat apa yang berubah, sementara reviewer lain bisa langsung masuk ke perubahan lengkap terbaru tanpa perlu memikirkan rangkaian fix-it. Dan ini bisa dilakukan terlepas dari sistem manajemen konfigurasi yang dipakai
  Jika dibuat dengan benar, ini juga bisa berdampingan dengan perubahan yang terdiri dari beberapa commit
  Misalnya, sebuah proyek kecil bisa dipecah menjadi beberapa commit untuk membantu review—API handler, UI front-end, dan dokumentasi—dan karena commit-commit itu saling terkait erat, mungkin masuk akal untuk mengunggahnya sebagai satu permintaan review. Jika keterkaitannya rendah, idealnya dibuat beberapa permintaan review dalam sebuah rantai dependensi
  Berdasarkan feedback review, Anda bisa membuat serangkaian perubahan pada salah satu atau semua commit tersebut. Saat orang meninjau pembaruan, akan lebih baik jika mereka bisa melihat bagaimana tiap bagian berevolusi, tanpa harus memetakan secara mental commit fix-it dan perubahannya ke perubahan awal yang bersesuaian
  Jadi interdiff benar-benar luar biasa. Baik untuk banyak commit kecil maupun commit besar, baik permintaan review satu commit maupun multi-commit, lebih banyak orang seharusnya memakainya

  • Benar-benar keren. Sebenarnya, di bagian 2 tulisan ini saya berencana membahas sejarah dan konteks politis yang membawa kita sampai ke alat-alat seperti ini
    Sekitar 2013, Glasgow Haskell Compiler pindah dari cara yang secara bercanda disebut “membaca file .patch dari bug reporter” ke penggunaan Phabricator. Ada beberapa alasan, tetapi saat itu bukan karena stacked diff. Alasannya adalah GitHub sangat buruk untuk review, bahkan tidak punya side-by-side diff. Dengan alasan itu saja GitHub sudah sepenuhnya tidak masuk pertimbangan, dan ada alasan lain juga
    Namun itu bukan pertama kalinya saya memindahkan tim ke alat code review. Pekerjaan pertama saya pada 2009 adalah di sebuah tim engineer yang sangat kecil dan erat di satu ruangan di Houston, dan saya berpikir bahwa jika orang lain mereview kode saya dan saya membaca apa yang mereka tulis, saya bisa memahami codebase dengan lebih baik
    Jadi selama beberapa bulan pertama setelah bergabung, saya terus mendesak manajer saya sampai ia memasang ReviewBoard, dan semua orang benar-benar menyukainya
    Jadi ini maksudnya ucapan terima kasih untuk RB. Sampai sekarang saya masih kadang mengingatnya dengan baik. Berkat itu, code review menjadi bagian yang sangat besar dari karier saya hampir sejak hari pertama, dan saya pikir sampai sekarang kita masih bisa melakukannya lebih banyak lagi

• Secara umum, saya merasa sistem seperti Gerrit, yang mengutamakan code review dan berpusat pada rebase, membuat kode jauh lebih mudah direview
  Salah satu hal terbaiknya adalah dukungan bawaan untuk menumpuk beberapa patch, yang mendorong orang membuat patch yang lebih kecil dan lebih mudah direview
  Code review di GitHub terasa seperti fitur tambahan belakangan yang buruk. Misalnya UI boros ruang yang terlihat seperti thread forum, dan ketidakmampuannya melacak melewati rebase

  • Ada satu hal yang terasa kurang saat push stack commit di Gerrit. Tidak ada tempat terpusat untuk membicarakan seluruh stack, bukan commit individual
    Diskusi teknis sekaligus “gambaran besar” seperti ini terlalu sering terjadi di issue tracker. Tapi saya juga tidak tahu harus menaruhnya di mana. Stack ini terlalu sementara dan bisa berubah total pada push berikutnya

• Saya sudah beberapa kali mendengar argumen untuk strategi seperti ini, tetapi tetap belum yakin. Sebagian besar proyek yang saya kerjakan menggabungkan feature branch dengan men-squash-nya menjadi satu commit, lalu menghapus riwayat branch
  Jika ada kasus seperti yang dijelaskan penulis, saya mungkin akan membuat refactoring, API baru, dan pembaruan sebagai 3 commit saja
  Praktik yang jelas-jelas baik bagi saya adalah menghindari branch yang berumur panjang. Skenario commit bertahap seperti ini biasanya muncul dari sana. Maksudnya, situasi ketika seseorang mengerjakan fitur selama beberapa hari, bahkan beberapa minggu, lalu ingin melemparkannya sekaligus
  Saya jauh lebih suka memindahkan perubahan ke main setiap hari, atau bahkan beberapa kali dalam sehari. Salah satu cara untuk itu adalah memakai feature flag agar commit yang masih dalam proses pun bisa masuk tanpa masalah. Jika sistemnya dikonfigurasi dengan benar, ada juga keuntungan bahwa fitur itu bisa dinyalakan dan diuji di lingkungan development dan staging. Ini juga tinggal selangkah lagi dari deployment blue/green
  Saya tidak ingin cara untuk membuat commit besar lebih mudah direview. Saya ingin memaksa tim melakukan commit perubahan kecil lebih awal dan lebih sering. Saya paham tidak semua orang akan setuju

  • Orang yang menyukai stacked diff mengatakan bahwa ini membuat perubahan lebih mudah diintegrasikan lebih cepat, berapa pun ukurannya
    Salah satu alasannya adalah, tidak seperti PR GitHub, hanya sebagian dari stack yang bisa diterapkan. Mengambil contoh di tulisan itu, jika diff “refactoring kecil” sudah siap, diff itu bisa dimasukkan lebih dulu tanpa harus sekaligus menerapkan diff “API baru” dan “migrasi pengguna API”
    Jika berpusat pada commit, bukan branch, efeknya adalah keseluruhan commit menjadi lebih kecil dibanding branch yang berumur panjang
  • Men-squash feature branch menjadi satu commit lalu menghapus riwayat branch itu buruk sekali
    Dengan begitu, git blame dan git bisect praktis menjadi tidak berguna
    Jika ada regresi, git bisect bisa mempersempitnya sampai ke satu patch. Karena itu, untuk fitur tertentu, lebih baik ada 50 patch masing-masing 160 baris dalam riwayat git daripada satu patch 8000 baris
    Jika satu baris kode terlihat mencurigakan, saya ingin git blame atau rangkaian perintah git blame mengarahkan saya ke commit 160 baris dengan pesan commit yang rinci, bukan ke commit 8000 baris
    Urutan commit asli juga harus dipertahankan. Bertahun-tahun kemudian, membaca pesan commit individual secara berurutan saja bisa sangat membantu untuk memahami desain awal. Tentu saja patchset awal harus disusun dalam urutan dependensi, harus bisa dikompilasi di setiap tahap, dan seterusnya, sehingga diperlukan tahap pengembangan terpisah di atas implementasi fitur. Kode harus disajikan dalam langkah-langkah yang logis

• Menarik. Di tempat kerja, kami memakai PR dengan cara penulis memakai commit, lalu pada akhirnya benar-benar melakukan squash-and-merge
  Namun dengan cara ini, setiap kali PR di depan diubah, PR-PR di belakangnya harus di-rebase. Cukup merepotkan, melanggar aturan “dilarang force-push”, butuh waktu lama untuk dipelajari engineer, dan cenderung merusak komentar code review yang sudah ada di UI GitHub. Meski begitu, untuk dua atau tiga PR masih lumayan berjalan
  Dalam alur kami, commit lebih mirip titik penyimpanan daripada unit kerja
  Saya juga banyak memakai stash dan banyak memakai undo-tree-mode di Emacs. Dengan begitu ada empat cara untuk melacak riwayat source code, yang terdengar redundan, tetapi dalam praktiknya berjalan cukup baik
  Usability Git untuk menangani hal ini cukup buruk. Phabricator memang lebih baik, tetapi tetap saja terasa tidak perlu sulit. Mungkin suatu tool version control baru bisa mendukung konsep yang lebih tinggi daripada commit dan branch sebagai first-class concept, atau mungkin itu justru akan membuatnya lebih buruk dipakai

  • Anda memakai commit seperti PR. Karena itu pekerjaan menjadi rumit akibat dependensi PR
    Apakah akan menyenangkan jika ada tool yang lebih baik daripada Git? Tentu, saya juga ingin tool yang lebih sedikit cacatnya dan lebih ramah pengguna. Tetapi sebagai solusi sementara, bagaimana kalau memperlakukan commit seperti commit? Tidak perlu sengaja membuatnya sulit sendiri
    Saya penasaran seberapa besar tanggung jawab GitHub dalam membuat orang melihat semuanya lewat kacamata PR
  • Sebaiknya lihat jj, sapling, mercurial

• Tulisan blognya bagus, dan menyenangkan melihat ada orang yang benar-benar memikirkan bagaimana code review seharusnya bekerja
  Saya sudah banyak memakai empat sistem code review dengan kelebihan dan kekurangan berbeda: Critique (internal Google), Gerrit (dipakai di Google, tetapi sama seperti yang eksternal), GitHub, dan CodeApprove yang saya buat
  Critique sejauh ini yang terbaik, tetapi itu dimungkinkan karena sangat pas dengan monorepo Google, sistem version control internalnya, serta tool lint/test kustomnya. CodeApprove dirancang untuk membawa sebanyak mungkin keunggulan itu ke GitHub, tetapi dalam praktiknya sulit untuk benar-benar mendekatinya
  Gerrit adalah yang kedua terbaik dari sisi pengalaman reviewer, tetapi sebagai author saya selalu tidak menyukainya. Rasanya ada lebih banyak cara untuk melakukan hal yang salah daripada cara yang benar, dan UI-nya juga tidak terlalu indah
  GitHub sangat ramah bagi author dan bekerja sesuai cara berpikir kita. Menulis kode, mendapat feedback, lalu menulis lebih banyak kode. Jika melakukan squash and merge di akhir PR, masalah riwayat yang disebut penulis tidak ada
  Namun, GitHub tidak terlalu ramah bagi reviewer atau tim. Diff incremental tidak ditonjolkan, diff dan percakapan berada di tab berbeda, sementara force push dan rebase merusak riwayat. Komentar menghilang sebagai “outdated”, file di luar jendela diff tidak bisa diberi komentar, file besar disembunyikan secara default, dan masih banyak masalah lain. Jelas GitHub tidak terlalu peduli dengan ini, dan mungkin saja mereka tahu sesuatu yang tidak saya ketahui
  Pada akhirnya, hal yang paling membuat frustrasi adalah banyak tim begitu saja menerima tool code review bawaan dari platform version control mereka. Itu seperti memakai IDE bawaan yang sudah terpasang di laptop. Sekarang ada jauh lebih banyak pilihan yang lebih baik. Selain CodeApprove, yang saya sukai adalah GitContext, Reviewable, dan Graphite, dan saya bisa menyebut setidaknya enam pilihan bagus lainnya. Jangan menerima default begitu saja

  • Masalahnya adalah GitHub tidak ramah bagi reviewer atau tim
    Reviewer dan maintainer jauh lebih langka daripada contributor. Menurut saya workflow dan UI harus dioptimalkan untuk throughput review
    Saya belum pernah memakai tiga tool lain yang disebutkan, jadi klaim saya bersifat umum