Mimari Değerlendirme ve Refactor: Kanıttan Aşamalı Dönüşüme

Mimari değerlendirme neyi sorgular, kod incelemesinden farkı nedir?

Kod incelemesi tek bir değişikliğin doğruluğuna bakar. Mimari değerlendirme ise sistemin bütününün, ona yüklenen taleplere yapısal olarak uygun olup olmadığını sorar: Yeni özellikler makul sürede eklenebiliyor mu? Bir modüldeki değişiklik başka modülleri bozuyor mu? Yük arttığında sistem nerede çatlıyor? Ekip büyüdüğünde kod tabanı birlikte çalışmaya izin veriyor mu?

Kod kokularını temizlemek (uzun fonksiyon, yinelenen kod) sınıf ve fonksiyon düzeyinde bir iştir. Mimari düzeyde sorunlar ise modüller arası bağımlılıkta, sorumluluk dağılımında, veri sahipliğinde ve dağıtım yapısında ortaya çıkar. Aynı sistemde iyi yazılmış fonksiyonlar bulunup mimari bozuk olabilir; tersi de mümkündür.

Değerlendirmenin çıktısı "iyi" ya da "kötü" hükmü değildir. Çıktı, bağlama göre sıralanmış bir sorun ve risk listesi ile bunlara karşılık gelen aşamalı bir dönüşüm planıdır.

Önce hedef: hangi kalite nitelikleri için değerlendiriyorsunuz?

Mimari tek başına iyi ya da kötü olmaz; belirli niteliklere karşı iyi ya da kötüdür. Değerlendirmeye başlamadan önce iş hedeflerinden çıkan kalite niteliklerini somut senaryolara çevirin:

• Değiştirilebilirlik: "Yeni bir ödeme sağlayıcısı eklemek hangi modüllere dokunmayı gerektirir?"
• Ölçeklenebilirlik: "Kampanya gününde sipariş yükü katlanırsa hangi bileşen önce darboğaz olur?"
• Dayanıklılık: "Bildirim servisi çöktüğünde sipariş alma devam eder mi?"
• Test edilebilirlik: "Sipariş kuralını veritabanı olmadan sınayabilir miyiz?"
• Dağıtılabilirlik: "Yalnızca fatura modülündeki bir düzeltmeyi bağımsız yayınlayabilir miyiz?"
• Güvenlik ve uyumluluk: "Kişisel veriye hangi modüller erişiyor?"

Senaryolar ölçülebilir ve çelişkiyi görünür kılan biçimde yazılmalıdır, çünkü mimari kararlar daima ödünleşimdir: dağıtılabilirlik için bölmek, işlem tutarlılığını zorlaştırabilir. Hangi niteliğin öncelikli olduğu iş tarafıyla birlikte netleştirilmezse değerlendirme zevke dönüşür.

Kanıt toplamak: kod tabanı ne söylüyor?

Değerlendirmeyi izlenimlere değil, ölçülebilir kanıta dayandırın. Pratik kaynaklar şunlardır:

• Bağımlılık grafiği: Modüller arası çağrıları çıkaran araçlarla döngüsel bağımlılıkları, her şeyin bağlandığı "merkez" modülleri ve katman ihlallerini görün. Çizilen mimari ile gerçek bağımlılıklar çoğu zaman ayrışır.
• Değişim geçmişi: Sürüm kontrol geçmişinde sık değişen ve aynı anda değişen dosyaları bulun. Her özellikte birlikte değişen modüller, yanlış yerden bölünmüş sorumluluğun işaretidir.
• Sıcak noktalar: Hem sık değişen hem karmaşık dosyalar, refactor çabasının en yüksek getiri sağlayacağı yerlerdir.
• Test ve dağıtım verisi: Hangi alanlar testsiz, hangi değişiklikler üretimde geri alınıyor, bir değişikliğin canlıya çıkması ne kadar sürüyor soruları sistemin gerçek sağlığını gösterir.
• Hata ve olay kayıtları: Tekrarlayan olayların hangi bileşenlerde toplandığı mimari zayıflıkları doğrular.
• Ekiple görüşme: Kodun yazılmadığı bilgi (neden böyle yapıldı, hangi köşelere kimse dokunmuyor) çoğunlukla geliştiricilerdedir.

Kanıtı, değerlendirdiğiniz senaryolarla eşleştirin: "yeni sağlayıcı eklemek" senaryosu için ödeme koduna bağlı modülleri çıkarmak, soyut bir tartışmadan daha çok şey söyler.

Bulguları önceliklendirmek: teknik borç envanteri

Bulgular uzayabilir; hepsini düzeltmek gerekmez. Her bulgu için şu soruları sorun: Hangi kalite niteliğini ve hangi iş senaryosunu tehdit ediyor? Ne sıklıkla bedel ödetiyor (her sprintte mi, nadir mi)? Düzeltmek ne kadar riskli ve pahalı?

Sık bedel ödeten, iş hedefini doğrudan tehdit eden ve görece ucuza düzelen bulgular önce gelir. Nadiren dokunulan ve çalışan, çirkin ama izole bir modülü yeniden yapılandırmak ise genellikle değmez. Envanteri her bulgu için kısa bir kayıtla tutun: tanım, etkilenen senaryo, kanıt, önerilen çözüm, riskler. Önemli kararları mimari karar kaydı (ADR) olarak yazıya dökmek, ekibin aynı tartışmayı yeniden yaşamasını önler.

