Şehir merkezlerinde bazı binalar güzel ve temizken, bazıları da çürük enkazlara benzer. Neden? Suç ve kentsel yozlaşma alanlarında uzman bazı araştırmacılar büyüleyici bir tetik mekanizması keşfettiler. Öyle ki bu mekanizma temiz, zarar görmemiş ve dolu bir binayı çok kısa bir süre içerisinde sahipsiz bir harabeye çevirebiliyor.

Kırık bir pencere.

Azımsanmayacak bir süre içerisinde tamir edilmeyen kırık bir pencere, bina sakinlerinin içine terk edilmişlik hissiyatını işliyor. Bu hissiyat, kimsenin binayı umursamamasına sebep oluyor. Böylece başka bir pencere daha kırılıyor. İnsanlar etrafa çöp atmaya başlıyor. Grafitiler ortaya çıkıyor. Bina yapısına ciddi zararlar gelmeye başlıyor. Görece kısa bir süre içerisinde bina, sahibinin tamire yanaşma sınırının çok ötesinde zarar görüyor ve böylece yerleşmiş olan terk edilmişlik hissiyatı gerçeğe dönüşüyor.

The Pragmatic Programmer: From Journeyman to Master

Kırık Pencereler Teorisi, 1980’li yıllarda şehircilikle alakalı olarak ortaya atılmış ve çokça destek görmüş bir teori. Birkaç yıl önce bu teoriyi bir yazılım geliştirme kitabında gördüğümde önce şaşırdım. Fakat temiz ve sürdürülebilir kod yazmak benim için bir süper güç olduğunda bu teorinin yazılım alanında ne denli güçlü bir araç olabileceğini fark ettim.

Temiz Kod’a ulaşma yolunda attığımız her adım, aslında kırık bir pencereyi tamir etmeye benziyor. Fakat, eğer temiz olmayan bir koda sahipsek, Temiz Kod’a ulaşmak demek, aslında terk edilmiş bir şehri baştan aşağı yenilemek demek.

Bununla birlikte, eğer hâli hazırda çok da kirli olmayan bir koda sahipsek veya her geçen gün yazdığımız yeni kodun temiz olduğunu düşünüyorsak, Kırık Pencereler Teorisi’ni aklımızda tutmak bize kodumuzu kirletmemenin yolunu gösterebilir.

Çalışmayan bir fonksiyon mu gördük? Beklemeden düzelt!

Sınıflarımızdan (class) birinin içerisinde gereksiz yorumlar mı mevcut? Hemen sil gitsin!

Gözümüze ismi pek de iyi olmayan bir değişken mi çarptı? Dur ve değişkenin ismini iyileştir!

Tüm bunlar birer zaman kaybı gibi görünse de, aslında uzun vadede kodun daha fazla çalışmayan fonksiyonla, gereksiz yorumlarla ve kötü isimlendirilmiş değişkenlerle şişmesini engelleyecek ve sıkı durun: Bize aslında çok daha fazla zaman kazandıracak!

…Andy’nin korkunç derecede zengin olan arkadaşının hikayesine tanık olalım. Bu kişinin evi tertemiz ve çok güzeldi; içi paha biçilemez antikalarla ve sanat eserleriyle doluydu. Bir gün, salonundaki şömineye fazla yakın asılmış bir duvar halısı alev aldı. İtfaiye günü kurtarmak için alelacele eve vardı. Fakat itfaiyeciler büyük, kirli hortumlarını evin içine sürüklemeden önce — ki bu sırada alevler gitgide büyüyordu — giriş kapısıyla yangının çıkış noktasının arasına bir mat sermek için durdular.

İtfaiyeciler, halıyı kirletmek istememişlerdi.

Elbette bu oldukça ekstrem bir durum; fakat yazılımda olması gereken de bu. Kırık bir pencere — kötü tasarlanmış bir kod parçası, yazılımcıların proje boyunca beraber yaşamak zorunda olduğu yanlış bir yönetim kararı —, kodun bozulmaya başlaması için gerekli olan yegane şeydir. Eğer kendinizi birkaç kırık pencerenin bulunduğu bir projede çalışırken bulursanız, “kodun geri kalanı da zaten çöp gibi, ben de aynı şeyi yapacağım,” deme ihtimaliniz oldukça yüksek. Projenin o ana kadar kötüye gitmemesinin hiçbir önemi yok. “Kırık Pencereler Teorisi”nin ortaya çıkmasına sebep olan asıl deneyde, terk edilmiş bir arabaya bir hafta boyunca hiçbir şey olmadı. Ama tek bir camı kırıldıktan sonra, arabanın soyulması ve tepetaklak hâle gelmesi yalnızca birkaç saat aldı.

The Pragmatic Programmer: From Journeyman to Master

Benim bu teoriden çıkardığım ders şu: Kırık bir pencereyi gördüğüm an tamir etmezsem, asla Temiz Kod’a sahip olamam.

Dipnot: Yukarıdaki iki alıntıyı çok sevdiğim bir kitap olan The Pragmatic Programmer: From Journeyman to Master‘dan kendim çevirdim.

Sohbete katılın

1 yorum

Yorum Gönderin

Bir Cevap Yazın

%d blogcu bunu beğendi: