Bir lojistik firmasının 2014'te yazdırdığı sipariş ve sevkiyat panelini düşünün. PHP 5 üzerinde çalışıyor, ekranlar jQuery ile yapılmış, veritabanı yıllar içinde elden ele geçmiş. Panel her gün kullanılıyor ve işini görüyor. Ama sunucu artık güncellenemiyor, mobilde ekranlar dağılıyor ve koda dokunan her geliştirici "burayı değiştirirsem başka neresi bozulur" diye tedirgin oluyor.
Bu noktada akla gelen ilk cümle genelde aynıdır: "Bunu baştan yazalım." Anlaşılır bir istektir; eski kod çirkindir, yenisi temiz olacaktır. Bu yazıda bu kararın neden sanıldığından riskli olduğunu ve aynı sonuca daha güvenli bir yoldan, eski sistemi adım adım değiştirerek nasıl ulaşılabileceğini anlatıyoruz. Örnekler PHP ve .NET Framework üzerinden, ama yaklaşım hangi dilde yazılmış olursa olsun aynı.
Baştan yazmanın görünmeyen maliyeti
Eski bir uygulama yalnızca ekranlardan ibaret değildir. Yıllar içinde içine sayısız küçük kural girmiştir: belirli bir müşteri grubuna farklı vade, ay sonunda kapanan bir hesap, bir alan boş bırakılırsa otomatik atanan bir depo. Bu kuralların çoğu hiçbir belgede yazmaz; yalnızca kodda vardır ve onları yazan kişi çoktan ayrılmıştır.
Sıfırdan yazılan sistem bu kuralları ancak birisi hatırlarsa içerir. Hatırlanmayanlar yeni sistem yayına girdikten sonra, bir müşteri yanlış fatura aldığında ortaya çıkar.
İkinci sorun zamandır. Yeni sistem bitene kadar eski sistem de çalışmak zorundadır. Bu sürede iş durmaz; yeni talepler gelir ve ya eski sisteme eklenir (yeni sistem geride kalır) ya da bekletilir (iş birimi sabırsızlanır). Planlanan altı ay çoğu zaman bir buçuk yıla uzar.
Üçüncü sorun geçiş günüdür. Bütün kullanıcıların bir sabah eski sistemden yenisine geçtiği tek bir an, projenin bütün riskinin tek bir güne toplanması demektir.
Alternatif: eskisini yavaş yavaş sarmalamak
Yazılım dünyasında buna "strangler fig" yaklaşımı denir. Adını, bir ağacın etrafını saran ve zamanla onun yerini alan incir türünden alır. Fikir basittir: eski sistemi bir anda kapatmazsınız; önüne bir katman koyar, işlevleri birer birer yeni koda taşır ve her taşınan parçada eskisini emekliye ayırırsınız. Geçiş boyunca eski ve yeni sistem yan yana çalışır.
Lojistik paneline dönersek, bu şöyle ilerleyebilir:
- Önce sevkiyat takip ekranı yeni bir arayüzde yazılır ve eski veritabanından okur.
- Kullanıcılar bu ekranı birkaç hafta kullanır; eski ekran yedek olarak durur.
- Sorun yoksa eski takip ekranı kapatılır, sıradaki modüle geçilir.
Her adım küçük, geri alınabilir ve tek başına değer üretir. İşin büyük kısmı bitmeden bile kullanıcılar daha iyi bir ekranla çalışmaya başlar.
Adım 1: Önce bugünkü davranışı kayıt altına alın
Koda dokunmadan önce sistemin bugün ne yaptığını yakalamak gerekir. Bunun en pratik yolu, en kritik akışlar için otomatik testler yazmaktır: sipariş girildiğinde hangi kayıtlar oluşuyor, fatura tutarı nasıl hesaplanıyor, iade hangi tablolara yansıyor.
Bu testler "doğru" davranışı değil, "bugünkü" davranışı tarif eder. Amaç, yeni kod aynı girdiye aynı sonucu veriyor mu, bunu her değişiklikte kontrol edebilmektir. Gözden kaçmış iş kuralları da genellikle bu aşamada ortaya çıkar; testi yazarken "bu neden böyle hesaplanıyor?" sorusu kendiliğinden sorulur.
Adım 2: Araya bir kapı koyun
Eski sistemle yeni parçalar arasında bir geçiş noktası gerekir. Web uygulamalarında bu genellikle bir yönlendirme katmanıdır: belirli adresler yeni uygulamaya, geri kalanı eski uygulamaya gider. Kullanıcı tek bir uygulama kullandığını sanır.
Veri tarafında da benzer bir kapı kurulur. Eski veritabanına doğrudan bağlanan yeni kod yerine, araya küçük bir API katmanı koymak işinizi kolaylaştırır. Bugün API eski tablolardan okur; yarın veri yeni bir şemaya taşındığında yalnızca API'nin içi değişir, ekranlar etkilenmez.
Adım 3: Taşınacak sırayı akıllıca seçin
Her modül aynı değerde değildir. Sıra belirlerken iki soruya bakın:
- En çok acı veren nerede? Kullanıcıların en çok şikâyet ettiği, en sık hata çıkan ya da mobilde hiç kullanılamayan ekran.
- En az bağımlılığı olan hangisi? Başka modüllere az dokunan, tek başına taşınabilecek bir parça.
İkisinin kesiştiği yer genelde iyi bir başlangıçtır. Raporlama ekranları, salt okunur listeler ve müşteriye açık sayfalar çoğu zaman bu kesişimde durur. Fatura hesaplama gibi her şeyin bağlı olduğu çekirdek parçalar ise en sona, testler oturduktan sonraya kalır.
Adım 4: Güvenlik açığını beklemeden kapatın
Modernizasyon aylar sürebilir; eski sürümlerdeki bilinen açıklar ise bugün risktir. Bu yüzden ilk iş olarak yapılabilecek bazı şeyler vardır: desteklenen en yakın PHP ya da .NET sürümüne yükseltme (çoğu zaman sanıldığından az değişiklik ister), eklenti ve kütüphanelerin güncellenmesi, yönetici paneline erişimin kısıtlanması, düzenli yedeğin ve yedekten geri dönme denemesinin yapılması.
Bunlar uygulamayı modern yapmaz ama yenileme süresince ayakta ve güvende tutar.
Adım 5: Her taşımanın bir bitiş çizgisi olsun
Kademeli geçişin en büyük tuzağı, yarıda kalmasıdır. Yeni ekran yazılır ama eskisi "ne olur ne olmaz" diye açık bırakılır; iki yıl sonra iki sistemin bakımını yapıyorsunuzdur.
Bunu önlemek için her modül taşımasını bir kapanışla bitirin: eski ekranın kullanım oranına bakın, sıfıra yaklaştığında kapatın ve ilgili eski kodu silin. Bir tabloda hangi modülün nerede olduğunu (eski, geçişte, yeni) tutmak, projenin gerçekten ilerlediğini herkese gösterir.
Baştan yazmak ne zaman doğru karar?
Bu yaklaşım her durumda en iyisi değildir. Şu durumlarda sıfırdan başlamak daha mantıklı olabilir:
- Uygulama küçükse ve birkaç haftada yeniden yazılabiliyorsa.
- İş süreci baştan değişiyorsa ve eski kuralların çoğu zaten geçerliliğini yitirdiyse.
- Kod o kadar iç içe geçmişse ki araya hiçbir katman konulamıyorsa.
Bu kararı vermek için önce mevcut sistemin dürüst bir incelemesi gerekir: kod, bağımlılıklar, sunucular, erişimler ve belgeler. İnceleme raporu, hangi yolun daha az riskli olduğunu tartışmaya dayalı değil, gerçek bilgiye dayalı olarak konuşmanızı sağlar.
Kısaca
Eski bir PHP ya da .NET uygulamasını baştan yazmak cazip görünür ama içine gömülmüş iş kurallarını, uzun paralel çalışma dönemini ve tek günlük riskli geçişi de beraberinde getirir. Daha güvenli yol: bugünkü davranışı testlerle kayıt altına almak, araya bir yönlendirme ve API katmanı koymak, modülleri acı ve bağımlılık sırasına göre tek tek taşımak, güvenlik güncellemelerini beklemeden yapmak ve her taşımayı eski kodu silerek kapatmak.
Yazılım bakım ve destek hizmetimizde devraldığımız sistemlere bu sırayla yaklaşıyoruz: önce yazılı bir inceleme raporu, sonra güvenlik güncellemeleri ve kritik akışların testleri, ardından eski ve yeni sistemin yan yana çalıştığı kademeli bir geçiş.
Böyle bir proje mi planlıyorsun?
10 adımda planla