İlk bakışta isim hissiyat olarak bunu size verir ve tabiri caizse her şeyi kitaba uygun yöntem olarak öne çıkar.

Evet, best practice gerçekten kitaba en uygun olanıdır. Ancak çoğu zaman en doğrusu değil.

Özellikle production’a giden yolda alınan her karar bir trade-off içerir, yani bazı kazanımlar için ödünler vermeniz gerekir. Bu yazıda en doğrusunu değil, en uygununu nasıl buluruz sorusunu inceleyeceğiz.

Örnek Trade-Off’lar Nelerdir?

Mimari, kararların sadece başlangıcı değil, sistemin uzun vadeli maliyetini belirlediği alandır. Bir mimari karar:

• Geri dönmesi en zor karardır.

• Yanlış alındığında teknik borç (technical debt) üretir.

• Doğru alındığında hareket alanı kazandırır.

Ancak "best practice" yaklaşımı bazen bu hareket alanını daraltan bir prangaya dönüşebilir.

1. Over-Layered Mimariler;

   Bağımlılığı azaltmak için Clean Architecture veya DDD gibi yaklaşımlarla sistemi onlarca katmana bölmek harika görünür. Use-case bazlı yapılar, application katmanının ayrıştırılması kağıt üzerinde kusursuzdur.

   Peki ya maliyeti?

   • Boilerplate Cehennemi: Basit bir kayıt ekleme işlemi için 5-6 farklı dosyada değişiklik yapmak.

   • Okunabilirlik Kaybı: Kodun akışını takip ederken kaybolmak.

   • Hız Kaybı: Geliştirme süresinin mimariyi beslemek için harcanması.

Sorun mimarinin kendisi değil, projenin ölçeğiyle mimarinin karmaşıklığının uyuşmamasıdır. Esneklik kazanmak için bilinçsizce karmaşıklığı satın alıyoruz.

2. DevEx’in Göz Ardı Edilmesi;

   Bir mikro-SaaS projesinde; CQRS, DDD, Event Sourcing ve karmaşık pipeline'lar kullanmak teknik olarak "doğru" olabilir. Ancak 2 kişilik bir ekipte bu durum motivasyonu yerle bir eder.

   Bir projede "bad pattern"lerin artması ne kadar tehlikeliyse, bağlamdan kopuk "best practice"lerin artması da DevEx'i (Geliştirici Deneyimi) o kadar düşürür. Runtime performansından önce, geliştirici performansını düşünmek zorundayız.

3. YAGNI Nedir?

   YAGNI (You Ain’t Gonna Need It), modern yazılımın en çok ihlal edilen kuralıdır. "Best practice" takıntısı genellikle bizi ihtiyacımız olmayan soyutlamalar inşa etmeye iter.

   Benim yaklaşımım basit:

   • Soyutlamayı ihtiyaçtan yapın: Bir yapı gerçekten 2 veya 3 farklı noktada kullanılıyorsa soyutlayın. "Kitap öyle diyor" diye değil.

   • AOP ve Middleware: Loglama veya yetkilendirme gibi merkezi işleri kodun kalbine gömmek yerine, mimarinin sunduğu araya girme (interceptor/middleware) mekanizmalarını kullanın.

   • Önce Yalınlık: Kodun en iyi hali, çıkarılacak hiçbir şeyin kalmadığı haldir.

Genel hatları ile özetlemem gerekirse kararlarınızı bugün için değil, yarınlar için verin.