Bir yorumlayıcı dilde program çalıştırmak, biraz güvenilmez ama parlak bir kahinle konuşmaya benzer. Kodunuzu baştan sona önceden mühürlemez; satır gelir, okunur, yorumlanır ve o anda hükmünü verir. İlk yüz satır kusursuz ilerleyebilir, yüz birinci satırda ise eksik bir değişken, yanlış türde bir veri ya da beklenmedik bir ağ yanıtı bütün evreni küçük bir hata mesajına indirger. Programın çalışıyor olması, onun bir sonraki anda da çalışacağına dair mantıksal bir garanti değildir.
Bu durum, felsefedeki radikal kuşkuculuğun teknoloji içindeki ilginç karşılığıdır. Radikal kuşkucu, duyularımızın, anılarımızın ve çıkarımlarımızın mutlak biçimde güvenilir olduğunu kanıtlayamayacağımızı söyler. Belki gördüğümüz dünya bir yanılsamadır; belki en sağlam sandığımız inanç, fark etmediğimiz bir varsayıma yaslanıyordur. Yorumlayıcı program da benzer biçimde yaşar: Elindeki satırın anlamını çözebilir, fakat henüz karşılaşmadığı satırların, verilerin ve koşulların güvenli olduğunu peşinen bilemez.
Çalışmak, Kanıtlanmak Değildir
Bir Python betiğinin terminalde başarıyla sonuçlanması çoğu zaman gereğinden fazla güven üretir. Geliştirici, ekran çıktısını görünce programın doğru olduğunu düşünmeye meyleder. Oysa bu yalnızca belirli girdiler, belirli ortam değişkenleri, belirli saat ve belirli bağımlılık sürümleri altında bir yürütmenin başarıyla tamamlandığını gösterir. Kodun doğruluğu ile kodun şu an hata vermemesi aynı önerme değildir. Tıpkı güneşin her gün doğmuş olmasının yarın da doğacağını biçimsel olarak ispatlamaması gibi, bin başarılı çalışma da milyon birinci çalışmanın güvence senedi değildir.
Burada David Hume’un alışkanlık üzerine düşüncesi devreye girer. Geçmişte sürekli birlikte gördüğümüz olaylardan, gelecekte de aynı düzenin süreceği sonucunu çıkarırız. Yazılımda buna daha teknik bir ad veririz: test kapsamı. Bir fonksiyon yüz testten geçince ona güveniriz; ama test edilmemiş sınırlar, boş değerler, eşzamanlılık sorunları ve kullanıcıların hayal gücü hâlâ kapıda bekler. Kullanıcı, yazılımcının asla düşünmediği bir kombinasyonu denemek konusunda neredeyse metafizik bir yeteneğe sahiptir.
Kuşku, Felç Değil Tasarım İlkesidir
Radikal kuşkuculuk yanlış yorumlandığında insanı eylemsizliğe sürükler: Hiçbir şey kesin değilse neden kod yazalım? Yazılım mühendisliğinin cevabı pratiktir: Kesinlik yoksa savunma katmanları kurarız. Tür denetimi, birim testleri, istisna yakalama, doğrulama kuralları, günlük kayıtları, geri alma mekanizmaları ve izleme araçları bu yüzden vardır. Bunlar mutlak doğruluk makineleri değildir; hata ihtimalini görünür, sınırlı ve onarılabilir kılan araçlardır.
Yorumlayıcı dillerin satır satır karakteri, bu yaklaşımı özellikle canlı tutar. Derleme aşamasında yakalanabilecek bazı sorunlar daha geç ortaya çıkabilir; çalışma zamanındaki dünya, kodun mantığına sürekli müdahale eder. Dosya bulunamaz, API cevap vermez, kullanıcı metin yerine sayı gönderir, sayı yerine boşluk gönderir. Bu kırılganlık bir kusur olmak zorunda değildir. Doğru kullanıldığında geliştiriciyi, sistemin soyut bir şemadan ibaret olmadığını; gerçek veri, gerçek zaman ve gerçek belirsizlik içinde yaşadığını kabul etmeye zorlar.
Sonuçta iyi programcı, koduna körü körüne inanan kişi değildir. Kodunun hangi varsayımlar üzerinde durduğunu soran, bu varsayımlar bozulduğunda ne olacağını tasarlayan kişidir. Kuşkuculuğun yazılımdaki değeri, her şeyi şüpheli ilan etmek değil; güvenin dereceli olduğunu kavramaktır. Program çalışır, ama koşullu olarak. Bilgi işe yarar, ama sınırları içinde. En olgun sistemler, hata vermeyeceklerini iddia edenler değil, hata verdiklerinde dünyayı yıkmadan konuşabilenlerdir.
