Eski bir yazılım sistemini devralmadan önce kontrol edilmesi gerekenler

Eski bir yazılım sistemini devralırken ilk yapılacak iş bütün kodu okumak veya hemen yeni teknoloji önermek değildir. Önce şirketin istediği sonucu, değişikliğin dokunacağı alanı ve hata halinde geri dönüş yolunu anlamak gerekir. İncelemenin derinliği de buna göre belirlenmelidir.

Tek bir rapor düzeltmesiyle yıllarca geliştirilecek yeni bir modül aynı hazırlığı gerektirmez. Her projeye eksiksiz bir “ideal altyapı” listesi uygulamak güvenli görünür, fakat gereksiz maliyet ve gecikme de üretebilir.

Bu kontrol listesi, çalışan eski bir sistemi bozmadan geliştirmek için hangi soruların hangi sırayla sorulacağını anlatıyor.

1. Önce teknolojiyi değil, talebi tanımlayın

“Sistem eski” bir problem tanımı değildir. Şirketin yaşadığı somut sıkıntıyı bulmak gerekir:

• Bir entegrasyon mu eklenecek?
• Bir rapor yanlış mı hesaplanıyor?
• Mevcut sistem sık sık mı duruyor?
• Aylar boyunca yeni modüller mi geliştirilecek?
• Sistemi yazan kişi artık destek vermiyor mu?

İstenen şey sınırları belirli küçük bir değişiklikse inceleme de önce o değişikliğin etki alanına odaklanabilir. Sistemin tamamına güvenlik denetimi yapmak, her bağımlılığı güncellemek ve yapıyı konteynerlere taşımak bu iş için gerekli olmayabilir.

Uzun süreli geliştirme planlanıyorsa tablo değişir. O zaman kodun yerelde veya ayrı bir sunucuda çalıştırılması, test verisi, yayın süreci ve geri alma yöntemi gerçek ihtiyaç haline gelir.

2. Çalışan sistemi “eski” etiketiyle değersizleştirmeyin

Uzun süredir kullanılan yazılım yalnız kaynak koddan oluşmaz. İçinde yıllar boyunca birikmiş iş kuralları, istisnalar, raporlar ve başka sistemlerle kurulmuş bağlantılar bulunur.

Bir sistemi sıfırdan yazma tahmini yapılırken çoğu zaman yalnız görünen ekranlar sayılır. Asıl süreyi büyüten parçalar şunlardır:

• geçmiş verinin taşınması ve doğrulanması,
• raporların eski sonuçlarla karşılaştırılması,
• ERP, muhasebe ve ödeme bağlantıları,
• arka planda çalışan zamanlanmış görevler,
• kullanıcıların alıştığı ancak yazılı olmayan iş akışları,
• kabul testleri ve canlı geçiş planı.

Yeni yazılımın kodunun tamamlanması, eski sistemin yerini almaya hazır olduğu anlamına gelmez.

3. Yedek var mı, geri dönüş gerçekten mümkün mü?

Canlı sistemde değişiklik yapılacaksa “yedek alınıyor” cevabı tek başına yeterli değildir. En azından şu soruların yanıtı bilinmelidir:

1. Veritabanı yedeği en son ne zaman başarıyla oluştu?
2. Yedek başka bir makinede veya depolama alanında tutuluyor mu?
3. Dosyalar ile veritabanı birlikte geri döndürülebiliyor mu?
4. Bir önceki çalışan kod sürümüne nasıl dönülüyor?
5. Geri yükleme daha önce denendi mi?

Her küçük iş için kapsamlı felaket tatbikatı gerekmez. Fakat geri dönüş yolunu bilmeden canlı veriyi değiştirmek gereksiz bir risktir.

4. Sistemi yalnız web sayfalarından ibaret sanmayın

Eski uygulamaların önemli işleri çoğu zaman tarayıcıda görünmez. Windows Task Scheduler, cron, kuyruk işlemleri, dosya aktarımları veya başka programların çağırdığı adresler sistemi sürekli tetikliyor olabilir.

Bir değişiklikten önce şu bağımlılıklar araştırılmalıdır:

• zamanlanmış görevler,
• ERP ve muhasebe bağlantıları,
• tedarikçi ve pazaryeri veri akışları,
• e-posta, SMS, kargo ve ödeme servisleri,
• başka sunuculara bırakılan veya alınan dosyalar,
• IP adresine veya alan adına bağlı dış sistemler.

Kod içinde kullanılmıyor görünen bir adres, geceleri çalışan bir aktarımın tek giriş noktası olabilir.

5. Hata kayıtlarına ve sunucuya talebin gerektirdiği kadar bakın

Hata kayıtları, kaynak kodu okumadan önce sistemin nerede zorlandığını gösterebilir. Sunucu kaynakları, veritabanı bağlantıları ve son hatalar özellikle performans veya kesinti şikâyetinde değerlidir.

Ancak yalnızca bir alan ekleme talebiyle gelen şirkete kendiliğinden kapsamlı altyapı denetimi satmaya çalışmak doğru değildir. Teknik incelemenin kapsamı, talebin riskiyle orantılı olmalıdır.

Pratik bir ayrım şöyle yapılabilir:

