Eski sistemi yeniden yazmak mı, kademeli modernizasyon mu?

Önce sorunu yeniden yazım talebinden ayırın

“Kod eski” tek başına yatırım gerekçesi değildir. Kararı tetikleyen somut sorunu yazın: Yeni bir müşteri için veri ayrımı mı gerekiyor, bir iş akışı sık mı hata veriyor, yoksa küçük bir değişikliğin yayına çıkması mı zorlaşıyor? Aynı belirti farklı nedenlerden kaynaklanabilir.

Örneğin teslim süresi uzuyorsa darboğazın kod bağımlılığı mı, test eksikliği mi, ortam kurulumu mu, yoksa karar bekleme süresi mi olduğunu ayırın. Yeni uygulama yazmak, son üç sorunu kendiliğinden çözmez. Değiştirmek istediğiniz davranışı ve bunu nasıl gözlemleyeceğinizi önce tarif edin.

Seçenekleri aynı sorularla karşılaştırın

Aşağıdaki tablo bir değerlendirme çerçevesidir; otomatik karar kuralı değildir. Bir satırdaki avantajı diğer satırlardaki maliyetlerle birlikte tartın. “Bilmiyoruz” yanıtlarını teklif kapsamına inceleme işi olarak ekleyin.

Bütçe ve takvimden önce toplanacak kanıtlar

İlk inceleme yalnızca kod kalitesini puanlamamalı. İşletim, veri ve teslim süreci de kapsamda olmalı. Her bulgunun yanında kaynağını ve bilinmeyenleri tutun:

• Davranış envanteri. İş açısından kritik akışlar, nadir istisnalar, zamanlanmış işler ve dış entegrasyonlar. Ekranda görünmeyen bir görev de geçiş kapsamına dahildir.
• Bağımlılık haritası. Aynı tabloyu güncelleyen uygulamalar, ortak kimlik doğrulama, dosya alışverişi ve bir işlem sırasında çağrılan diğer bileşenler.
• Mevcut işletim verisi. Destek kayıtları, hata örnekleri, bekleme süreleri ve dağıtım geçmişi. Yaklaşık bir izlenim ile ölçülmüş bir sorunu ayrı yazın.
• Korunacak davranışlar. Kritik girişler ve beklenen çıktılar için tekrar çalıştırılabilir kontroller. Bugünkü davranışın hangisinin gereksinim, hangisinin hata olduğunu ürün ekibiyle belirleyin.
• Ekip ve erişim koşulları. Kod, ortam ve veri erişimleri; sistemi bilen kişiler; mevcut işlere ek olarak geçişi kimin işleteceği. Erişilemeyen alanı incelenmiş saymayın.

Kademeli modernizasyon pratikte ne demek?

Martin Fowler’ın Strangler Fig yaklaşımı, eski sistemin sorumluluklarının zaman içinde yeni yapıya aktarılmasını anlatır. Değişim tek bir büyük geçişe sıkışmaz; yatırım ve elde edilen değer aşamalar halinde görünür olabilir. Bu yaklaşım dönüşümü kolay veya kendiliğinden başarılı yapmaz. Martin Fowler: Strangler Fig.

Bu yazıdaki öneri, ilk adım için ekip tarafından anlaşılabilen ve sonucu sınanabilen bir akış seçmek. Her adımın sonunda kullanıcıya sunulabilen bir işlev veya doğrulanmış bir belirsizlik azalması olmalı. Yalnızca yeni altyapı kurmak, geçişin ilerlediğini göstermeye yetmez.

Geçişin en zor kısmı iki sistemin birlikte yaşaması olabilir

Microsoft’un mimari rehberi, geçici yönlendirme katmanının işletim maliyetini ve darboğaz ya da tek hata noktası olma riskini vurgular. Ortak veri depoları ve iki yönlü bağımlılıklar ayrıca ele alınmalıdır. Geçiş katmanı da tasarlanması ve izlenmesi gereken bir sistemdir. Microsoft Azure Architecture Center: Strangler Fig pattern.

