Birçok geliştirici yazılım geliştirmenin temel amacının çalışan kod üretmek olduğunu düşünür. Oysa gerçek ürünlerde asıl mücadele kodu ilk kez yazmak değil, onu defalarca değişen ihtiyaçlara rağmen sürdürülebilir tutabilmektir. Çünkü değişmeyen tek şey değişimin kendisidir. Requirement'lar değişir, ekipler değişir, teknolojiler değişir ve ürünler sürekli evrilir. Bu yazıda yazılım mimarisinin neden bugünü değil, yarını düşünerek tasarlanması gerektiğini ele alıyoruz.
Yazılım geliştirirken en sık duyduğumuz cümlelerden biri şudur:
"Şimdilik böyle yapalım."
Aslında bu cümlede yanlış olan hiçbir şey yoktur.
Çünkü gerçekten de hiçbir ekip ilk günden mükemmel sistemi kuramaz. Hiçbir Product Owner bütün ihtiyaçları baştan bilemez. Hiçbir müşteri de ürünün bir yıl sonra hangi noktaya geleceğini tahmin edemez.
Problem bu cümlede değil.
Problem, "şimdilik"in çoğu zaman kalıcı hale gelmesinde.
Gerçek ürünlerde öğrendiğim en önemli şeylerden biri şu oldu: Yazılımın en zor tarafı kodu ilk kez yazmak değil, aylar sonra aynı kodu güvenle değiştirebilmektir.
Çünkü kod hiçbir zaman sabit kalmıyor.
Bir fonksiyon yazıyorsunuz.
İlk gün gayet yeterli geliyor.
Sonra KDV geliyor.
İndirim geliyor.
Kampanya geliyor.
Bölgesel fiyatlandırma geliyor.
Kur dönüşümü geliyor.
Bir süre sonra aynı fonksiyon onlarca farklı senaryoyu yönetmeye çalışıyor.
Kod bozulduğu için değil.
İş değiştiği için.
Bence yazılım geliştirmedeki en büyük yanılgılardan biri requirement'ların sabit olduğu düşüncesi.
Hiçbir ürün ilk günkü requirement'larıyla yaşamıyor.
Bugün "sadece yöneticiler görebilsin" dediğiniz bir ekran, birkaç ay sonra şirket bazlı yetkilere ihtiyaç duyabiliyor.
Bugün tek abonelik planı yeterliyken, yarın üç farklı paket çıkıyor.
Bugün tek dil desteklenirken, birkaç ay sonra global pazara açılma kararı alınıyor.
Kod çoğu zaman yanlış yazıldığı için değil, dünya değiştiği için değişiyor.
Bir projeyi sadece kod değil, insanlar da şekillendiriyor.
Yazdığınız kodu altı ay sonra siz okumayabilirsiniz.
Belki başka biri devralacak.
Belki ekip büyüyecek.
Belki tamamen farklı bir ekip projeyi devam ettirecek.
Bu yüzden okunabilirlik yalnızca estetik bir tercih değildir.
Bir iletişim biçimidir.
İyi yazılmış kod sadece bilgisayara değil, gelecekte o kodu okuyacak geliştiriciye de hitap eder.
Bundan birkaç yıl önce popüler olan birçok teknoloji bugün yerini yenilerine bıraktı.
Yarın React'in, Next.js'in veya bugün kullandığımız herhangi bir aracın yerini başka teknolojiler alabilir.
Ama ürün yaşamaya devam edecek.
Müşteri aynı problemi çözmek isteyecek.
Business rule'lar aynı kalacak.
İşte bu yüzden mimariyi kullandığınız teknoloji üzerine değil, değişmeyecek kavramlar üzerine kurmak çok daha değerlidir.
Framework'ler araçtır.
Ürün ise amaçtır.
Mimari çoğu zaman gereksiz soyutlama yapmak olarak görülüyor.
Bence tam tersi.
İyi mimari geleceği tahmin etmeye çalışmaz.
Değişimi kolaylaştırmaya çalışır.
Çünkü hangi requirement'ın geleceğini bilemeyiz.
Ama yeni requirement'ların geleceğini kesin olarak biliriz.
Bu yüzden kendime yeni bir geliştirme yaparken şu soruyu sormayı seviyorum:
"Altı ay sonra bu kodu değiştirmek zorunda kalırsam bunu rahatça yapabilir miyim?"
Bu sorunun cevabı "hayır" ise, büyük ihtimalle problem requirement'da değil, tasarımdadır.
Yazılım geliştirmek çoğu zaman yeni kod yazmak gibi görünür.
Oysa gerçek ürünlerde zamanın büyük kısmı mevcut sistemi değiştirmekle geçer.
Yeni kurallar gelir.
Yeni müşteriler gelir.
Yeni ekip arkadaşları gelir.
Yeni teknolojiler gelir.
Ve bütün bunların ortak bir özelliği vardır.
Hepsi değişimdir.
Bence iyi mühendislik değişimi engellemek değildir.
Değişim geldiğinde sistemin ayakta kalmasını sağlamaktır.
Kod yazmak işin başlangıcıdır.
Asıl mühendislik, o kod yıllar boyunca değişirken düzenini koruyabilmektir.
Bugün geriye dönüp baktığımda en başarılı projelerin ortak bir özelliğini görüyorum.
En karmaşık mimariye sahip olmaları değil.
En kolay değiştirilebilen mimariye sahip olmaları.
Çünkü yazılımın en büyük maliyeti ilk geliştirme değildir.
Yıllar boyunca süren değişimdir.
Ve bence iyi mühendislik, değişimi tahmin etmek değil; değişim geldiğinde panik yapmayacak sistemler tasarlayabilmektir.
