# Production'da Trade-off'lar: Best Practice Gerçekten En İyi Seçim mi?

Bir sistem tasarlarken en çok duyduğumuz kavramlardan biri **best practice**’tir.

İ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.