Çalışan sistemi baştan yazmadan modernize etmek

Bize gelen taleplerin önemli bir kısmı "bu sistemi baştan yazalım" diye başlıyor. Çoğunda cevabımız hayır oluyor — ve bu, iş kaçırmak pahasına verdiğimiz bir cevap. Sebebi basit: baştan yazma projelerinin büyük kısmı ya bitmiyor ya da bittiğinde eski sistemin yaptığı işin yarısını yapıyor.

Baştan yazma neden başarısız oluyor?

Çalışan bir sistem, yıllar içinde biriken yüzlerce küçük iş kuralını içinde taşır. Bunların hiçbiri dokümante değildir; kimse hepsini hatırlamaz. Baştan yazarken bu kuralların ancak bir kısmını yakalarsınız, kalanı canlıya geçtikten sonra hata olarak geri döner.

İkinci sebep: baştan yazma sürerken eski sistem durmaz. Yeni özellik talepleri gelmeye devam eder ve bunlar iki yerde birden yazılmak zorunda kalır. Proje uzadıkça bu makas açılır.

Baştan yazmanın gerçek maliyeti, yeni sistemi yazmak değil; eski sistemin bildiği ama kimsenin yazmadığı kuralları yeniden keşfetmektir.

Strangler Fig: parça parça değiştirme

Yaklaşımın adı, konak ağacın etrafını sarıp zamanla onun yerini alan incir türünden geliyor. Eski sistemi bir anda değiştirmek yerine, önüne bir yönlendirme katmanı koyup işlevleri tek tek yeni sisteme taşıyorsunuz.

1. Eski sistemin önüne bir yönlendirici (reverse proxy veya API gateway) konur. Başlangıçta her istek eski sisteme gider — davranış hiç değişmez.
2. Tek bir işlev seçilir ve yeni sistemde yazılır.
3. Yönlendirici o işleve ait istekleri yeni sisteme göndermeye başlar. Kalan her şey eskide kalır.
4. Sorun çıkarsa yönlendirici geri alınır; geri dönüş bir yapılandırma değişikliğidir, bir dağıtım değil.
5. İşlev kararlı çalıştığında sıradaki işleve geçilir.
6. Eski sistemde hiçbir işlev kalmadığında kapatılır.

Nereden başlamalı?

İlk taşınacak işlevi seçerken üç kritere bakıyoruz:

• Sınırları net olmalı — diğer modüllerle veri paylaşımı az olan bir işlev seçin.
• Değeri görünür olmalı — ilk adım işe yaramıyorsa proje desteğini kaybeder.
• Geri alınabilir olmalı — yanlış giderse eskiye dönmek mümkün olmalı.

Genelde raporlama iyi bir başlangıç: okuma ağırlıklıdır, yazma yapmadığı için veri tutarlılığı riski düşüktür ve sonucu yönetim hemen görür. Ödeme veya stok düşümü gibi yazma ağırlıklı çekirdek işlevler en sona bırakılır.

Geçiş sırasında veri

En zor kısım burası. İki sistem bir süre aynı anda çalışacak ve ikisi de veriye ihtiyaç duyacak. Üç seçenek var:

Tek kaynak, ortak veritabanı

Yeni sistem eski veritabanını okur. En basit ve geçiş dönemi için genelde en doğru olan. Yeni sistemin şemayı değiştirmemesi şartıyla tutarlılık sorunu çıkmaz.

Olay tabanlı senkronizasyon

Eski sistem değişiklikleri olay olarak yayınlar, yeni sistem kendi kopyasını günceller. Sistemleri gerçekten ayırır ama gecikmeyi kabul etmeniz gerekir ve tersine akış (yeni → eski) ayrıca kurulmalıdır.

Çift yazma

Her iki sisteme de aynı anda yazmak. Kulağa basit gelir ama biri başarılı olup diğeri başarısız olduğunda tutarsızlık oluşur ve bunu düzeltmek zordur. Yalnızca kısa geçiş pencerelerinde ve mutlaka bir uzlaştırma işiyle birlikte kullanın.

Ölçün, yoksa bitmez

Strangler Fig projelerinin gerçek riski başarısızlık değil, yarım kalmaktır. İki sistem kalıcı olarak yan yana çalışmaya başlar ve bakım maliyeti tek sistemden yüksek olur.

Bunu önlemek için taşınan işlev oranını görünür bir yerde takip edin ve eski sistemin kapatılma tarihini baştan koyun. Tarih kayarsa sebebini konuşun; kaymasına izin verirseniz hiç kapanmaz.

Ne zaman gerçekten baştan yazmalı?

Baştan yazmayı önerdiğimiz durumlar var:

• Teknoloji artık güvenlik güncellemesi almıyor ve yükseltme yolu yok.
• İş modeli değişti; eski sistemin varsaydığı temel kurallar artık geçerli değil.
• Sistem gerçekten küçük — birkaç haftalık iş ise parçalı geçişin ek karmaşıklığı gereksizdir.
• Kaynak koda erişim yok ve sağlayıcı desteği bitti.

Bunların dışında, çalışan bir sistemin üzerine inşa etmek neredeyse her zaman daha hızlı ve daha ucuz sonuç veriyor. Teklif alırken bunu sorun: karşınızdaki firma neden baştan yazmayı öneriyor — teknik bir gerekçe mi var, yoksa mevcut kodu okumak istemiyor mu?

• legacy
• modernizasyon
• mimari
• entegrasyon