Talep	İlk inceleme odağı
Küçük, sınırları belli düzeltme	İlgili kod, veri, geri dönüş yolu
Yeni entegrasyon	Veri formatı, kimlik doğrulama, zamanlanmış işler, hata kaydı
Sürekli yeni özellik geliştirme	Yerel/test ortamı, sürüm yönetimi, yayın ve yedek düzeni
Performans veya kesinti	Sunucu, veritabanı, loglar, darboğaz ve izleme
Tam modernizasyon	Tüm bağımlılıklar, veri geçişi, kabul testleri ve aşamalı geçiş

6. Test ortamını amaç haline getirmeyin

Eski sistemlerin çoğu yeni bir geliştiricinin bilgisayarında tek komutla çalışmaz. Eksik bağımlılıklar, eski sunucu ayarları veya yalnız canlı ortamda bulunan bağlantılar olabilir.

Bir saatlik düzeltme için bütün sistemi Docker’a taşımak ve eksiksiz yerel ortam kurmak bazen düzeltmenin kendisinden kat kat uzun sürer. Bu, teknik olarak güzel fakat ticari olarak anlamsız bir sonuç olabilir.

Öte yandan sistem üzerinde aylarca çalışılacaksa her değişikliği canlıda denemek kabul edilemez hale gelir. Bu durumda test ortamı, örnek veri ve tekrarlanabilir yayın süreci ilk yatırımlardan biri olmalıdır.

Doğru soru “Test ortamı olmalı mı?” değil, “Planlanan işin riski ve devam süresi bu yatırımı ne zaman gerekli kılıyor?” sorusudur.

7. Gerçek örnek: 2007’den beri çalışan Classic ASP sistemi

Devraldığım B2B satış sistemi Classic ASP ve MySQL kullanıyordu. Netsis ERP ile tam entegreydi, yıllardır sipariş alıyordu ve şirketin kullandığı çok sayıda raporu barındırıyordu.

İstenen değişiklik, tedarikçilerin stoklarını JSON üzerinden sisteme almaktı. Microsoft’un Classic ASP belgelerinde platformun sunucu tarafında VBScript veya JScript çalıştırdığı ve ek kabiliyetlerin COM bileşenleriyle kullanılabildiği görülür. Classic ASP/VBScript’in yerleşik JSON ayrıştırıcısı bulunmadığından hazır bir ayrıştırıcı veya özel bir COM/.NET bileşeni kullanmak gerekiyordu. Bu nedenle entegrasyon güncel bir teknolojiye göre daha zahmetliydi.

Yine de yalnız bu entegrasyon zor diye bütün sistemi yeniden yazmak mantıklı değildi. Yılların raporlarını, Netsis akışlarını ve gerçek kullanım davranışını yeniden üretmek çok daha büyük bir işti.

Entegrasyon tamamlandığında firma kendi deposunda bulunmayan fakat tedarikçide bulunan ürünleri de stokta gösterebildi. Böylece önceden satın alıp sermaye bağlamadığı ürünleri satışa açtı. Çalışan B2B sistemi ve ERP bağlantısı korunmuş oldu.

Classic ASP’nin çalışma modeli için Microsoft’un resmi IIS belgesine, ASP içinde bileşen kullanımına ilişkin ayrıntılar için de Windows Script Components belgesine bakılabilir.

8. Yeniden yazma kararını nasıl hesaplamak gerekir?

Yeniden yazma kararı zor olmaktan çok, acele verilmemesi gereken bir karardır.

Örneğin yeni bir modülün:

• güncel bir sistemde geliştirilmesi bir hafta,
• mevcut eski sistemde geliştirilmesi bir ay,
• mevcut sistemin gerçekten eşdeğer biçimde yeniden kurulması iki hafta

sürüyorsa yeniden yazmak değerlendirilebilir. Bugünkü modülde kazanılan süre, gelecek geliştirmelerde de kazanılacaktır.

Fakat üçüncü tahmin çoğu projede gerçekçi değildir. Yıllardır yaşayan bir sistemi iki haftada yeniden yazmak mümkün görünse bile kabul testleri, veri karşılaştırmaları ve kullanıcı geçişi aylar sürebilir.

Kararda şu toplam karşılaştırılmalıdır:

Mevcut sistemi geliştirme maliyeti ile yeniden geliştirme + veri taşıma + entegrasyonları kurma + test + geçiş riskinin maliyeti.

Yeni teknoloji kullanmak tek başına iş sonucu değildir. Yeniden yazma kararı sırf daha büyük proje ve daha yüksek fatura çıkarmak için verilirse iki taraf da zarar görür.

9. Devralma sonunda ne teslim edilmelidir?

Her devralma çalışmasının sonunda aynı tür rapor çıkmaz. Şirketin ihtiyacına göre sonuç şunlardan biri veya birkaçı olabilir:

• canlıya alınmış bir entegrasyon,
• hatası giderilmiş mevcut sistem,
• test ve yayın ortamı,
• sağlam yedekleme ve izleme düzeni,
• modernizasyon yol haritası,
• aşamalı olarak yenilenen bir modül,
• çalışır halde teslim edilen yeni portal veya iç sistem.

Ben bu çalışmaları tek seferlik proje olarak değil, aylık sabit saatli hizmet içinde yürütüyorum. İlk görüşme ücretsiz; anlaşmadan sonraki inceleme, planlama, geliştirme ve yönetim aynı saat sayacının parçası.

Sisteminiz çalışıyor ancak geliştirmek zorlaşıyorsa eski sistem devralma ve modernizasyon hizmetinin ayrıntılarını inceleyebilir veya ücretsiz tanışma görüşmesi talep edebilirsiniz.