Code Review Memerlukan Pembacaan

• Code review bukan sekadar prosedur formal sebelum deployment, melainkan proses memindahkan tanggung jawab atas insiden, masalah keamanan, dan penghapusan data dari satu individu menjadi tanggung jawab tim
• Penilaian, pengujian, feature flag, guardrail, observability, dan hal-hal serupa yang lebih baik bisa jadi merupakan jawaban untuk mengurangi kecemasan saat melakukan deployment terhadap kode yang belum dibaca, tetapi dikritik karena melewatkan tujuan review, yaitu penyebaran tanggung jawab
• Tuntutan untuk menyetujui tanpa membaca sama saja dengan menyuruh orang menekan tombol tanpa berpikir, yang berujung pada satire button roulette: menggabungkan PR acak dengan semua CI berstatus hijau
• Code review membuat anggota tim melihat berbagai bagian dari codebase yang besar sehingga menurunkan bus factor, sekaligus berfungsi sebagai sarana belajar bagi anggota baru untuk memahami kode dan budaya kode
• Kesimpulannya, jika ingin memaksa deployment kode yang belum dibaca, diperlukan pembebasan tanggung jawab tertulis atas bug, masalah keamanan, downtime, dan sebagainya; dan pembebasan seperti itu sulit diperoleh

---

Tujuan review adalah penyebaran tanggung jawab, bukan persetujuan

• Titik berangkatnya adalah pertanyaan dalam tulisan Charity Majors “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy” tentang “apa yang dibutuhkan agar kita merasa nyaman mendeploy kode yang belum dibaca ke production”
• Jawaban seperti evals yang lebih baik, testing, feature flag, guardrail, observability, pemisahan dependensi, mengecilkan blast radius, dan memulai dari perubahan kecil di luar jalur kritis diperlakukan sebagai jawaban yang meleset dari inti review
• Tujuan review adalah membagi beban atas insiden, masalah keamanan, dan penghapusan data yang tidak disengaja agar tidak berada pada satu individu saja, melainkan menjadi tanggung jawab tim yang dibagi antara penulis dan seluruh reviewer
• Jika yang diminta adalah “setujui tanpa membaca”, maka alasan meminta manusia menekan tombol secara manual menjadi semakin lemah, dan muncullah satire button roulette, yakni menggabungkan salah satu PR yang ditugaskan secara acak selama semua CI berstatus hijau

Apa yang hilang dari review tanpa membaca

• Code review memaksa anggota tim melihat bagian lain dari codebase, sehingga membantu mengatasi keterbatasan bahwa dalam sistem yang terlalu besar, mustahil selalu mengetahui semua bagiannya setiap saat
• Proses review membantu menurunkan bus factor dan membuat lebih banyak anggota tim semakin akrab dengan codebase serta budaya penulisan kode tim
• Jika semua orang menyetujui tanpa membaca, efek pembelajaran ini hilang, bus factor bukan hanya naik menjadi 1, tetapi juga menimbulkan masalah dialihdayakan ke pihak ketiga
• Ringkasnya, untuk menerima tuntutan mendeploy kode yang belum dibaca ke production, orang yang memberi instruksi itu harus memberikan pembebasan tanggung jawab tertulis atas bug, masalah keamanan, downtime, dan sebagainya

[GN⁺]

Opini Lobste.rs

• Saya sangat tidak setuju dengan klaim bahwa tujuan review adalah membagi tanggung jawab
  Jika kode yang di-merge ke main merusak production, itu tanggung jawab penulisnya, bukan tanggung jawab saya atau seluruh tim
  Sebagai seorang profesional, itu adalah pekerjaan yang ditandatangani atas nama sendiri; jika desain jembatan yang dicap dengan lisensi P.E. teknik sipil menewaskan orang, itu juga tetap pekerjaan dan tanggung jawab dirinya sendiri
  Tanggung jawab tim adalah, sebagai developer sekaligus pengelola codebase, membuat siapa pun tidak bisa merusak production

  • Saya rasa pola pikir bahwa jika kode yang di-merge ke main merusak production maka itu tanggung jawab individu bukanlah budaya yang sehat
    Merge ke main berarti seseorang telah mereview, menelaah perubahan, berdiskusi soal desain, merevisi berkali-kali, lalu menyetujuinya
    Tidak ada orang yang membangun Menara Eiffel sendirian, dan menyalahkan individu di tempat kerja hanya akan melahirkan dendam dan budaya yang toksik
    Jika itu adalah pola perilaku yang berulang, maka itu urusan HR
  • Jika reviewer sama sekali tidak memikul tanggung jawab, maka itu sama saja seperti tidak ada review
    Jika tanggung jawabnya 0, reviewer tidak berguna dan tidak ada alasan untuk repot melakukan review
    Pembagian tanggung jawab lebih merupakan hasil, dan tujuan utamanya adalah menangkap kesalahan yang mudah luput jika dikerjakan sendirian tetapi lebih sulit terlewat jika ada dua orang atau lebih
    Namun saya juga merasa review terlalu sering dipakai dalam software, dan review tidak bisa menjadi pengganti engineering

