Singleton Patron, Observer Komşu: Yazılım Desenleriyle Toplumun Gizli Tiyatrosu

Yazılım tasarım desenleri ilk bakışta soğuk bir mühendislik sözlüğü gibi görünür: Singleton, Observer, Factory, Adapter… Oysa biraz yaklaşınca bu desenlerin sadece kodu değil, toplumu da tarif ettiğini fark ederiz. Çünkü insan kalabalıkları da tıpkı büyük yazılım sistemleri gibi karmaşıktır; tekrar eden problemler üretir, bu problemlere pratik çözümler bulur ve sonra bu çözümleri gelenek, rol, unvan ya da karakter diye paketler. Mahalledeki her şeyi bilen teyze ile bir olay olduğunda anında haberdar olan Observer deseni arasında sandığımızdan az mesafe vardır.

Design pattern dediğimiz şey, aynı türden problemlere defalarca verilmiş sınanmış cevaptır. Kod dünyasında bu, geliştiricinin her seferinde sıfırdan kahramanlık yapmasını engeller. Toplumda da roller benzer bir iş görür. Öğretmen, arabulucu, asi genç, bilge ihtiyar, düzen koruyucu, girişimci, günah keçisi… Bunların her biri sosyal sistemin tekrar eden gerilimlerine verilmiş kalıplaşmış çözümlerdir. Klişe olmaları onları değersiz yapmaz; tam tersine, klişe dediğimiz şey çoğu zaman kültürel hafızanın önbelleğidir.

Mikroservis Cumhuriyeti: Her Servis Kendi Tahtında, Sistem Kimin Umurunda?

Mikroservis mimarisi, yazılım dünyasının özgürlük vaadi gibidir: Her parça bağımsız geliştirilsin, ayrı deploy edilsin, kendi verisine sahip olsun, ekipler hızlansın, kimse kimsenin ayağına basmasın. Kâğıt üzerinde şahane. Fakat her özgürlük projesi gibi burada da küçük bir dipnot vardır: Bağımsızlık, sorumluluğun buharlaşması için icat edilmiş lüks bir perdeye dönüşebilir. Bir sabah sistem çöker, kullanıcı ödeme yapamaz, loglar sisli bir ormana benzer ve herkes aynı kutsal cümleyi söyler: Bizim servis ayakta.

İşte mikroservis mimarisinin bireycilikle akrabalığı burada başlar. Modern birey de kendi servisini ayakta tutmaya çalışır: Kariyerim çalışıyor, hesabım dönüyor, takvimim dolu, profilim güncel. Ama mahalle yanıyorsa, kurum çürüyorsa, ürün kullanıcıyı perişan ediyorsa, sadece kendi endpointinin 200 dönmesi pek de kahramanca değildir. Mikroservisler teknik bir desen olmaktan çıkıp örgütsel bir psikoloji aynasına dönüşür: Herkes kendi sınırlarını korur, kendi SLA belgesini parlatır, fakat sistemin ruhu ortada kalır.

Bir Değişkene İsim Verdiğinde Evreni Derliyorsun

Kodlamada isimlendirme çoğu zaman küçük bir nezaket kuralı gibi anlatılır: Okunabilir olsun, ekip arkadaşın anlasın, altı ay sonra kendine küfretme. Bunlar doğru, fakat yüzeyde kalır. Bir değişkene isim vermek yalnızca etiketi kavanoza yapıştırmak değildir; kavanozu, içindekini ve onu hangi rafta arayacağımızı aynı anda icat etmektir. Programcı, count yazdığında sayılabilir bir şeyler evreni kurar. activeUsers dediğinde kullanıcıları varlık, etkinliği durum, çoğulluğu da yönetilecek bir alan olarak ilan eder. Bu küçük satırda sessiz bir metafizik çalışır.

Ontoloji, en basit haliyle neyin var olduğunu ve nasıl var olduğunu sorgular. Yazılımda bu soru daha acımasızdır, çünkü cevap derlenir. Bir veriye temp adını verdiğinizde onu geçici, değersiz, birazdan atılacak bir nesne haline getirirsiniz. Sonra o temp, sistemin kalbine yerleşir; kimse dokunamaz, çünkü kimse onun gerçekte ne olduğunu bilmez. Böylece kötü isim, teknik borçtan önce varoluşsal borç üretir. Kod tabanında dolaşan hayaletlerin çoğu, yanlış adlandırılmış varlıklardır.

İlk Satırın Gölgesi: Mimari Kararlar Neden Yıllarca Peşimizi Bırakmaz?

Bir yazılım projesinin ilk günlerinde alınan kararlar çoğu zaman masum görünür: Veritabanını şimdilik tek sunucuda tutalım, kullanıcı kimliğini e-posta adresiyle eşleştirelim, modülleri hızlı ilerlemek için aynı kod tabanında toplayalım. Ekip küçüktür, müşteri acele eder, bütçe dardır. Herkes “sonra düzeltiriz” der. Fakat bilişim dünyasında bazı “sonralar”, yıllar sonra milyonlarca kullanıcının, yüzlerce geliştiricinin ve kritik iş süreçlerinin omzuna çöken birer mimari gölgeye dönüşür.

Geri dönüşsüz karar, teknik olarak asla değiştirilemeyecek karar demek değildir. Çoğu sistem yeniden yazılabilir, veri taşınabilir, servisler ayrıştırılabilir. Ancak değişimin maliyeti zamanla öyle büyür ki karar pratikte geri dönüşsüz hale gelir. Bir apartmanın temelini değiştirmek mümkündür; fakat apartman doluyken, çevresinde trafik akarken ve kiracılar her gün yaşamaya devam etmek zorundayken bu iş yalnızca mühendislik problemi olmaktan çıkar. Yazılım mimarisi de böyledir: Kodun altında çalışan iş kuralları, kullanıcı alışkanlıkları, entegrasyonlar ve kurum hafızası vardır.

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.