Laravel’de Localhost Dışında Hata Ayıklama – DEV Community

Gerçek Ortamlardan Öğrenilen Dersler

Uzun yıllar boyunca hata ayıklama iş akışım aynı şekilde ilerledi.

Bir şey bozuldu.

Bu durumu yerel ortamda yeniden oluşturmaya çalıştım.

Log ekledim.

Tahmin ettim.

Bazen işe yaradı. Çoğu zaman işe yaramadı.

Laraavel projelerim Docker, WSL, staging sunucuları ve uzaktan ortamlara geçiş yaptıkça, tek bir şey daha belirgin hale geldi:

Çoğu hata localhost’ta meydana gelmiyor.

Bu makale, yerel hata ayıklamaya fazla güvendiğimizde nelerin bozulduğuna ve gerçek çalışma sırasında hata ayıkladığımızda nelerin değiştiğine odaklanmaktadır.

Hata Ayıklama İllüzyonu

Yerel hata ayıklama, bize bir kontrol hissi verir.

Aynı makine.

Aynı IDE.

Aynı veritabanı anlık görüntüsü.

Ama üretim ve QA böyle görünmüyor.

Farklı çevre değişkenleri.

Farklı veriler.

Farklı zamanlamalar.

Farklı altyapılar.

Pek çok durumda peşinden koştuğunuz hata “yanlış sözdizimi” nedeniyle oluşmaz.

Bu hata, durum nedeniyle oluşur.

Ve durum neredeyse her zaman çevresel koşullara bağlıdır.

Neden Yerel Hata Ayıklama Bozulur?

Yerel hata ayıklama araçları harikadır. Ta ki olmadıklarında.

Karşılaştığım en yaygın sorun noktaları şunlardı:

• Docker veya WSL ile iyi çalışmayan PHP uzantıları
• Ağ portlarının engellenmesi veya yapılandırılmaması
• IDE’lere sıkı sıkıya bağlı hata ayıklayıcılar
• Bir seferde yalnızca bir geliştiricinin hata ayıklayabilmesi
• Hata ayıklamanın yalnızca HTTP istekleri ile sınırlı olması

Bunların hiçbiri “araç hatası” değil.

Bunlar, iş akışına yerleşmiş varsayımlardır.

Varsayım basit:

Eğer bunu yerelde yeniden oluşturabiliyorsam, hata ayıklayabilirim.

Ama gerçek dünyadaki hatalar bu varsayıma saygı göstermez.

Gerçek Çalışmayı Hata Ayıklama

Bir noktada, “Bunu yerelde nasıl yeniden oluşturabilirim?” sormayı bıraktım.

“Gerçekten neyin çalıştığını nasıl inceleyebilirim?”

Bu değişim her şeyi değiştirir.

Gerçek çalışma:

• Gerçek çevre değişkenleri
• Gerçek veriler
• Gerçek dosya sistemi
• Gerçek yapılandırma
• Gerçek yan etkiler

Tahmin etmek yerine, gözlemlersiniz.

Yeniden üretmek yerine, incelersiniz.

Hata ayıklama, satırlar arasında adım atmakla ilgili değil, durumu anlamakla ilgilidir.

İstekleri Yeniden Üretmek Yerine Yöntemleri Çalıştırmak

Bir başka realizasyon ise kısa süre sonra geldi.

Çoğu hata kontrollerde yaşamaz.

Onlar:

• servislerde
• alan mantığında
• işlerde
• dinleyicilerde
• yardımcı fonksiyonlarda
• kenar durumu koşullarında

Ancak hala bunları HTTP istekleri üzerinden hata ayıklamaya çalışıyoruz.

Neden?

HTTP sık sık hata ayıklamak için en kötü giriş noktasıdır:

• kimlik doğrulama
• middleware
• CSRF
• çerezler
• başlıklar
• harici bağımlılıklar

Bu yüzden isteği yeniden üretmek yerine, yöntemleri doğrudan çalıştırmaya başladım.

Servisi çalıştırın.

Girişi verin.

Durumu inceleyin.

Çalıştırmayı durdurun.

Tarayıcı yok.

Sahte istek yok.

Altyapı jimnastikleri yok.

Önemli olan sadece kod, gerçekten önemli olan yerde çalışıyor.

Farklı Bir Hata Ayıklama Yaklaşımı

Bu deneyimler, bana farklı bir zihinsel model kazandırdı:

• VM düzeyinde değil, çalışma zamanında hata ayıklayın
• Simüle etmek yerine, yürütmeyi gözlemleyin
• Geliştirici başına oturumları izole edin
• Mümkün olduğunda ağ bağımlılıklarından kaçının
• HTTP’yi zorunlu değil, isteğe bağlı olarak değerlendirin

Amaç mevcut araçları değiştirmek değil, asla tasarlaınmamış boşlukları kapatmaktır.

Uzaktan ortamlar.

QA sunucuları.

Üretim için güvenli inceleme.

Çoklu geliştirici iş akışları.

Bunun Açtığı Olanaklar

Artık localhost’u gerçeğin kaynağı olarak kullanmayı bıraktığınızda, yeni olasılıklar açılır:

• Altyapıyı değiştirmeden QA’yı hata ayıklamak
• Üretimi güvenli bir şekilde incelemek, izolasyon ve zaman aşımına sahip olmak
• İşleri ve servisleri trafik olmadan hata ayıklamak
• Aynı sunucuda çoklu geliştiricilerin bağımsız olarak hata ayıklamasına izin vermek
• Yeniden üretmekten daha fazla anlamaya zaman harcamak

Hata ayıklama, çevreyle mücadele etmek olmaktan çıkar.

Onunla bir diyalog haline gelir.

Son Düşünceler

Hata ayıklama, araçlarla ilgili değildir.

Bu, doğruluk ile ilgilidir.

Gerçek çalışmaya ne kadar yakın olursanız, o kadar az varsayımda bulunmanız gerekir.

Bu anlayış, sonunda DDLess adlı bir çalışma zamanı hata ayıklayıcı geliştirmeme yol açtı; gerçek Laravel ortamları için tasarlanmıştır.

Yerel araçların bir yerine geçmek olarak değil, yerel hata ayıklamanın yeterli olmadığı durumlarda tamamlayıcı olarak.

“Bu hata yalnızca makinemin dışında oluyor” diye düşündüyseniz, problemi zaten anlıyorsunuz demektir.

Gerisi sadece ona yaklaşımınızı değiştirmekle ilgilidir.

https://ddless.com