DX konuşmaları çoğu ekipte araç seviyesinde kalıyor: daha hızlı build, daha iyi IDE, yeni CI eklentisi. Bunlar faydalı ama kök problem çoğu zaman mimari. Kod sınırları belirsizse en iyi araç bile sürtünmeyi gizler, çözmez.
Biz DX'i teslimat sistemi olarak ele alıyoruz. İlk soru şu: küçük bir değişikliğin etki alanını öngörmek kolay mı? Değilse hız problemi insan değil sistem problemidir.
Repo topolojisini teknik moda göre değil iş kabiliyeti sınırına göre kuruyoruz. Ödeme, kimlik, içerik gibi alanlar net ayrıldığında ownership konuşmaları kısalıyor, bağımlılık haritası okunur hale geliyor.
Test stratejisinde de katman odaklı düşünmeyi tek başına yeterli bulmuyoruz. Koruyucu testler hızlı geri bildirim verirken, az sayıda fakat temsil gücü yüksek akış testleri ürün güvenini koruyor. Çok test değil, doğru yerde doğru test ilkesi daha verimli.
Ownership'in operasyonel tanımı olmazsa DX hızlanmıyor. Her modül için kim deploy eder, kim incident'ta karar alır, kim sözleşme değişikliğini onaylar, kim bakım borcunu roadmap'e taşır açıkça tanımlanmalı.
Araç yatırımı bu temel kurgu üzerine geldiğinde etkisi katlanıyor. Aksi halde her iyileştirme kısa süreli rahatlama üretip tekrar tıkanıyor.
DX, geliştirici konfor projesi değildir. Doğru tasarlandığında teslimat süresini kısaltır, hata maliyetini düşürür ve yeni ekip üyelerinin sistemi güvenle devralmasını sağlar. Bu yüzden DX kararı, doğrudan mimari karardır.
