12.7 Review sebagai Memahami Konsekuensi, Bukan Mencari Salah
Kualitas kode juga dijaga melalui review, tetapi senior engineer melihat review dengan cara yang berbeda. Banyak tim menjalankan code review seperti sesi audit: siapa yang membuat kesalahan, baris mana yang perlu diperbaiki, siapa yang lupa menangani kasus tepi. Suasananya seperti pemeriksaan kualitas di pabrik—produk diperiksa, cacat dicatat, pengembang diperingatkan. Senior engineer tidak melihat review seperti itu.
Bayangkan Anda menerima pull request dari rekan satu tim. Perubahannya kecil: menambahkan satu parameter ke fungsi validasi alamat. Kode terlihat benar, semua test hijau, tidak ada syntax error. Engineer junior mungkin langsung menyetujui karena "tidak ada yang salah secara teknis". Tapi senior engineer membaca diff yang sama dengan pertanyaan yang berbeda: apa yang bisa rusak karena perubahan ini?
Perhatikan contoh diff berikut:
- function validateAddress(address) {
- // validasi alamat
- return isValid;
- }
+ function validateAddress(address, strictMode = false) {
+ // validasi alamat
+ if (strictMode) {
+ // validasi tambahan
+ }
+ return isValid;
+ }
Sekilas kode ini benar, tapi senior engineer akan bertanya: "Apakah fungsi ini dipanggil dari modul lain yang tidak ikut berubah? Apakah parameter baru strictMode mengubah perilaku komponen dependen yang tidak menerima parameter ini?"
Pertanyaan itu mengubah segalanya. Alih-alih mencari kesalahan, senior engineer mencari konsekuensi. Ia membayangkan skenario: apakah fungsi ini dipanggil dari modul lain yang tidak ikut berubah? Apakah parameter baru ini akan mengubah perilaku komponen yang bergantung pada output fungsi ini? Apakah perubahan ini konsisten dengan keputusan desain yang sudah diambil sebelumnya? Apakah ada asumsi di tempat lain yang sekarang menjadi tidak valid?
Inilah yang membedakan membaca diff sebagai pemeriksa dan membaca diff sebagai pemikir sistem. Senior engineer membaca setiap baris perubahan dengan kesadaran bahwa kode tidak berdiri sendiri. Satu fungsi validasi bisa dipanggil dari sepuluh tempat berbeda. Satu perubahan tipe data bisa merambat ke tiga lapisan sistem. Satu flag baru bisa mengubah logika bisnis yang sudah berjalan setahun.
Senior engineer juga membaca diff untuk konsistensi desain. Ia tidak hanya bertanya "apakah kode ini benar?" tetapi juga "apakah kode ini cocok dengan arsitektur yang sudah ada?" Kadang kode yang benar secara teknis justru melanggar pola yang sudah disepakati tim. Misalnya, tim sepakat bahwa semua akses database harus melalui repository layer, tapi pull request ini menulis query langsung di controller. Kodenya berfungsi, tapi melanggar keputusan desain. Senior engineer akan menolak bukan karena kodenya salah, tapi karena konsekuensinya: ke depannya setiap orang akan meniru pola ini dan lapisan abstraksi perlahan runtuh.
Yang menarik, AI bisa membantu membaca diff dengan cepat. Ia bisa menunjukkan baris mana yang berpotensi bermasalah, fungsi mana yang terpengaruh, dan bahkan menyarankan perbaikan. Tapi AI tidak bisa menggantikan pertanyaan tentang konsistensi desain. AI tidak tahu keputusan arsitektural yang sudah diambil tim enam bulan lalu. AI tidak tahu mengapa tim memilih pola tertentu dan bukan yang lain. Pertanyaan tentang konsekuensi sistemik tetap membutuhkan pemahaman manusia.
Karena itu senior engineer tidak menyerahkan review sepenuhnya ke AI. Ia menggunakan AI sebagai asisten yang mempercepat pembacaan diff, tapi ia sendiri yang memutuskan apakah perubahan ini aman, konsisten, dan tidak merusak keseimbangan sistem. Ia membaca review sebagai latihan memahami sistem lebih dalam, bukan sebagai kewajiban administratif.
Setelah review selesai dan kode siap diintegrasikan, pertanyaan berikutnya adalah: bagaimana kita tahu bahwa kode ini benar-benar bekerja seperti yang diharapkan? Jawabannya bukan hanya dari review, tapi dari testing. Dan di sinilah senior engineer kembali menunjukkan perbedaannya: ia memilih testing sebagai bukti, bukan sekadar kewajiban.