Değerlendirme raporu iş tarafına anlatılabilir olmalıdır. "Modüller arası bağımlılık yüksek" demek yerine "ödeme değişikliklerinin her seferinde sipariş ve stok modüllerini de etkilemesi nedeniyle özellik teslimi yavaşlıyor" demek karar vericiyi harekete geçirir.

Aşamalı refactor: büyük patlama yerine küçük, güvenli adımlar

Mimari refactor'ün en riskli yolu her şeyi baştan yazmaktır. Yeniden yazım uzun sürer, bu sırada eski sistem değişmeye devam eder ve hedef kayar. Güvenli yaklaşım, sistemin çalışır halde kalarak parça parça dönüştürülmesidir.

Adımlar genellikle şöyle ilerler:

• Davranışı kilitleyin: Dönüştüreceğiniz alanın mevcut davranışını karakterizasyon testleriyle sabitleyin. Test, "doğru" davranışı değil, "şu an olan" davranışı kaydeder; amaç dönüşümde istemeden bir şeyin değişmediğini görmektir.
• Dikişi bulun: Eski ve yeni yapının buluşabileceği bir arayüz noktası açın. Çağıran kodları bu arayüze yöneltin.
• Yan yana çalıştırın: Yeni gerçeklemeyi arayüzün arkasına ekleyin, özellik bayrağı ya da yönlendirme ile trafiği kademeli aktarın. Bu yaklaşım, monolitten parça koparmada kullanılan strangler fig örüntüsünün mantığıdır.
• Eskiyi kaldırın: Yeni yapı kanıtlandıktan sonra eski kodu silin; aksi halde eski ve yeni sistemi birlikte bakımda tutarsınız.
• Her adımda dağıtın: Küçük adımlar canlıya sık çıkar; sorun çıkarsa geri almak kolaydır.

Bağımlılık yönünü düzeltmek de çoğu mimari refactor'ün özüdür: alan kodunun altyapıya değil altyapının alan koduna bağımlı olması, döngüsel bağımlıkların bir arayüz eklenerek kırılması gibi.

Dönüşümü korumak: mimari kuralları otomatik kılmak

Refactor bittikten birkaç ay sonra aynı bozulma yeniden başlayabilir. Bunu engellemek için kuralları insanların hafızasından çıkarıp otomatik denetime bağlayın. Örneğin katman bağımlılık kurallarını (alan katmanı altyapıyı tanımaz) bir mimari test aracıyla kod tabanında sınayın ve derleme hattında başarısız kılın. Döngüsel bağımlılık oluşursa sürecin kırılması, kuralı kâğıt üzerindeki bir niyetten gerçek bir güvenceye çevirir.

Düzenli aralıklarla küçük mimari incelemeler yapmak, büyük ve nadir incelemelerden daha etkilidir. Bağımlılık grafiğini ve sıcak noktaları izleyen hafif bir gösterge paneli ekibin "bozulma" sinyalini erken görmesini sağlar.

Son olarak kültür tarafı: mimari kararların gerekçelerini yazılı tutmak, yeni gelenlerin bağlamı öğrenmesini ve eski kararların koşullar değiştiğinde bilinçle gözden geçirilmesini kolaylaştırır.

Sık yapılan hatalar

• Hedefsiz değerlendirme: Kalite nitelikleri tanımlanmadan yapılan inceleme, kişisel tercihlerin listesine döner.
• Büyük yeniden yazım: Çalışan sistemi bırakıp sıfırdan yazmak, çoğunlukla eski sistemin gizli kurallarını kaybetmeyle sonuçlanır.
• Testsiz taşıma: Davranışı kilitlemeden yapılan yapısal değişiklikler fark edilmeden hata üretir.
• Mimari ile ekip yapısını ayırmak: Modül sınırları ekip sınırlarıyla uyuşmazsa, kod kâğıt üzerinde bölünse bile koordinasyon maliyeti sürer.
• Moda yaklaşımı hedef saymak: Mikroservise geçmek bir hedef değil bir araçtır; hangi senaryoyu iyileştirdiği belli değilse dağıtık sistemin karmaşıklığını boşuna ödersiniz.
• Sadece teknik gerekçe sunmak: İş etkisini ifade etmeyen refactor önerileri öncelik alamaz.

Bu beceriyi Mindset programında nerede çalışırsınız?

Yazılım Mimarisi ve Tasarım Desenleri programının mimari değerlendirme ve refactor modülü, bu sayfadaki konunun doğrudan karşılığıdır; mimari düşünce ve karar alma modülü ile mimari stiller modülü de değerlendirme ölçütlerini besler. Programın gerçek senaryo modülünde ise kurumsal bir mimari tasarımı üzerinde bu bilgilerin birlikte kullanılması hedeflenir.

Eski ve büyümüş kod tabanlarını devralan teknik liderler, mimarlar ve kıdemli geliştiriciler için uygundur. Kurumsal ekiplerde kazanç, mimari tartışmaların ortak bir kanıt ve ölçüt diliyle yapılması ve refactor işinin iş hedefleriyle ilişkilendirilebilmesidir.