Bir üretim ERP’sinde, altı ay süren bir geliştirme projesinin sonunda, “mükemmel” olduğuna inandığım mimarinin aslında sadece bir hayalden ibaret olduğunu acı bir şekilde fark ettim. Kağıt üzerinde her şey kusursuzdu; microservice’ler özenle ayrılmış, veritabanı şemaları normalized, her senaryo düşünülmüştü. Ancak gerçek dünya, planladığım bu pürüzsüz tabloya sürekli çomak soktu.
Bu deneyim ve 20 yıla yaklaşan saha tecrübem bana gösterdi ki, yazılım mimarisinde “mükemmel” diye bir kavram yoktur; sadece uygun ve işlevsel olan vardır. Her projenin kendi kısıtlamaları, öncelikleri ve trade-off’ları vardır ve bu, bizi ideal senaryolardan uzaklaştırıp pragmatik çözümlere yönlendirir.
Mükemmel Mimari Neden Sadece Bir İllüzyon?
Yazılım mimarisi, mühendislik disiplinlerinin aksine, her zaman değişen ve insan faktörünün yoğun olduğu bir alandır. Bir köprü inşa ederken fizik kuralları sabittir, ancak bir yazılım sistemi inşa ederken iş gereksinimleri, teknolojiler ve ekip yetkinlikleri sürekli evrilir. Bu dinamik ortamda, statik bir mükemmellik arayışı baştan kaybetmeye mahkumdur.
Benim gördüğüm en büyük yanılgı, yazılım mimarisini bir kere yapıp biten bir iş olarak görmek. Oysa mimari, projenin ömrü boyunca yaşayan, nefes alan ve sürekli evrilen bir yapı olmalı. İlk başlarda harika görünen bir çözüm, altı ay sonra iş gereksinimleri değiştiğinde veya yeni bir teknoloji ortaya çıktığında yetersiz kalabilir.
Kararların Bedeli: Her Mimari Seçim Bir Trade-off mudur?
Kesinlikle evet. Yaptığımız her mimari seçim, bir şeyden ödün vermek anlamına gelir ve bu kararların bir bedeli vardır. Bir müşteri projesinde, hızlı bir MVP çıkarmak için monolith bir yapıya yöneldiğimizde, altı ay sonra karşılaştığımız bakım zorlukları bu kararın bedeliydi. O anki acil ihtiyaca cevap verirken, gelecekteki ölçeklenebilirlik veya geliştirme hızından feragat etmiştik.
Her “best practice” diye adlandırılan yaklaşımın bile kendi dezavantajları vardır. Microservice’ler ölçeklenebilirlik ve bağımsız geliştirme avantajı sunarken, operasyonel karmaşıklığı, distributed transaction yönetimi ve debug zorluklarını beraberinde getirir. Monolith’ler ise geliştirme kolaylığı sağlarken, büyük ekiplerde darboğazlara ve teknoloji bağımlılığına yol açabilir. Benim yaklaşımım, her zaman projenin mevcut durumuna ve ekibin yetkinliklerine uygun olan “good enough” çözümü bulmak olmuştur.
Evrilen İhtiyaçlar ve Gelişen Teknoloji: Statik Mimarinin Sonu
Yazılım dünyası yerinde durmuyor. Yeni diller, framework’ler, veritabanı teknolojileri ve dağıtım modelleri sürekli ortaya çıkıyor. Bir yandan da iş dünyasının ihtiyaçları, pazar dinamikleri ve kullanıcı beklentileri değişiyor. Bu kadar dinamik bir ortamda, “mükemmel” ve değişmez bir mimari tasarlamak, denize kumdan kale yapmaya benzer.
Kendi yan ürünlerimden birinde, Android spam blocker uygulamamın ilk versiyonunu tasarlarken, o anki veritabanı seçimim ve API yapım gayet yeterliydi. Ancak zamanla spam algılama algoritmaları gelişti, veri hacmi arttı ve daha hızlı sorgulama ihtiyacı doğdu. Bu durum, ilk mimari kararlarımı sorgulamamı ve sistemi büyük ölçüde evriltmemi gerektirdi. Mimariyi bir “bitiş çizgisi” değil, sürekli bir “yolculuk” olarak görmek bu yüzden çok önemli.
Pragmatizm Mi, Prensipler Mi? Benim Yaklaşımım
Benim için mimari, katı prensiplerin körü körüne uygulandığı bir dogma değil, pragmatik bir sanat. Elbette SOLID prensipleri, DRY ilkesi gibi temel mühendislik ilkelerine bağlı kalmaya çalışırım. Ancak bu prensipleri, projenin somut gerçekleriyle harmanlayarak, “olur o kadar” diyebileceğim esneklikte uygulamayı tercih ederim. Bazen hızlıca bir POC (Proof of Concept) çıkarmak için teknik borçlanmaya bile göz yumduğum oldu, yeter ki iş değeri en kısa sürede ortaya çıksın.
Önemli olan, bu borcun farkında olmak ve uygun zamanda ödemek için bir plan yapmak. Bir keresinde bir projede testlerin yazılmadığı bir legacy koda entegrasyon yapmak zorunda kaldık. Normalde test yazmadan bir satır kod bile eklemezdim, ama o anki acil durum, beni pragmatik bir istisna yapmaya zorladı. Sonraki sprint’lerde bu teknik borcu kapatmak için efor ayırdık.
Sonuç: Sürekli Öğrenen ve Gelişen Bir Yolculuk
Mükemmel mimari diye bir şey yok; sadece o anki en iyi kararlar ve sürekli adaptasyon var. Bir sistem mimarı olarak benim görevim, ideal bir tablo çizmek değil, mevcut kısıtlamalar altında en uygun, esnek ve sürdürülebilir çözümü bulmaktır. Bu yolculukta hatalar yaparız, yanlış kararlar alırız, ama önemli olan bunlardan ders çıkarıp sistemi ve kendimizi sürekli geliştirmektir.