Eski yazılımı yenilemek mi baştan yazmak mı sorusu, çoğu işletmede teknik bir tartışma gibi başlar; fakat aslında operasyon, maliyet, veri, kullanıcı alışkanlığı ve iş sürekliliği kararıdır. Mevcut yazılım yavaş çalışıyor, yeni özellik eklemek zorlaşıyor, entegrasyonlar kırılıyor veya güvenlik riski büyüyorsa değişim kaçınılmaz olabilir. Ancak bu değişimin yolu her zaman “sıfırdan yazalım” değildir.
Baştan yazmak cazip görünür: temiz teknoloji, yeni arayüz, modern mimari, daha iyi performans. Fakat eski yazılım yıllardır gerçek kullanıcı, gerçek veri, gerçek hata ve iş kuralı biriktirmiştir. Bunların tamamı dokümantasyonda yer almayabilir. Yenileme kararı bu görünmeyen bilgiyi hesaba katmadan verilirse proje tahmin edilenden uzun, pahalı ve riskli hale gelebilir.
Önce sorun doğru adlandırılmalı
“Yazılım eskidi” ifadesi karar almak için yeterli değildir. Eski olan ne? Arayüz mü, teknoloji mi, veritabanı mı, performans mı, güvenlik mi, kullanıcı deneyimi mi, iş akışı mı? Sorun doğru adlandırılmazsa çözüm yanlış seçilir.
Örneğin yalnızca arayüz kötü ise komple yeniden yazım gerekmeyebilir. API yapısı sağlıklıysa yeni bir kullanıcı arayüzü geliştirilebilir. Sorun sunucu kapasitesi veya sorgu performansıysa veritabanı optimizasyonu ve altyapı iyileştirmesi yeterli olabilir. Sorun iş akışının değişmiş olmasıysa, yeni modül veya süreç tasarımı gerekebilir.
Yazılım geliştirme kararında ilk adım, mevcut sistemin hangi katmanında problem olduğunu tespit etmektir. Aksi halde teknik borç, kullanıcı memnuniyetsizliği ve iş süreci karmaşası tek torbaya atılır.
Baştan yazmak neden risklidir?
Baştan yazma kararında en büyük risk, mevcut yazılımın taşıdığı görünmeyen bilgiyi hafife almaktır. Eski sistemde yüzlerce küçük iş kuralı, kullanıcı alışkanlığı, hata düzeltmesi, veri istisnası ve operasyon kolaylığı olabilir. Bunlar dokümanda yoksa yeni sistem ilk bakışta temiz görünür ama sahada eksik çalışır.
Joel Spolsky, Netscape’in tarayıcı kodunu baştan yazma kararını ele aldığı yazısında, sıfırdan yazmanın yıllarca birikmiş hata düzeltmelerini ve ürün bilgisini çöpe atma riski taşıdığını savunur Joel on Software. Bu yazı eski olsa da verdiği ana ders hâlâ geçerlidir: çalışan kod yalnızca kod değildir; gerçek kullanımdan öğrenilmiş bilgidir.
Baştan yazımda sık görülen riskler:
- Eski sistemdeki iş kuralları eksik keşfedilir.
- Kullanıcı alışkanlıkları yeni arayüzde dikkate alınmaz.
- Veri migrasyonu tahmin edilenden karmaşık çıkar.
- Yeni sistem hazır olana kadar eski sisteme özellik eklenemez.
- İki sistem arasında geçiş süreci uzar.
- Yeni sistem, eski sistemin kritik ama görünmez fonksiyonlarını kaçırabilir.
Yenilemek ne anlama gelir?
Yenilemek, her zaman küçük makyaj yapmak değildir. Yazılım modernizasyonu; arayüzü yenilemek, veritabanını düzenlemek, API eklemek, modülleri ayırmak, güvenliği güçlendirmek, performansı iyileştirmek, eski teknoloji bağımlılıklarını kaldırmak veya bazı parçaları yeni sistemle değiştirmek anlamına gelebilir.
Microsoft’un bulut geçiş stratejileri içinde rehost, replatform, refactor, rearchitect, replace, rebuild ve retain gibi farklı seçenekler yer alır Microsoft Cloud Adoption Framework. Bu sınıflandırma pratik bir gerçeği gösterir: eski yazılımla ilgili tek seçenek “dokunma” veya “sıfırdan yaz” değildir.
Özel web yazılım projelerinde modernizasyon, çoğu zaman mevcut iş bilgisini koruyup teknik yapıyı daha sürdürülebilir hale getirme çalışmasıdır. Doğru yenileme planı, sistemi bir anda yıkmak yerine riskli bölgeleri sırayla ele alır.
Karar matrisi: yenileme mi, baştan yazım mı?
Karar verirken duygusal gerekçeler yerine ölçülebilir kriterler kullanılmalıdır. “Kod kötü”, “panel eski görünüyor” veya “teknoloji modası geçti” tek başına yeterli gerekçe değildir. Aşağıdaki matris ilk değerlendirme için kullanılabilir.
| Kriter | Yenileme daha uygundur | Baştan yazım düşünülebilir |
|---|---|---|
| İş kuralları | Mevcut kurallar çalışıyor ve anlaşılabiliyor | İş modeli kökten değişti veya kurallar karışmış durumda |
| Veri modeli | Veri temizlenerek sürdürülebilir hale gelebilir | Veri yapısı temel iş akışını yanlış temsil ediyor |
| Teknoloji | Güncelleme, refactor veya modül ayrımı mümkün | Teknoloji desteklenmiyor ve güvenli çalıştırılamıyor |
| Kullanıcı etkisi | Kullanıcılar mevcut akışı kullanıyor ve parça parça geçiş mümkün | Mevcut deneyim iş yapmayı ciddi şekilde engelliyor |
| Entegrasyon | API veya ara katmanla genişletilebilir | Entegrasyon eklemek sistemi sürekli kırıyor |
| Risk | Modül modül test ve yayın yapılabilir | Mevcut sistemde küçük değişiklik bile büyük kesinti üretiyor |
Strangler Fig yaklaşımı nedir?
Martin Fowler’ın Strangler Fig yaklaşımı, eski sistemi tek seferde değiştirmek yerine yeni parçaların eski sistemin çevresinde aşamalı olarak geliştirilmesini ve zamanla eski parçaların devreden çıkarılmasını anlatır Martin Fowler. Bu yaklaşım, özellikle iş açısından kritik ve bir anda kapatılamayan sistemlerde değerlidir.
Microsoft Azure Architecture Center da Strangler Fig pattern için eski sistemin belirli fonksiyonlarının yeni uygulama ve servislerle kademeli değiştirildiğini; bu süreçte eski sistemin çalışmaya devam ettiğini açıklar Microsoft Learn. Yani modernizasyon, tek büyük teslimat yerine kontrollü parçalarla ilerleyebilir.
Örnek bir fazlı geçiş şöyle olabilir:
- Mevcut sistem analiz edilir ve kritik iş akışları çıkarılır.
- Yeni bir API veya ara katman kurulur.
- Önce raporlama veya müşteri portalı gibi düşük riskli modül yenilenir.
- Yeni modül canlıda gerçek veriyle çalışır.
- Eski modülün sorumluluğu azaltılır.
- Sonraki modül aynı mantıkla taşınır.
- Eski sistem, bağımlılıklar bitince devre dışı bırakılır.
Hangi durumlarda baştan yazmak mantıklıdır?
Baştan yazım her zaman yanlış değildir. Bazı sistemlerde mevcut yapı o kadar sınırlayıcıdır ki, yenileme sürekli geçici çözüm üretir. Ancak bu karar net gerekçelere dayanmalıdır.
Baştan yazım şu durumlarda daha güçlü aday olabilir:
- Mevcut teknoloji artık güvenli veya desteklenebilir değildir.
- Veri modeli temel iş ihtiyacını karşılamıyor ve düzeltmek sistemi bozuyor.
- İş modeli eski yazılımın varsayımlarından tamamen farklı hale gelmiştir.
- Mevcut sistemde test, loglama ve hata ayıklama neredeyse imkansızdır.
- Yeni ürün, eski sistemin yalnızca küçük bir kısmını devralacaktır.
- Kullanıcı deneyimi ve operasyon akışı baştan tasarlanmak zorundadır.
- Eski yazılımın lisans, hosting veya bağımlılık maliyeti sürdürülemezdir.
Bu kararda önemli nokta şudur: Baştan yazım, “eski kodu beğenmiyoruz” gerekçesiyle değil, eski yapının iş hedefini karşılayamadığı kanıtlandığında seçilmelidir.
Hangi durumlarda yenileme daha doğrudur?
Mevcut yazılım işin büyük bölümünü doğru yapıyorsa, kullanıcılar sistemi aktif kullanıyorsa ve sorunlar belirli modüllerde yoğunlaşıyorsa yenileme daha kontrollü olabilir. Özellikle veri ve iş kuralları değerliyse, bu bilgiyi korumak önemlidir.
Yenileme şu durumlarda daha uygundur:
- Sistemin ana iş akışı çalışıyor ama arayüz veya performans zayıf.
- Belirli modüller sorunlu, tüm sistem değil.
- Veri modeli temizlenebilir ve genişletilebilir durumda.
- Kullanıcılar sisteme alışmış ve ani değişim operasyonu bozabilir.
- Yeni özellikler API, entegrasyon veya modül ekleme ile yapılabilir.
- Bütçe ve süre tek seferlik büyük projeye uygun değildir.
- İş sürekliliği nedeniyle sistemin kapanması kabul edilemez.
Bakım ve destek süreci olan yazılımlarda yenileme daha yönetilebilir hale gelir. Çünkü mevcut hatalar, kullanım verileri ve teknik borç kalemleri düzenli izleniyorsa hangi parçanın önce ele alınacağı daha net görülür.
Veri migrasyonu kararın merkezindedir
Eski yazılımı yenileme veya baştan yazma kararında veri çoğu zaman koddan daha önemlidir. Müşteri kayıtları, sipariş geçmişi, stok hareketleri, cari hesaplar, faturalar, teklifler, kullanıcı yetkileri ve işlem logları yeni sisteme nasıl taşınacak? Hangi veri temizlenecek, hangi veri arşivlenecek, hangi veri aktif kullanılacak?
Baştan yazım projelerinde en çok küçümsenen işlerden biri veri migrasyonudur. Eski sistemde boş alanlar, hatalı formatlar, mükerrer kayıtlar, eski ürün kodları, farklı müşteri tanımları ve manuel girilmiş notlar olabilir. Yeni sistem temiz tasarlanmış olsa bile bu veri yeni modele uymayabilir.
Bu nedenle migrasyon planı ayrı bir iş kalemi olarak ele alınmalıdır. Veri envanteri, dönüşüm kuralları, test aktarımı, kullanıcı kontrolü, geri dönüş planı ve canlı geçiş takvimi olmadan baştan yazım kararı eksik kalır.
Entegrasyonlar gizli bağımlılık oluşturur
Eski yazılımlar genellikle başka sistemlere bağlıdır: muhasebe, CRM, ödeme, kargo, e-posta, SMS, ERP, stok, pazaryeri, raporlama veya iç operasyon araçları. Bu bağlantılar dokümante edilmemişse, yeni sistem tasarlanırken kritik entegrasyonlar gözden kaçabilir.
API entegrasyon hizmeti modernizasyon kararında ayrı analiz gerektirir. Hangi sistem veri gönderiyor, hangisi veri alıyor, hangi işlem zamanlı çalışıyor, hangi alan eşleşiyor, hata durumunda kim müdahale ediyor? Bu sorular netleşmeden eski sistemi kapatmak ciddi operasyon riski doğurur.
| Bağımlılık | Sorulması gereken soru | Risk |
|---|---|---|
| Muhasebe | Fatura, cari ve ödeme verisi nasıl aktarılıyor? | Finansal kayıtlar eksik veya hatalı oluşabilir |
| CRM | Müşteri ve teklif bilgisi hangi sistemde ana kayıt? | Müşteri verisi iki sistemde farklılaşabilir |
| Stok | Stok düşümü siparişin hangi aşamasında yapılıyor? | Stok fazlası veya eksi stok oluşabilir |
| Raporlama | Yönetim hangi metrikleri eski sistemden alıyor? | Yeni sistemde karar verisi eksik kalabilir |
| Kullanıcı yetkileri | Roller ve izinler hangi kurala göre çalışıyor? | Yanlış kullanıcı yanlış veriye erişebilir |
Kullanıcı alışkanlıkları tamamen yok sayılmamalı
Eski yazılım teknik olarak sorunlu olabilir; fakat kullanıcıların iş yapma biçimini yıllardır şekillendirmiştir. Yeni sistem tasarlanırken her eski ekran birebir kopyalanmamalıdır, ama kritik kullanıcı alışkanlıkları da yok sayılmamalıdır.
Örneğin depo personeli ürün kodunu belirli formatta arıyor, satış ekibi müşteri geçmişinde belirli not alanına bakıyor, muhasebe ekibi raporu belirli sırada dışa aktarıyor olabilir. Bunlar küçük detay gibi görünür; fakat günlük operasyon hızını doğrudan etkiler.
Yönetim paneli geliştirme sırasında kullanıcı görüşmeleri, ekran gözlemi ve pilot kullanım yapılırsa yeni sistem eski hataları taşımadan gerçek iş hızını koruyabilir.
Maliyet nasıl değerlendirilmelidir?
Baştan yazım maliyeti yalnızca geliştirme saatinden oluşmaz. Analiz, veri migrasyonu, entegrasyon, test, eğitim, paralel kullanım, canlı geçiş, hata düzeltme, eski sistemin bir süre açık kalması ve operasyonel kesinti ihtimali de maliyetin parçasıdır.
Yenileme maliyeti ise daha küçük fazlara bölünebilir; fakat geçici mimari, ara katman, eski sistemle birlikte çalışma ve teknik borcun bazı parçalarının korunması gibi maliyetleri olabilir. Bu yüzden karşılaştırma yalnızca ilk teklif tutarı üzerinden yapılmamalıdır.
Yazılım maliyetleri değerlendirilirken üç ayrı tablo hazırlanmalıdır: mevcut sistemi koruma maliyeti, fazlı yenileme maliyeti ve baştan yazım maliyeti. Bu üç tablo süre, risk ve iş etkisiyle birlikte okunmalıdır.
Karar vermeden önce teknik analiz yapılmalı
Sağlıklı karar için kısa ama disiplinli bir teknik analiz gerekir. Bu analiz tüm sistemi aylarca incelemek zorunda değildir; ancak karar verecek kadar veri üretmelidir. Kod kalitesi, veritabanı yapısı, entegrasyonlar, güvenlik açıkları, performans darboğazları, kullanıcı şikayetleri ve iş hedefleri birlikte değerlendirilmelidir.
Teknik analiz çıktıları şunları içerebilir:
- Mevcut modül ve kullanıcı akışı haritası
- Veri tabanı ve kritik tablo envanteri
- Entegrasyon ve dış sistem bağımlılıkları
- Güvenlik, performans ve bakım riskleri
- Yenilenebilir modüller ve yeniden yazılması gereken parçalar
- Veri migrasyonu zorlukları
- Fazlı geçiş veya baştan yazım yol haritası
Örnek senaryolar: hangi karar daha mantıklı?
Aşağıdaki örnekler geneldir; her işletmede teknik analiz sonucuna göre değişebilir. Ama karar mantığını göstermek için faydalıdır.
| Durum | Daha olası karar | Gerekçe |
|---|---|---|
| Panel eski görünüyor ama iş akışı çalışıyor | Yenileme | Arayüz ve kullanıcı deneyimi iyileştirilebilir |
| Veri modeli yanlış ve her yeni özellik sistemi bozuyor | Baştan yazım veya kapsamlı yeniden mimari | Temel yapı iş ihtiyacını taşımıyor |
| Tek modül sorunlu, diğerleri çalışıyor | Fazlı yenileme | Riskli modül ayrıştırılarak değiştirilebilir |
| Eski teknoloji güvenlik güncellemesi alamıyor | Öncelikli modernizasyon | Güvenlik ve sürdürülebilirlik riski büyüktür |
| İş modeli tamamen değişti | Yeni ürün tasarımı | Eski sistemin varsayımları yeni operasyonu karşılamaz |
Başlamadan önce kontrol listesi
Eski yazılımı yenileme veya baştan yazma kararından önce aşağıdaki sorular netleşmelidir:
- Mevcut sistemde tam olarak hangi sorunlar var?
- Sorun arayüz, performans, güvenlik, veri modeli veya iş akışı kaynaklı mı?
- Hangi modüller hâlâ iş değerini doğru sağlıyor?
- Hangi iş kuralları dokümante edilmemiş durumda?
- Veri migrasyonu ne kadar karmaşık?
- Hangi entegrasyonlar yeni sistemde devam edecek?
- Kullanıcılar hangi alışkanlıkları kaybetmemeli?
- Fazlı geçiş mümkün mü?
- Eski ve yeni sistem bir süre birlikte çalışacak mı?
- Geri dönüş planı ve test ortamı var mı?
- Kararın maliyet, süre ve operasyon riski karşılaştırıldı mı?
Sonuç: En doğru karar çoğu zaman ikisinin karışımıdır
Eski yazılımı yenilemek mi baştan yazmak mı sorusunun tek cevabı yoktur. Bazı parçalar yenilenir, bazı parçalar korunur, bazı modüller sıfırdan yazılır, bazı işlevler hazır servisle değiştirilir. Önemli olan kararı teknik moda, kişisel tercih veya aceleci yorumla değil; iş hedefi, risk, veri, kullanıcı ve maliyet analiziyle vermektir.
Webioo, eski yazılım modernizasyonu projelerinde önce mevcut sistemi analiz eder; ardından yenileme, fazlı geçiş, yeniden mimari veya baştan yazım seçeneklerini karşılaştırır. Böylece işletme, çalışan sistem bilgisini kaybetmeden daha sürdürülebilir ve geliştirilebilir bir yazılım yol haritası çıkarabilir.
Sıkça Sorulan Sorular
Eski yazılımı baştan yazmak her zaman daha mı iyidir?
Hayır. Baştan yazmak bazı durumlarda gerekli olabilir; ancak çalışan sistemde yıllarca biriken iş kuralları, hata düzeltmeleri ve kullanıcı alışkanlıkları kaybolabilir. Mevcut sistem parça parça iyileştirilebiliyorsa fazlı yenileme çoğu zaman daha düşük risklidir.
Ne zaman baştan yazım düşünülmeli?
Mevcut teknoloji desteklenmiyorsa, veri modeli temel iş akışını yanlış temsil ediyorsa, güvenlik riski yüksekse, sistem küçük değişikliklerde bile bozuluyorsa veya iş modeli eski yazılımın varsayımlarından tamamen farklı hale geldiyse baştan yazım düşünülebilir.
Fazlı yenileme nedir?
Fazlı yenileme, eski yazılımın tamamını tek seferde değiştirmek yerine modül modül modernize edilmesidir. Önce düşük riskli veya yüksek değerli parçalar yenilenir, yeni sistem eski sistemle bir süre birlikte çalışır ve bağımlılıklar azaldıkça eski parçalar devreden çıkarılır.
Veri migrasyonu neden bu kadar önemlidir?
Çünkü yeni sistemin doğru çalışması için müşteri, sipariş, stok, cari hesap, kullanıcı ve işlem geçmişi gibi verilerin doğru taşınması gerekir. Eski veride mükerrer kayıt, eksik alan veya hatalı format varsa bu sorunlar yeni sisteme taşınmadan önce temizlenmelidir.
Eski yazılım yenilenirken kullanıcılar etkilenir mi?
Etkilenebilir. Bu nedenle kullanıcı alışkanlıkları, kritik ekranlar, eğitim ihtiyacı ve geçiş planı baştan düşünülmelidir. Fazlı geçiş ve pilot kullanım, operasyon kesintisini azaltmaya yardımcı olur.
Karar vermeden önce hangi analiz yapılmalı?
Kod yapısı, veritabanı, entegrasyonlar, performans, güvenlik, kullanıcı akışları, teknik borç, veri migrasyonu ve maliyet karşılaştırması incelenmelidir. Bu analiz sonucunda yenileme, fazlı geçiş, yeniden mimari veya baştan yazım seçenekleri daha sağlıklı karşılaştırılır.