• Bir kayıt için esas kabul edilen veri hangi sistemde? Aynı kaydı iki taraf değiştirebiliyorsa çakışmayı kim çözecek?
• Bir istek yeniden denendiğinde işlem tekrarlanacak mı? Eski ve yeni akışın sonuçlarını nasıl karşılaştıracaksınız?
• Yeni yol sorun çıkardığında yalnızca trafiği çevirmek yeterli mi, yoksa veriyi de düzeltmek gerekiyor mu?
• Geçici adaptörü ve eski akışı kaldırma koşulu nedir? Bu işi kimin üstleneceği belli mi?

Yeniden yazım ne zaman ciddi bir seçenek olur?

Sınırları küçük ve iyi bilinen bir uygulamada, bütün davranışları doğrulamak ve tek bir geçişi hazırlamak uygulanabilir olabilir. Buna karşılık yalnızca “yeni teknoloji daha temiz” gerekçesi kapsamı, geçişi veya sahipliği açıklamaz. Yeniden yazım teklifinde yeni uygulamanın geliştirilmesi kadar eski sistemin kapanış planını da isteyin.

Kademeli yaklaşımı da peşinen doğru kabul etmeyin. Eski ve yeni yolları ayırmak için gereken müdahale, bütçeyi veya eldeki süreyi aşabilir. Böyle bir durumda küçük bir teknik keşifle ayrıştırmanın mümkün olup olmadığını sınayın; sonuç belirsizse teslim planını kesinleşmiş gibi sunmayın.

AWS’nin rehberi, iş alanı anlaşılmadan yapılan erken ayrıştırmanın yanlış servis sınırları ve maliyet yaratabileceğini belirtir. Bu nedenle ilk kararın “kaç servis kuracağız?” olması gerekmez. Önce sorumlulukları ve bağımlılıkları anlamak gerekir. AWS Prescriptive Guidance: Strangler fig pattern.

Örnek: rapor üretimini ayırmadan önce

Bu, karar adımlarını göstermek için hazırlanmış varsayımsal bir SaaS örneğidir; müşteri vakası değildir.

Uygulama içinden alınan bir raporun uzun sürdüğünü düşünün. İlk hedef “rapor servisi kurmak” yerine, hangi raporun hangi koşulda kabul edilebilir sürede hazırlanması gerektiğini belirlemek olsun. Önerilen inceleme sırası:

1. Temsilî raporları ve izin kurallarını listeleyin. Sonucun hangi veriye, hangi ana göre hesaplandığını açıklayın.
2. Beklemenin sorgudan mı, hesaplamadan mı, yoksa dosya üretiminden mi kaynaklandığını ölçün. Sorun mevcut uygulamada dar bir değişiklikle çözülebiliyorsa bu seçeneği de değerlendirin.
3. Ayrı bir iş akışı gerekiyorsa deneme çıktısını mevcut çıktıyla karşılaştırın. İncelemeyi yalnızca dosyanın oluşmasına değil içerik ve yetki doğruluğuna bağlayın.
4. Yeni yolu sınırlı kullanıma açmadan önce hata, yeniden deneme ve geri dönüş adımlarını yazın. Kullanıcıya gönderilen bir çıktının ikinci kez gönderilmesini nasıl önleyeceğinizi belirleyin.
5. Kabul edilen kontroller sağlandığında sorumluluğu devredin. Eski zamanlanmış iş, sorgu veya ekranın kaldırılmasını ayrı ve sahipli bir iş olarak kapatın.

Devam ve durdurma koşullarını baştan yazın

İlk bölüm tamamlanınca yalnızca yeni kodun çalışmasına bakmayın. Ürün davranışı korunmuş mu, işletim yükü anlaşılmış mı, ekip akışın sahibi olabiliyor mu? Kabul ölçütü sağlanmıyorsa kapsamı büyütmeden nedeni araştırın. Her sonraki bölümü öncekinin kanıtı üzerinden kararlaştırın.

Bir sayfalık karar özeti hazırlayın

• Çözülecek iş sorunu ve korunacak davranış
• Değerlendirilen seçenekler ve elenenlerin gerekçesi
• Doğrulanmış bulgular ile açık varsayımlar
• İlk adım, sahibi ve kabul ölçütleri
• Geçiş, geri dönüş ve eski sistemi kaldırma koşulları