• Saya rasa tidak tepat menyamakan “menyetujui tanpa membaca kode” dengan “menyetujui tanpa berpikir”
  Misalnya, bagaimana jika program dilengkapi bukti kebenaran, lalu di PR kita bisa membaca definisi dan teorema, CI memverifikasi secara deterministik bahwa program dan buktinya cocok, kebutuhan nonfungsional seperti rasio kontras, benchmark performa, dan tail latency juga diperiksa, dan perubahan UI bisa diuji-coba dengan mudah lewat prototipe
  Bahkan di dunia seperti itu pun, saya ragu kita perlu sebegitu terobsesi seperti sekarang untuk membaca kode baris demi baris
  Bahkan hari ini pun, kebanyakan orang saat menulis SQL tidak memverifikasi satu per satu apakah query plan benar-benar persis sesuai yang mereka inginkan
  Tulisan aslinya terasa lebih seperti “mari definisikan dunia ideal di mana kita merasa nyaman melakukan deploy tanpa harus membaca kode secara harfiah”, lalu setelah itu bertanya “bagaimana kita bisa bergerak mulus dari kondisi sekarang ke dunia tersebut”
  Kita bisa berdebat soal seberapa jauh industri, atau perusahaan dan codebase tertentu, dari titik itu, tetapi jika dunia ideal itu dibayangkan dengan serius, kebanyakan orang mungkin bisa menyebut beberapa kriterianya
  Saya paham mengapa, karena arah industri saat ini, orang menangkapnya sebagai “tanpa berpikir”, tetapi menurut saya bukan itu yang dimaksud tulisan Charity

  • Inti tulisan aslinya bukan menangkap masalah di PR, melainkan menjadi akrab dengan codebase dan membangun rasa tanggung jawab
    Ini hanya bisa terjadi dengan membaca kode, sebaik apa pun test-nya
    Jika Alice memasukkan kode, Bob mereview-nya, lalu Alice pergi cuti, Bob harus cukup memahami bagian itu dan merasa bertanggung jawab sehingga bisa memperbaikinya atau menambahkan fitur baru
    Jika Bob hanya memberi stempel pada bukti kebenaran, maka setelahnya ia belum siap menangani codebase itu
    Meski ikut dalam proses commit, jika pengetahuan atau rasa memiliki tidak bertambah, pada dasarnya itu sama saja seperti tidak ikut berpartisipasi
  • Penjelasan ini terlihat mirip dengan compiler pada umumnya
    Hanya saja compiler bersifat deterministik, sedangkan LLM adalah alat nondeterministik yang berpotensi menghasilkan test yang meragukan
    Kita sebenarnya sudah punya program yang mengubah instruksi atau kode buatan manusia menjadi kode atau representasi perantara yang bisa dibaca mesin, dan karena ada jaminan hubungan tertentu antara input dan hasil generasinya, kita bisa mempercayai output tanpa harus memeriksanya satu per satu
    Untuk optimisasi memang kadang kita membaca output compiler dengan alat seperti Godbolt, tetapi selain itu biasanya tidak perlu
    Jika ini dicoba pada level abstraksi lain yang nondeterministik, itu mungkin tampak masuk akal, tetapi pada dasarnya hanya meniru jaminan kebenaran yang diberikan compiler dan pada akhirnya akan menimbulkan masalah
    Perdebatan soal LLM, pada tingkat yang lebih mendasar, menurut saya adalah gejala dari masalah bahwa bahasa pemrograman deterministik yang ada belum cukup ekspresif dan alatnya belum cukup efektif
    LLM mungkin terasa seperti menyelesaikan masalah itu, tetapi sebenarnya bukan solusi; itu hanya menambahkan satu lapisan perantara lagi beserta biaya performa di atas fondasi yang sudah terlalu terbatas
    Saya melihatnya lebih seperti pseudo-compiler yang mahal dan penuh bug, berjalan di atas interpreter, lalu di atas machine code yang dikompilasi lagi
    Karena itu saya menganggapnya jalan buntu secara teknis
    Bagi perusahaan itu mungkin jalan menuju keuntungan jangka pendek, tetapi saya tidak percaya itu akan memperbaiki software atau hubungan manusia dengan software, baik saat menggunakannya maupun saat membuatnya
    Software lebih dari sekadar teknologi untuk merilis produk

• Akan membantu jika dipisahkan menurut kegunaannya
  Kalau hanya mengunggah JavaScript baru untuk UI aplikasi internal, saya rasa tidak masalah kalau kita tidak harus memeriksa sampai ke CSS