Uygulama modernizasyonu nedir, ne zaman gerekir?
Uygulama modernizasyonu, mevcut yazılımı işin bugünkü ihtiyaçlarına, desteklenen teknolojiye ve güvenilir işletim koşullarına uyarlamaktır. Kodun yaşını azaltmak tek başına hedef değildir. Sürüm çıkarmak üç hafta sürüyorsa, desteği biten veritabanı sürekliliği tehdit ediyorsa veya yoğun saatte müşteriler işlemi tamamlayamıyorsa somut bir modernizasyon gerekçesi vardır. Her sorun için başlangıç değeri ve kabul edilecek sonuç yazılmalıdır. Önemli bir sonuç değişmeyecekse uygulamayı koruyup riskini azaltmak yakın vadede uygun olabilir.
Buluta taşınma ile uygulamayı iyileştirme aynı karar değildir. AWS yedi geçiş stratejisi tanımlar; koruma, kaldırma, yeniden barındırma, platform değiştirme ve refaktör bunlar arasındadır. Microsoft'un modernizasyon planı platform değiştirme, refaktör ve mimariyi yeniden kurmayı ayırır. Farklı rehberlerde aynı terim daha geniş veya dar kullanılabilir. Ekibinizde tanımı yazın; bir etiket maliyetlendirilmiş planın yerine geçmemelidir.
Bir portföyün tamamına tek strateji seçmek zorunda değilsiniz. Sipariş defterini koruyabilir, barındırmayı değiştirebilir, fiyatlandırma kodunu iyileştirebilir ve kullanılmayan bir raporu kaldırabilirsiniz. Yeniden yazım da seçenekler arasındadır; ancak iş davranışı, veri taşıma ve kullanıcı eğitimi yüküyle değerlendirilmelidir. Hangi müdahalenin ölçülen kısıtı azalttığı, kullanılan teknolojiden daha güçlü karar ölçütüdür.
Koru, platform değiştir, refaktör et veya yeniden yaz?
Aşağıdaki karar matrisi uygulama parçası bazında kullanılır. Önce iş ihtiyacının hâlâ geçerli olup olmadığını, sonra kod ve işletim kısıtlarını değerlendirin. Bir seçenek seçerken destek süresini, değişim maliyetini, veri bağımlılığını ve geri dönüş yolunu birlikte kaydedin. “Koru” kararı unutma anlamına gelmez; inceleme tarihi ve sorumlusu bulunmalıdır.
| Seçenek | Uygun durum | Temel kontrol |
|---|---|---|
| Koru | Destekli sistem ihtiyacı karşılıyor | Sorumlu ve yeniden inceleme tarihi |
| Platform değiştir | İşletim yükü temel sorun | Uyumluluk ve kapasite testi |
| Refaktör et | Davranış değerli, kod değişimi zor | Mevcut davranışı koruyan testler |
| Yeniden yaz veya değiştir | İş akışı hedefe artık uymuyor | Veri ve özellik eşdeğerliği |
| Kullanımdan kaldır | İşlev kullanılmıyor, bağımlılığı yok | Çağıranlar ve veri saklama kontrolü |
Yeniden barındırma, uygulamayı büyük davranış değişikliği yapmadan farklı altyapıya taşır. Platform değişimi işletim biçimini değiştirir; örneğin yönetilen veritabanına geçiş olabilir. Refaktör mevcut davranışı koruyarak kod yapısını iyileştirir. Mimariyi yeniden kurmak sınırları ve iletişimi değiştirir; tamamen yeniden yazmakla aynı şey değildir. Hazır bir ürünle değiştirme de değerlendirilebilir, fakat kimlik, entegrasyon ve veri taşıma yükü yine hesaba katılmalıdır. Bu ayrımları teklif ve kabul kapsamına açıkça yazın.
Modernizasyon planı nasıl hazırlanır?
İlk çıktı uygulama envanteri ve bağımlılık haritasıdır. Veritabanları, kimlik sağlayıcısı, dosya aktarımları, tedarikçiler, mobil istemciler, toplu işler ve belgelenmemiş elle yapılan işlemler dahil olsun. Her bileşen için iş sahibi, teknik sorumlu, kullanıcı grubu, çalışma zamanı, sürüm, destek durumu, veri sahibi ve çağıranları kaydedin. “Bu rapor kullanılmıyor” gibi varsayımları kullanıcıyla ve trafik kaydıyla doğrulayın; ay sonunda çalışan bir iş günlük gözlemde görünmeyebilir.
Ardından başlangıç ölçümlerini toplayın. İş tarafında aksayan görevi, sıklığını ve gecikmenin etkisini yazın. Teslim tarafında sürüm hazırlama süresi, değişiklik kaynaklı hata ve hizmeti geri getirme süresi; işletimde yoğun saat gecikmesi, erişilebilirlik, destek olayı ve altyapı maliyeti bulunsun. Farklı dönemlerin değerlerini rastgele karşılaştırmayın. Veri miktarı, saklama ihtiyacı, doğrulama kuralları ve taşınacak tarihsel kayıtlar da kapsamı belirler.
Her aday bileşen için karar kaydı oluşturun: seçilen yol, alternatifler, gerekçe, ön koşullar, kabul ölçütü, tahmini emek ve belirsizlik. Maliyete kod yazmanın yanında keşif, veri temizleme, paralel işletim, eğitim, test, geçiş desteği ve eski ortamın kaldırılması girsin. Veri veya bağımlılık bilinmiyorsa bütün dönüşümü kesin fiyatlandırmak yerine sınırlı ölçüm çalışması planlayın. Sağlam bir başlangıç değeri olmadan yüzde tasarruf veya hız sözü vermeyin.
İlk aşamada küçük ve anlamlı bir iş sınırı seçin: tek rapor, API ya da müşteri akışı. Ön koşulları önce çözün; kırılgan sistemde geçişten önce yerinde iyileştirme gerekebilir. Başlangıçta hedef kapsamı sabitleyin ve yeni özellikleri ayrı değerlendirin. Aksi hâlde aynı anda davranış değişimi, veri taşıma ve altyapı dönüşümü yapılarak hatanın nedeni belirsizleşir. Bir parçanın sonucu, sonraki parçanın planını güncellemelidir.
Geri alınabilir geçiş ve veri mutabakatı
Kabul testlerini teknoloji adları yerine iş örnekleriyle tanımlayın: eski siparişi düzeltme, iade sonrası toplam, yetkisiz rapor isteği ve yarım kalmış işlem. İşlevleri aşamalı taşıma için Microsoft'un Strangler Fig deseni ortak giriş noktasından eski ve yeni uygulamaya yönlendirme sunar. Bu desen, eski sistemin önüne bir yönlendirme katmanı konabilmesine ve işlevlerin net sınırlarla ayrılabilmesine bağlıdır. Geçiş yöntemi seçilirken iki ortamın birlikte işletim maliyeti de görünür olmalıdır.
Her aşamada kimin durdurma yetkisi olduğunu, hangi sinyalin geri dönüş başlatacağını ve işlem sırasında oluşan verinin nasıl ele alınacağını yazın. Trafiği eskiye çevirmek, yeni şemaya yazılmış kaydı otomatik dönüştürmez. Kaydın hangi sistemde tek yetkili kaynak olduğunu ve veri eşitleme yolunu belirleyin. Paralel çalışmada aynı girdileri karşılaştırın, bilinçli farkları onaylayın ve anlaşmazlığı kimin çözeceğini belirtin. Yedek alınması kadar geri yükleme süresinin ve sonucun sınanması da gerekir.
Varsayımsal örnek: dağıtıcının sipariş portalı
Örneğin 120 çalışanın kullandığı bir portal günde 3.000 sipariş işlesin. Yeni fiyat kuralının teslimi 15 iş günü sürsün; yoğun rapor saatinde ödeme p95 gecikmesi 2,4 saniyeye çıksın. Aylık altyapı ve bakım bütçesi 90.000 TL olsun. Bir yıldır kullanılmadığı düşünülen elektronik tablo dışa aktarımı da bulunsun. Bütün rakamlar varsayımsaldır; amaç müdahaleleri aynı iş sorunu üzerinden karşılaştırmaktır.
Envanter, sipariş defterinin iş ihtiyacını karşıladığını ancak fiyat kodunun ortak sürüm gerektirdiğini göstersin. İlk plan defteri süreli olarak korumak, fiyatlandırmayı testli arayüz arkasında refaktör etmek, raporları ayrı okuma yoluna taşımak ve dışa aktarımı kullanıcılarla doğruladıktan sonra kaldırmaktır. Yeni ödeme arayüzü daha sonraki bir aşamaya bırakılır. Böylece bütün portalın yeniden yazılması yerine her parçaya ayrı gerekçe ve geri dönüş sınırı verilir.
Altı haftalık pilotta hedef, fiyat değişikliği teslimini beş iş gününe indirmek ve rapor saatinde ödeme p95 gecikmesini 1,5 saniyenin altında tutmak olsun. Sipariş ve ödeme tutarlarında açıklanamayan fark kabul edilmesin. Geçici ikinci ortam aylık 12.000 TL ek maliyet getiriyorsa bu bütçede açıkça gösterilir; 90.000 TL ile karşılaştırılıp hemen tasarruf iddia edilmez. Pilot sonunda sonuç ve bakım yükü birlikte değerlendirilir. Hedef tutmazsa bütün yeniden yazımı başlatmak yerine ilk kısıt ve yaklaşım yeniden incelenir.
Modernizasyonun test ve ölçüm planı
- Davranış: Temsilî kullanıcı görevlerini eski ve yeni yolda çalıştırın; tarihsel kayıt, iptal ve uç durumların beklenen sonucunu iş sahibine doğrulatın.
- Veri: Kayıt sayısını, kimlikleri, tutarları ve durumları uzlaştırın; yalnızca taşınan dosyanın tamamlanmasına bakmayın. Çözülmemiş farkları canlıya geçiş onay koşuluna ekleyin.
- Yetki: Aynı görevleri farklı rollerle sınayın; yeni platform veya arayüz daha geniş veri erişimi vermemelidir.
- Yük: Normal trafik, yoğun rapor saati ve toplu iş çalışmasını ölçün. p95 gecikmesi ve hata oranını eşdeğer dönemdeki başlangıç ölçümüyle karşılaştırın.
- Geri dönüş: Uygulama, yapılandırma ve veri adımlarını birlikte deneyin; sorumluyu, gereken süreyi ve dönüş sonrası kontrolü kaydedin.
- İş sonucu: İlk aşamadan sonra teslim süresi, destek olayı ve toplam bakım maliyetini inceleyin; ikinci aşamayı ölçülen sonuca göre onaylayın.
Sık yapılan hatalar
- Kod eski olduğu için bütün uygulamaya tek yeniden yazım kararı vermek.
- Buluta taşınmayı iş akışının kendiliğinden iyileşeceği bir sonuç saymak.
- Belgelenmemiş kuralları, aylık görevleri ve elle yapılan düzeltmeleri envanterden çıkarmak.
- Test, veri temizliği, eğitim ve paralel işletim giderlerini tahminde atlamak.
- Koruma kararına inceleme tarihi koymamak; kaldırılacak parçanın çağıranlarını doğrulamamak.
Hatson Tech bunu nasıl kuruyor?
Özel yazılım geliştirme çalışmalarında uygulama envanteri, iş kısıtı ve başlangıç ölçümleriyle keşfe başlıyoruz; bileşen kararlarını kabul testleri ve geçiş planıyla somutlaştırıyoruz. Ayrı servis ihtiyacını monoliti ne zaman servislere ayırmalı rehberindeki sınır alıştırmasıyla, seçilen işlevin taşınmasını kademeli eski sistem geçiş planıyla değerlendirebilirsiniz. En sık aksayan kullanıcı görevini, mevcut bağımlılıkları ve bir ölçümü paylaşmanız, hangi müdahalenin önce denenmesi gerektiğini belirlemeyi kolaylaştırır.