Yazılım projelerinde en tehlikeli an çoğu zaman büyük toplantı odalarında, dramatik sunumların ortasında ya da milyon dolarlık bütçe görüşmelerinde yaşanmaz. Tehlike, projenin ilk haftasında bir geliştiricinin kahvesinden bir yudum alıp ‘Şimdilik böyle yapalım’ dediği o küçük anda başlar. Bir klasör yapısı, bir veritabanı tercihi, bir API sözleşmesi, bir kimlik doğrulama yöntemi… Başta masum görünen bu kararlar, yıllar sonra şirketin çevikliğini, ürünün performansını, ekibin ruh sağlığını ve hatta iş modelinin sınırlarını belirleyen görünmez anayasalara dönüşür.
Yazılımda tasarım kararı, yalnızca teknik bir seçim değildir; geleceğe yazılmış bir taahhüttür. Bir monolit mi kuruyorsunuz, mikroservis mi? SQL mi NoSQL mi? Domain modeli gerçekten iş alanını mı temsil ediyor, yoksa ekran formlarının aceleyle sınıflara dökülmüş hali mi? Bu soruların cevapları ilk günlerde kolay sanılır, çünkü sistem küçüktür, kullanıcı azdır, beklentiler belirsizdir. Fakat yazılım canlı bir organizma gibi büyür. Her yeni özellik, ilk mimari kararların etrafında şekillenir. Bir süre sonra sistem sizin yazdığınız bir şey olmaktan çıkar; sizinle pazarlık eden, direnç gösteren, hatta emir veren bir şeye dönüşür.
Küçük kararların büyük gölgesi
Bir örnek düşünelim: Projenin başında tüm iş kuralları controller katmanına yazıldı. Çünkü hızlıydı. Çünkü demo yetişecekti. Çünkü ‘sonra düzeltiriz’ cümlesi yazılım tarihinin en pahalı ninnisidir. İlk ay sorun yoktur. Üçüncü ay bazı controller dosyaları biraz şişer. Birinci yıl sonunda test yazmak acı verici hale gelir. İkinci yıl mobil uygulama isterler, aynı iş kurallarını tekrar yazarsınız. Üçüncü yıl regülasyon gelir, her değişiklik mayın tarlasına dönüşür. Beşinci yıl ekipte kimse hangi koşulun nerede çalıştığını tam bilmez. Artık mesele kod kalitesi değil, kurumsal hafızanın çöküşüdür.
İşte burada geri dönülemezlik başlar. Elbette teknik olarak her şey değiştirilebilir. Veritabanı taşınabilir, mimari bölünebilir, modüller yeniden yazılabilir. Ama yazılımda geri dönüşün maliyeti yalnızca kod satırıyla ölçülmez. Müşteri beklentileri, entegrasyonlar, ekip alışkanlıkları, operasyon süreçleri, dokümantasyon boşlukları ve üretimdeki binlerce küçük istisna birlikte bir ağırlık oluşturur. Bu ağırlık arttıkça ‘refaktör edelim’ cümlesi teknik bir öneri olmaktan çıkar, stratejik bir savaş ilanına dönüşür.
Mimari karar, seçenekleri azaltma sanatıdır
İyi mimari her şeyi önceden bilmek değildir. Bu zaten mümkün değildir. İyi mimari, henüz bilinmeyen gelecek karşısında seçenekleri açık tutabilmektir. Bir tasarım kararının kalitesi, bugünkü ihtiyacı ne kadar hızlı çözdüğüyle değil, yarınki değişikliği ne kadar az kan dökerek kabul ettiğiyle anlaşılır. Bu yüzden yazılım mimarisi biraz satranca benzer: En iyi hamle, yalnızca şu an taş kazanmak değil, beş hamle sonra tahtada nefes alacak alan bırakmaktır.
Geri dönülemezliği azaltmanın ilk yolu, kararları bilinçli sınıflandırmaktır. Bazı kararlar kapı gibidir: Açarsınız, geçersiniz, gerekirse geri dönersiniz. Örneğin bir kütüphaneyi değiştirmek nispeten yönetilebilir olabilir. Bazı kararlar ise tünel gibidir: İçine girdikçe geri dönüş zorlaşır. Veri modeli, servis sınırları, kimlik yönetimi, olay akışı, dağıtım stratejisi ve hata toleransı gibi alanlar bu türdendir. Bu konularda ‘şimdilik’ kelimesi kırmızı alarmdır.
İkinci yol, soyutlama ile gerçeklik arasındaki dengeyi korumaktır. Fazla soyutlama sistemi buharlaştırır; hiçbir şey somut değildir, herkes ‘framework içinde framework’ yazar. Yetersiz soyutlama ise sistemi betona gömer; her değişiklik kırıcı delici gerektirir. Usta geliştirici, soyutlamayı süs olsun diye değil, değişim yönünü sezdiği yerde kullanır. Yani tasarımın amacı güzel diyagramlar çizmek değil, değişimin sürtünmesini azaltmaktır.
Üçüncü yol, karar kayıtları tutmaktır. Neden bu veritabanı seçildi? Neden servisler böyle bölündü? Neden senkron iletişim tercih edildi? Altı ay sonra kimse hatırlamaz. İki yıl sonra herkes mevcut yapının ezelden beri böyle olduğunu sanır. Mimari karar kayıtları, ekibin kolektif hafızasıdır. Kod ne yapıldığını söyler; karar kaydı neden yapıldığını anlatır. Nedenini bilmeden yapılan değişiklik, karanlık odada kılıç sallamaktır.
Sonuç: Kod kader değildir, ama karakter ister
Yazılımda geri dönülemezlik mutlak değildir; fakat umursamazlığın faizi bileşik çalışır. Başta küçük görünen borçlar, zamanla teknik enflasyona dönüşür. Bu yüzden projenin ilk günlerinde atılan her mimari adım, yalnızca bugünün hızını değil, yarının özgürlüğünü de belirler. En iyi ekipler hata yapmayanlar değildir; kararlarının sonuçlarını izleyen, gerektiğinde erken dönebilen ve ‘sonra bakarız’ büyüsüne kapılmayan ekiplerdir.
Belki de yazılımın en temel dersi şudur: Gelecek, büyük kararlarla değil, küçük ihmallerle kilitlenir. Bir satırlık kolaylık, yıllar sonra şirketin boynuna takılmış görünmez bir zincir olabilir. Bu yüzden mimari düşünmek, kod yazmayı yavaşlatan bir lüks değil; gelecekte hareket edebilme hakkını koruyan disiplinli bir özgürlük biçimidir.