Hızlı Yazılan Kod Neden Geleceğin En Pahalı Hatasına Dönüşür?

Hızlı Yazılan Kod Neden Geleceğin En Pahalı Hatasına Dönüşür?

Bir yazılım ekibinin takviminde bazen şu cümle belirir: “Şimdilik böyle çıkaralım, sonra düzeltiriz.” Bu cümle masum görünür; hatta çoğu zaman doğrudur. Pazar fırsatı beklemez, müşteri demo ister, kritik bir hata gece yarısı çözülmelidir. Sorun hızlı davranmak değildir. Sorun, hız uğruna alınan kararın gelecekte bir maliyet yaratacağını unutmak ya da bu maliyeti kayda geçirmemektir. İşte bu görünmez yükün adı kalıtsal borçtur: Bugünün kod kolaylığı karşılığında yarının geliştirme kapasitesinden alınan kredi.

Finansal borçla benzetme güçlüdür çünkü teknik borç da faiz işler. Bir fonksiyonun içine sıkıştırılmış iş kuralları, kopyalanmış kod blokları, anlamsız değişken adları, test edilmeyen kritik akışlar veya “geçici” diye eklenmiş ama iki yıldır yaşayan bir yapı… Bunların her biri ilk gün küçük bir tasarruf sağlar. Ancak sistem büyüdükçe yeni özellik eklemek zorlaşır, hata ayıklama uzar ve ekip üyeleri kod tabanına dokunmaktan çekinir. Faiz, sadece işlemci zamanı ya da sunucu faturası değildir; geliştiricinin dikkati, motivasyonu ve güveni de bu faizle aşınır.

Ekranda Aynı, İçeride Devrim: Kod Refaktörünün Gizli Estetiği

Kod refaktörü, yazılım dünyasının en tuhaf sanatlarından biridir: Seyirci salona girer, perde açılır, sahne aynı görünür. Düğmeler aynı yerde, ekran aynı renkte, kullanıcı yine aynı işlemi yapar. Fakat kulisin arkasında dekor sökülmüş, kablolar etiketlenmiş, oyuncuların giriş çıkışları yeniden düzenlenmiş, yangın çıkışları açılmıştır. Dışarıdan hiçbir şey değişmemiştir; içeride ise küçük bir uygarlık kurulmuştur.

Bu yüzden refaktör, sadece teknik bir işlem değil, bir ahlak biçimidir. Çünkü hızlıca çalışan ama içten içe çürüyen kod ile karşılaşan geliştirici, iki yoldan birini seçer: Ya halının altına bir hata daha süpürür ya da diz çöküp zemindeki çatlağı onarır. Refaktör yapan kişi, gelecekteki bilinmeyen bir meslektaşına, hatta çoğu zaman kendisinin üç ay sonraki hâline not bırakır: Burada seni bekleyen bir mayın yok, rahat yürü.

Ölü Kod Mezarlığı: Sistemi Yavaşlatan Hayalet İnançlar

Her yazılım sisteminin bodrum katında bir mezarlık vardır. Orada artık çalışmayan fonksiyonlar, yıllar önce terk edilmiş koşullar, kimsenin çağırmadığı sınıflar ve üstüne not düşülmüş kadim büyüler uyur: sakın silme, bir gün lazım olabilir. Ölü kod tam olarak budur; programın yaşayan akışına katkısı olmayan ama depoda yer kaplayan, zihni meşgul eden, bakım maliyetini artıran eski parçalar. İlginç olan şu: Ölü kod teknik bir mesele gibi görünür, ama çoğu zaman psikolojik bir arızanın izidir. Kod çalışmaz; korku çalışır.

Bir ekip düşünün. Beş yıl önce yazılmış bir ödeme modülünün içinde devasa bir if bloğu duruyor. Artık hiçbir müşteri o yolu kullanmıyor, dokümantasyon onu anmıyor, testler ona uğramıyor. Ama biri silmeyi önerdiğinde odada sessizlik oluşuyor. Çünkü kodun kendisinden çok, onun etrafındaki efsane yaşıyor: Eski CTO bunu yazmıştı. Büyük bir müşteride sorun çıkarmıştı. Bir ara kampanya döneminde hayat kurtarmıştı. İşte yazılımda ölü kod, çoğu zaman eski bir savaşın madalyasıdır; paslanmıştır ama kimse duvardan indirmeye cesaret edemez.

Az Kod, Çok Ustalık: Neden Kısa Çözümler Daha Zordur?

Programlamada uzun kod bazen çok çalışıldığının kanıtı gibi görünür. Ekranı satır satır dolduran koşullar, döngüler ve yardımcı fonksiyonlar insana üretkenlik hissi verir. Oysa deneyimli geliştiriciler çoğu zaman tersine bir hedefe yönelir: Aynı işi daha az kodla, daha açık biçimde ve daha az hata olasılığıyla yapmak. Bu, tembellik değil; problemin özünü ayıklama sanatıdır. Kısa kod yazmak, tuşlara daha az basmak değil, düşünceye daha fazla emek vermektir.

Satır sayısı değil, zihinsel yük

Bir programın gerçek maliyeti onu ilk yazarken değil, ikinci kez anlamaya çalışırken ortaya çıkar. Kodun bakımını yapan kişi çoğu zaman onu yazan kişi değildir; hatta çoğu projede bu kişi, birkaç ay sonraki sizsiniz. Her gereksiz değişken, tekrar eden kontrol ve özel durum, okuyucunun zihninde taşınması gereken ek bir yük yaratır. Dil ekonomisi tam burada devreye girer: Kod, makinenin çalıştıracağı talimatların yanında insanların okuyacağı bir metindir. İyi kod, yalnızca doğru sonucu üretmez; niçin doğru olduğunu da görünür kılar.

Kodun Gösterişi Değil, Zarafeti Kazanır: Neden Daha Az Çoğu Zaman Daha İyidir?

Bir yazılım projesinde karmaşıklık çoğu zaman zekânın kostümü gibi görünür. On iki katmanlı soyutlamalar, her sınıf için ayrı bir arayüz, küçük bir işlem için devasa bir tasarım deseni koleksiyonu… Bunlar ilk bakışta etkileyicidir. Fakat bilişimde etkileyici olmak ile iyi olmak aynı şey değildir. Zarafet ilkesi, çözümün gösterdiği kas gücünden çok, problemi ne kadar doğrudan, anlaşılır ve güvenilir biçimde çözdüğüne bakar. İyi kod, geliştiricinin ne kadar çok şey bildiğini değil; neyi gereksiz yere kullanmadığını da gösterir.

Zarafet: Az Kod Değil, Az Gereksiz Karar

Zarif bir çözüm mutlaka en kısa çözüm değildir. Tek satıra sıkıştırılmış, yalnızca yazarı tarafından çözülebilen bir ifade zarif sayılmaz; o, çoğu zaman şifrelenmiş bir egodur. Zarafet; okunabilirlik, doğru soyutlama, öngörülebilir davranış ve düşük bilişsel yükün birleşimidir. Bir fonksiyonun ne yaptığını anlamak için zihinde beş farklı dosya, üç tasarım deseni ve geçmişte alınmış iki mimari karar taşımak gerekiyorsa, orada bir sorun vardır. Kod bilgisayara değil, gelecekte onu değiştirecek insana da hizmet eder.