Eski (legacy) web uygulamasını baştan yazmadan modernize etmek: iki gerçek örnek

Yıllar içinde büyüyen her yazılımın bir noktada aynı sorunları yaşadığını görüyorum: yeni bir özellik eklemek haftalar sürüyor, küçük bir değişiklik başka bir yeri bozuyor, ekranlar yavaşlıyor ve kodu bilen tek kişi ayrıldığında kimse dokunmaya cesaret edemiyor. Bu noktada en sık duyduğum cümle "Baştan yazalım" oluyor. Çoğu zaman bu en pahalı ve en riskli seçenek. Bu yazıda, eski (legacy) bir web uygulamasını baştan yazmadan nasıl modernize edilebileceğini, kendi projelerimden örneklerle anlatıyorum.

Baştan yazmak neden riskli?

Çalışan bir sistemi baştan yazdığınızda, yıllar içinde biriken iş kurallarının tamamını yeniden keşfetmeniz gerekir. Bu kuralların çoğu hiçbir dokümanda yazmaz, sadece kodun içindedir. Üstelik yeni sistem hazır olana kadar eski sistem de yaşamaya ve değişmeye devam eder. Sonuç: aylarca süren, bütçesi aşılan ve sonunda eski sistemle aynı eksikleri taşıyan bir proje. Baştan yazmanın doğru olduğu durumlar elbette var, ama ilk seçenek olmamalı.

Kademeli modernizasyon nasıl yapılır?

Benim izlediğim yol, sistemi çalışır hâlde tutarken parça parça iyileştirmek:

• Önce ölç ve incele. Kod tabanını inceleyip sorunları öncelik sırasına koymak. Hangi ekran yavaş, hangi modül en çok hata üretiyor, hangi dosya kimsenin dokunmak istemediği yer?
• En pahalı sorundan başla. Geliştirme hızını en çok düşüren ya da kullanıcıyı en çok etkileyen sorunu ilk çöz.
• Ortak bir standart koy. Yeni yazılan her parçanın uyacağı mimari kuralları, klasör yapısını ve bileşen yapısını belirle.
• Parça parça taşı. Modülleri teker teker yeni yapıya geçir. Her adımda sistem çalışmaya devam etsin.
• Bilgiyi yazıya dök. Taşınan her modülün kurallarını dokümante et ki bilgi tek bir kişiye bağlı kalmasın.

Örnek 1: 2.000 sayfalık bir bankacılık uygulaması

Fibabanka'da bankanın çalışanlarının kullandığı Core Banking uygulaması, tescilli ve kapalı bir arayüz teknolojisinden React tabanlı modern bir web mimarisine taşındı. Uygulama 2.000'den fazla sayfadan oluşuyordu ve dönüşüme 20'den fazla ekip katıldı. Her şeyi tek seferde yeniden yazmak yerine önce ortak bir altyapı kurduk: proje iskeletleri, ortak mimari standart, yeniden kullanılabilir bileşen ve yardımcı fonksiyon kütüphaneleri. Böylece her ekip kendi alanını bağımsız olarak taşıyabildi. Bir sayfanın geliştirme süresi 1 haftadan 1 günün altına indi, frontend deneyimi olmayan backend geliştiriciler bile hazır bileşenleri birleştirerek sayfa üretebilir hâle geldi.

Örnek 2: 5 yıllık bir no-code platform

Turkcell Grubu bünyesindeki Ultia'da 5 yıldır geliştirilen bir no-code platformda en büyük sorun performanstı: editöre bileşen eklemek bir dakikayı aşan bekleme demekti. Platformu baştan yazmak yerine önce bu darboğazın kök nedenini bulup çözdük, ardından geliştirici deneyimini iyileştirdik ve aşırı büyümüş dosyaları planlı bir refactor programıyla modüler yapıya ayırdık. Platform çalışmaya devam ederken ekip daha hızlı geliştirmeye başladı.

Ne zaman gerçekten baştan yazmak gerekir?

Kullanılan teknoloji artık desteklenmiyorsa ve güvenlik riski taşıyorsa, iş modeli tamamen değiştiyse ya da sistem o kadar küçükse ki yeniden yazmak taşımaktan ucuzsa. Bu durumlarda bile eski sistemi bir anda kapatmak yerine yeni sistemi modül modül devreye almak riski azaltır.

Nereden başlamalı?

İlk adım kısa bir kod incelemesi. Bir hafta gibi kısa bir sürede kod tabanının durumu, en kritik sorunlar ve gerçekçi bir iyileştirme planı ortaya çıkar. Bu plan, "baştan yazalım mı?" sorusuna tahminle değil, veriyle cevap vermenizi sağlar.

Modernizasyonun gizli kazancı: ekip hızı

Legacy modernizasyonun en çok gözden kaçan faydası, ekibin geliştirme hızıdır. Hot reload süresinin dakikalardan saniyelere inmesi, ortak bileşenlerin hazır olması ve kuralların yazılı olması, her yeni özelliği ucuzlatır. Yatırımın geri dönüşü genellikle ilk birkaç ayda, yeni özelliklerin teslim süresinde görülür. Bu yüzden modernizasyonu bir maliyet kalemi olarak değil, sonraki tüm geliştirmeleri hızlandıran bir altyapı yatırımı olarak düşünmek gerekir. Doğru planlandığında kullanıcılar kesinti yaşamaz, ekip ise ilk haftalardan itibaren farkı hisseder.