Hipotesis, logging, dan binary search

Setelah AI mengusulkan sebuah penyebab, jangan langsung menerimanya begitu saja. Uji dengan cara yang murah. Uji termurah biasanya adalah satu baris log.

Minta AI untuk menambahkan logging sementara:

"Sebelum kita mengubah apa pun, tambahkan console.log (atau print) yang menampilkan nilai user tepat sebelum baris 14, agar kita bisa lihat apakah nilainya memang undefined."

Jalankan, tempelkan outputnya kembali. Sekarang kamu punya bukti, bukan sekadar teori. Mungkin user memang undefined — mengonfirmasi hipotesis. Mungkin juga baik-baik saja dan penyebab sebenarnya ada satu level di atasnya. Bagaimanapun kamu sudah bergerak maju. Log secara berlimpah selagi kamu menyelidiki: nilai dari variabelnya, dan label yang menyatakan variabel mana itu dan di mana log itu berada. console.log(user) polos yang mencetak undefined jauh kurang berguna dibanding console.log("user at validate.js:14 =", user). Dan ingat untuk mencabut kembali log sementara itu setelah bug diperbaiki — sisa noise debug adalah kekacauan kecilnya sendiri.

Ketika bug berada di suatu tempat dalam proses yang panjang dan kamu tidak bisa menentukan di mana, gunakan binary search. Potong area yang dicurigai menjadi setengah: tambahkan log di titik tengahnya.

Idenya: setiap pemeriksaan membuang setengah dari yang tersisa, sehingga ruang pencarian yang sangat besar menyusut dengan cepat. Di sini sebuah bug bersembunyi di suatu tempat antara langkah 1 dan langkah 8 — tiga pemeriksaan sudah cukup untuk menyudutkannya:

   step:  1  2  3  4  5  6  7  8      a bug is somewhere in here
          ░░░░░░░░░░░░░░░░░░░░░░

   check 1 ── log at 4 ── OK ──▶  bug is AFTER 4, drop 1–4
                                  ░░░░░░░░░░░  (5 6 7 8 left)

   check 2 ── log at 6 ── BAD ─▶  bug is AT/BEFORE 6, drop 7–8
                                  ░░░░░  (5 6 left)

   check 3 ── log at 5 ── OK ──▶  bug is at step 6   ✔ found

   8 steps → 3 checks.  1000 steps → about 10 checks.

Apakah nilainya terlihat benar di titik itu? Berarti bug ada setelah titik itu — cari di setengah bagian itu. Apakah nilainya sudah terlihat salah? Berarti bug ada sebelum titik itu — cari di setengah bagian itu. Setiap langkah membelah dua ruang pencarian, jadi bahkan alur seribu baris pun bisa dipersempit dalam sekitar sepuluh pemeriksaan. Katakan pada AI secara eksplisit: "Bantu saya membisect ini — di mana titik tengah yang harus saya log?" Teknik yang sama juga berlaku pada riwayat, bukan hanya kode: jika sebuah fitur berfungsi minggu lalu tapi rusak hari ini, bisect commit-commitmu untuk menemukan perubahan persis yang menimbulkan bug tersebut.