Her şirketin "eski sistem"i var. 8 yıllık bir iç portal. 12 yıllık bir entegrasyon servisi. Bir keresinde dışarıdan yazdırılıp sonra unutulmuş bir muhasebe köprüsü. Çalışıyor — ama kimse dokunmak istemiyor.

Sonra bir gün ihtiyaç değişir: yeni bir özellik eklemek gerekir, performans yavaşlar, geliştirici bulunamaz, güvenlik denetiminden ortalama bir not gelir. Toplantıda biri sorar: "Bunu yeniden yazsak mı?"

Bu yazı o sorunun cevabını vermek için değil — doğru soruyu sormak için.

"Sıfırdan yazalım" cazibesi

Yazılımcı zihni rewrite'a aşıktır. Eski kod karmaşık, kararları başkası vermiş, dokümantasyonu yok. Sıfırdan yazsak temiz olur, modern olur, ekibin yarısı sevinir.

Bu his çoğu zaman hatadır. Eski kodun karmaşıklığının önemli bir kısmı, kodun değil gerçek dünyanın dağınıklığını yansıtır:

• Yıllar içinde patlayan edge case'ler için eklenmiş kontroller.
• "Müşteri X şu durumda şöyle bir hesap istiyor" diye yamanmış özel kurallar.
• Bir defaya mahsus sanılıp kalıcı hale gelen entegrasyonlar.
• Yasal uyumluluk için zorunlu hale gelmiş audit log'lar.

Sıfırdan yazımda bu kuralların hepsi tekrar keşfedilmek zorunda kalır. Genellikle bir veya iki yıl boyunca yeni sistem eskinin gerisinde kalır.

Sayısız "rewrite projesi" gördük ki:

• 12 ay söz verildi, 30 ay sürdü.
• Yeni sürüm canlıya geçtiğinde eski özelliklerin önemli bir kısmı eksikti.
• Müşteriler iki sistemi aynı anda kullanmak zorunda kaldı.
• Sonunda eski sistem bir yıl daha çalıştı.

Ne zaman rewrite mantıklı?

Sıfırdan yazımın doğru karar olduğu durumlar var, ama beklediğinizden daha az sıklıkta:

• Teknoloji yığını tamamen ölmüş. Geliştirici bulunamıyor, kütüphaneler güncellenmiyor, güvenlik açıkları kapatılamıyor.
• Mimari iş ihtiyacını engelliyor. Sistem tek parça halinde tasarlanmış ama artık birden fazla ekip aynı kodu değiştirmek istiyor. Refactoring tek başına çözmüyor.
• Veri modeli baştan yanlış. "Müşteri" diye tek tablo var, ama gerçekte üç farklı kavram. Bütün sorgular bunun etrafında bükülmüş.
• Ürün vizyonu değişti. Sistem B2B için kuruldu, şirket artık B2C odaklı. Adapt etmek baştan yazmaktan zor.

Bu listeden iki veya daha fazlası geçerliyse, rewrite konuşmaya değer. Sadece "kod çirkin" hissi varsa — değer.

Aşamalı modernizasyon: çoğu zaman doğru yol

Çoğu durumda doğru cevap "ikisi de değil" — eski sistemi parça parça değiştirmek. Yeni özellikleri eski sistemin etrafında yazıyor, eski parçaları zamanla emekliye ayırıyorsunuz.

Pratikte şöyle ilerliyor:

1. Eski sistemin önüne bir geçit kuruluyor. Bütün istekler önce yeni katmandan geçer, gerektiğinde eskiye yönlendirilir.
2. Yeni özellikler yeni mimaride yazılıyor. Geliştirme hızı yeni katmanda artar.
3. Eski parçalar tek tek değiştiriliyor. Bir modül "ödeme", bir başkası "raporlama"... her biri ayrı bir proje.
4. Trafik yavaşça kaydırılıyor. Yeni modül çalışır vaziyette canlıdayken eskinin önüne geçer.
5. Eski parça emekli ediliyor. Sadece kullanılmadığından emin olduktan sonra silinir.

Bu yöntemin avantajı: her aşamada çalışan bir sistem var. Risk yayıldığı için yönetilebilir. İş tarafı dakikalık kesinti yaşamaz.

Dezavantajı: daha fazla disiplin gerektirir. "İki sistemi aynı anda yönet" anlamına gelir, ki bu da farklı bir karmaşıklık. Kısa vadede iki sistem maliyeti taşırsınız.

"Yapmalı mıyız?" sorusu önce gelir

Modernizasyon konuşmasına başlamadan önce sorulması gereken bir soru daha var: bu işi kendiniz mi yapmalısınız?

Yıllar önce özel yazdırılmış birçok modül, bugün hazır bir SaaS ile değiştirilebilir. Yıllarca bakım yapıyorsanız, ya farklılaştırıcı bir şey yaratıyordur ya da artık bir yük. İkincisi geçerliyse, modernize etmek yerine devretmek daha mantıklı olabilir.

İki soru sorulmalı:

• Bu yazılım bizim için stratejik bir fark yaratıyor mu?
• Bu yazılımı sıfırdan kurmak bugün doğru karar olur muydu?

İki cevap da "hayır" ise, modernizasyon değil dışsallaştırma konuşulmalı.

Sık görülen 3 tuzak

1. "Yeniden yazma" planının altında gizli "büyük yeni özellik" projesi. Rewrite konuşması başladığında genellikle yeni özellik talepleri de paketlenir. Bu, projenin riskini katlar. Ya modernizasyon ya yeni özellik — ikisi aynı anda nadiren başarılı olur.

2. Yeni sistem henüz hazır değilken eskiyi silmek. Eski sistem psikolojik olarak rahatsız edicidir ama hâlâ üretiyor. Yeni sistem stabil olana kadar emekli edilmesi acele edilmemeli.

3. Eski sistemi yapan kişi gittiyse, dokümantasyon yazmadan başlamak. "O kişi gitti, kimse bilmiyor" durumunda yapılması gereken önce davranışın çıkartılması, sonra modernizasyon. Bilinmeyeni sıfırdan yazmak iki kat riskli.

Karar için pratik bir çerçeve

Aşağıdaki soruları sırayla cevaplayın:

• Eski sistem şu an üretmeye devam ediyor mu?
• Yeni özellikler eklemek mümkün ama yavaş mı? (Mümkün değilse durum farklı.)
• Geliştirici bulmak mümkün mü?
• Mimari iş ihtiyacını engelliyor mu, yoksa sadece estetik olarak rahatsız edici mi?
• Yarın bu sistemi sıfırdan kurmaya başlasanız, aynı mimariyi mi seçerdiniz?

Bu sorulara verilen cevaplar genellikle "rewrite mi, incremental mı" kararını netleştirir. Çoğunda doğru cevap aşamalı modernizasyon olur.

Sonuç

Eski yazılımdan kurtulmak isteği doğal. Ama "kurtulmak"la "değiştirmek" farklı işler. Çoğu zaman "kurtulmak" gerekmez — doğru parçayı doğru zamanda değiştirmek yeter.

Bu konuyu birlikte konuşmak isteyenler için keşif aşaması ücretsiz. Mevcut sisteminizde neyin değişmesi, neyin olduğu gibi kalması gerektiğine birlikte karar veriyoruz. İletişim sayfasından ulaşabilirsiniz.