Yıllardır çalışan bir yazılımın bakımı zorlaştığında en cazip fikir genellikle sıfırdan yeniden yazmaktır. Oysa yeniden yazım sırasında mevcut ürün çalışmaya devam eder, iş kuralları eski kodun içinde gömülü kalır ve yeni sistemi kullanıcı ancak proje sonunda görür. Kademeli modernizasyon bu riski böler: sistemi canlı tutarak bileşenleri tek tek yeniler. Asıl zorluk, nereden başlanacağına karar vermektir. Bu yazıda ilk 30 günü kod yazmaya değil, envanter, denetim ve önceliklendirmeye ayıran sade bir yol haritası anlatıyoruz. Amaç, ilk bileşen seçimini sezgiye değil kanıta dayandırmaktır.
01Neden yeniden yazmak yerine kademeli modernizasyon?
Büyük yeniden yazım projelerinde üç sorun sık görülür:
- Gizli iş kuralları: Yıllar içinde eklenen istisnalar belgelenmemiştir. Yeni sistemde eksik kalırlar ve ancak canlıda fark edilirler.
- Çift yük: Eski sistem bakım ister, yeni sistem geliştirme ister. Ekip iki ürünü birden taşır.
- Geç geri bildirim: Kullanıcı değeri projenin sonunda görülür. Yanlış varsayımlar da o zaman ortaya çıkar.
Kademeli yaklaşımın bilinen modeli, yeni bileşenlerin eski sistemin yanında büyüyüp trafiği adım adım devraldığı "strangler fig" desenidir. Deseni Microsoft Azure Mimari Merkezi'ndeki Strangler Fig deseni belgesinde okuyabilirsiniz. Her koşulda kademeli yol doğru değildir. Çok küçük ve teknolojisi tamamen terk edilmiş bir araçta yeniden yazım daha makul olabilir. Ancak çoğu kurumsal sistemde ilk adım, neyin nerede olduğunu görmektir.
02Hafta 1-2: Envanter ve denetim
İlk iki haftanın çıktısı, tek sayfalık bir sistem haritası ve bulgu listesidir. Önce envanter çıkarın:
- Modüller, servisler, zamanlanmış işler ve her birinin sorumlusu
- Dış entegrasyonlar: ödeme, ERP, e-posta, üçüncü taraf API'ler
- Veri tabanları ve hangi bileşenin hangi tabloya yazdığı
- Dağıtım biçimi: kim, nasıl, ne sıklıkla yayına alıyor?
- Son 12 ayda en çok hata kaydı açılan ve en sık değişen kod alanları (sürüm geçmişinden ve destek kayıtlarından çıkarılır)
Ardından aynı haritanın üzerinde beş başlıkta denetim yapın:
- Kod ve mimari: Test kapsamı var mı, modüller birbirine ne kadar bağımlı, tekrar eden kod nerede yoğunlaşıyor?
- Bağımlılıklar: Desteği biten çerçeve ve kütüphane sürümleri hangileri? Eski ve savunmasız bileşenler, OWASP Top 10 listesinde ayrı bir risk başlığıdır. Bulgularınızı bu listeyle karşılaştırabilirsiniz.
- Veri: Kişisel veri hangi bileşenlerde tutuluyor, erişim kaydı var mı? Veri güvenliği yükümlülükleri için KVKK Kurumu yayınlarını ve hukuk danışmanınızı referans alın.
- Performans: Web arayüzü varsa yükleme ve etkileşim ölçümlerini web.dev Core Web Vitals tanımlarıyla ölçün ve başlangıç değerini kaydedin.
- Operasyon: Yedekten geri dönüş denendi mi, izleme ve uyarılar var mı, bir hata olduğunda geri dönüş yolu nedir?
Belge yoksa şaşırmayın. Kod, log kayıtları, veri tabanı şeması ve sistemi yıllardır kullanan kişilerle yapılan kısa görüşmeler çoğu zaman yeterli bir başlangıç sağlar.
03Hafta 3: Öncelik kriterleri ve puanlama
Elinizde bulgular olduğunda her bileşeni aynı kriterlerle puanlayın. Her kriter için 1 (düşük) ile 5 (yüksek) arası puan vermek yeterlidir. Önemli olan, puanların tek kişinin görüşü değil, iş birimi ve teknik ekibin ortak kararı olmasıdır.
| Kriter | Sorulacak soru | Yüksek öncelik işareti |
|---|---|---|
| İş etkisi | Bu bileşen yavaşladığında ya da durduğunda ne olur? | Gelir, müşteri deneyimi veya operasyon doğrudan etkilenir |
| Değişim sıklığı | Bu alana ne sıklıkla yeni istek geliyor? | Her sürümde dokunulan alan |
| Risk | Güvenlik, veri veya destek süresi açısından açık var mı? | Desteği biten bileşen, kişisel veri |
| Bağımlılık düzeyi | Diğer bileşenlerden ne kadar ayrılabilir? | Net bir arayüzle izole edilebiliyor |
| Test edilebilirlik | Mevcut davranışı otomatik testle yakalayabilir miyiz? | Girdi ve çıktısı tanımlı |
| Bilgi sahipliği | Bileşeni bilen biri ekipte var mı? | Sorumlu kişi ve dokümantasyon mevcut |
Varsayımlı bir örnekle ilerleyelim. Üç adayınız olsun: raporlama modülü, kimlik doğrulama ve fatura oluşturma. Kimlik doğrulama risk açısından yüksek puan alır, ancak neredeyse her bileşen ona bağlıdır. Bağımlılık ve test edilebilirlikte düşük puan aldığı için ilk dilim olmaya uygun değildir. Raporlama modülü sık değişir, diğer bileşenlere yalnızca veri okuyarak bağlanır ve çıktısı doğrulanabilir. Bu nedenle ilk aday olarak öne çıkar.
Pratik kural şudur: ilk dilim değerli, küçük, izole ve geri alınabilir olmalıdır. En riskli çekirdekle başlamak, ekibin henüz güvenlik ağı kurmadığı bir dönemde en pahalı hatayı yapma ihtimalini artırır.
04Hafta 4: İlk dilimi tanımlayın ve güvenlik ağını kurun
Dördüncü haftada seçilen bileşen için uygulama planı hazırlanır. Plan şu kalemleri içermelidir:
- Karakterizasyon testleri: Mevcut davranışı olduğu gibi yakalayan testler yazın. Yeni bileşenin eskisiyle aynı sonucu verdiğini bu testlerle kanıtlarsınız.
- Yönlendirme katmanı: İstekleri eski ya da yeni bileşene yönlendirebilen bir proxy veya API katmanı planlayın.
- Özellik bayrağı ve geri dönüş: Yeni bileşeni önce küçük bir kullanıcı grubuna açın. Sorun çıkarsa tek adımda eskiye dönülebilmelidir.
- Başarı ölçütleri: Hata oranı, yanıt süresi, destek talebi sayısı gibi 2-3 ölçüt belirleyin ve hafta 2'de kaydettiğiniz başlangıç değerleriyle karşılaştırın.
- Sürüm ritmi: İki haftalık sürümler ve her sürüm sonunda kısa bir demo ile ilerleyin. Böylece geri bildirim erken gelir.
Bu haftanın çıktısı; seçilen bileşen, gerekçeli puan tablosu, test ve geri dönüş planı ile ölçüt listesinden oluşan kısa bir karar belgesidir. Belge, üst yönetim ve teknik ekip arasında ortak referans olur.
05Sık sorulan sorular
30 gün yeterli mi?
Bu sürenin amacı modernizasyonu bitirmek değil, doğru ilk adımı kanıtla seçmektir. Denetimin kapsamı sistemin büyüklüğüne, belge durumuna ve erişilebilir bilgiye göre değişir. Takvimi kendi sisteminize göre yeniden ayarlamak normaldir.
Dokümantasyon yoksa nereden başlanır?
Kod deposu, sürüm geçmişi, uygulama ve sunucu logları, veri tabanı şeması ve sistemi günlük kullanan ekiplerle yapılan görüşmeler ilk kaynaklardır. Canlı trafik kayıtları, hangi uç noktaların gerçekten kullanıldığını gösterir. Kullanılmayan alanlar modernizasyon kapsamından çıkarılabilir.
Hangi bileşenle başlamamalıyız?
Genellikle herkesin bağımlı olduğu çekirdek bileşenlerle (kimlik doğrulama, ödeme çekirdeği gibi) ve hiç test edilemeyen, sahibi belirsiz alanlarla başlanmaz. Önce daha izole bir dilimle yöntemi ve güvenlik ağını doğrulamak, sonraki adımları kolaylaştırır.
06Sonuç
Kademeli modernizasyonun ilk 30 günü, sistemi tanımaya ve karar vermeye ayrılmış bir dönemdir: iki hafta envanter ve denetim, bir hafta ortak kriterlerle puanlama, bir hafta da ilk dilimin test ve geri dönüş planı. Bu çerçeveyle ilk bileşen, en gürültülü olan değil, değeri yüksek, bağımlılığı düşük ve doğrulanabilir olandır. Mevcut yazılımınız için denetim ve önceliklendirme çalışmasını birlikte yürütmek isterseniz OPEIS Teknoloji'nin yazılım geliştirme hizmet sayfasından bilgi alabilirsiniz.
DESTEK
Bu konuda destek alın
Yazıdaki yaklaşımı kendi altyapınıza uyarlamak için ekibimize yazın. 1 iş günü içinde dönüş yapıyoruz.
İletişime geçin