Yazılım modernizasyonu: yeniden yazmak mı, kademeli mi? Yedi soruluk karar testi

Yazılım modernizasyonunda "yeniden yaz mı?" iki ayrı karardır

Yıllardır çalışan bir sistemin sahibi ya da BT sorumlusuysanız, çoğu zaman tek soruymuş gibi sorulan iki sorunuz vardır. Birincisi: bu sisteme dokunmak gerekiyor mu? İkincisi: dokunulacaksa baştan mı yazılmalı, yoksa parça parça mı değiştirilmeli? Birincisi bir denetim sorusudur; yarım kalmış yazılım projesi nasıl devralınır yazısındaki komutlar, 0–2 puanlı matris ve rapor iskeleti ona yanıt verir ve burada yinelenmez. Bu yazı ikincisini ele alır: yazılım modernizasyonunda yönü seçilmiş bir sistem nasıl dilimlenir ve nasıl devreye alınır. Bir özel yazılım geliştirme teklifi istemeden önce kendi yanıtınızı bilmek, teklifleri okumanızı kolaylaştırır.

İki uç görüş bellidir ve yarım kalmış proje yazısında denetim sonucuna bağlanarak kısaca anlatılmıştır; burada yalnızca bu yazının dayandığı noktayı alıyoruz. Joel Spolsky 2000'de çalışan kodu baştan yazmayı bir yazılım şirketinin yapabileceği en büyük stratejik hata saydı (Spolsky). Martin Fowler ise eski sistemin ne yaptığı bilindiği için aynısını yeni ve daha iyi bir teknolojiyle kurma planının, basit görünmesine rağmen çoğu zaman alev alarak battığını yazar (Fowler). Ama kademeli geçişin her sistemde mümkün olduğunu ikisi de söylemez; Microsoft'un belgesi onun uygun olmayabileceği durumları açıkça sayar. Bu yüzden yön seçimini bir test olarak yazmak mümkündür: yedi soru, her birinin dayanağıyla.

Değerlendirme, yol haritası ve yeniden kurulum işlerini nasıl yürüttüğümüzü yazılım danışmanlığı ve modernizasyon sayfamızda anlattık.

Dört yol, tek tablo

Önce seçenekleri adlandıralım. Hücredeki kaynak adı, ifadenin dayandığı sayfayı gösterir; "çıkarım" ya da "yargı" yazan hücreler kaynağın yazdığının ötesine geçen, bizim mühendislik yargımızdır, standart değildir.

Hangi yolun toplam maliyeti nasıl çıkar sorusu ayrı bir sorudur; maliyet kalemlerini nasıl çıkaracağınızı hazır yazılım mı, özel yazılım mı: toplam sahip olma maliyeti yazısındaki çalışma sayfasında bulabilirsiniz; o sayfa hazır ve özel yazılım karşılaştırması için yazılmıştır, bir modernizasyona uyarlamak size kalır.

Karar testi: yedi soru

Soruları kendi sisteminiz için "evet", "hayır" ya da "bilmiyorum" diye yanıtlayın. "Bilmiyorum" da bir sonuçtur: yanıtı bulmak, geçişin ilk işi olur.

"Dayanak" sütunu her sorunun hangi sayfadan geldiğini gösterir; "Evet ise" ve "Hayır ise" sütunlarındaki sonuçlar bizim çıkarımımızdır. İlk dört soru, kademeli geçişin uygun olmayabileceği durumları sıralayan Microsoft Learn belgesinden gelir. Beşinci soru Fowler'ın gözlemine dayanır: iyi ayrışmış sistemler nadirdir, ayrışmaları genellikle sonradan siz sağlarsınız. Altıncı soru, ilk dördünün aksine Microsoft Learn belgesinden gelmez; Thoughtworks ekibinin ve karakterizasyon testi yaklaşımının dayandığı bir gözleme, yani bugünkü davranışın yazılı olup olmadığına dayanır. Thoughtworks ekibi (Cartwright, Horn, Lewis), eski davranışı birebir yeniden üretmeyi hedefleyen planlarda mevcut davranışı tanımlamanın ve üzerinde anlaşmanın bile büyük bir iş olduğunu ve bunun tek bir büyük kesime yol açtığını yazar (Patterns of Legacy Displacement). Testsiz kodun davranışını önce olduğu gibi kaydetmek için karakterizasyon testleri kullanılır; denetim tarafı için yine yarım kalmış proje yazısına bakın. Yedinci soru bizim yargımızdır; aynı kaynak, uzun bir programın başında kabul edilen gereksinimlerle iş ihtiyacı arasındaki farkın zamanla açıldığını da anlatır.

Şimdi yanıtları yöne çevirelim. Tabloyu yukarıdan aşağı okuyun; ilk uyan satır yönü verir, son iki satır yöne eklenen koşuldur. Bu sıralama bizim mühendislik yargımızdır, bir standart değildir.

Varsayımsal bir okuma örneği: yanıtlarınız 1 evet, 2 evet, 3 hayır, 4 hayır, 5 hayır, 6 hayır, 7 evet olsun. "1 ya da 5 hayır, 2 evet" satırı uyar: önce iç iyileştirmeyle sınır açılır, sonra kademeli geçiş. Altıncı soruya hayır dediğiniz için bu işin ilk adımı davranışı sabitlemektir; yedinci soruya evet dediğiniz için de sınır açıldıktan sonra tek bir büyük kesim yerine ayrı hedefli dilimler planlarsınız. Gerçek bir sistemde yanıtların bir kısmı "bilmiyorum" çıkar; o sorunun yanıtını bulmak ilk iş olur.

İlk dilimi seçmek

Thoughtworks ekibi dilimlemeyi, mevcut çözümün iş yeteneklerine nasıl karşılık geldiğini görmekle başlatır: büyük bir teknik çözümün birden çok ihtiyacı karşıladığı yerde bir ihtiyacı ayırıp bağımsız teslim etmek mümkün mü diye bakılır ve parçaların birbirine en az bağımlı olması istenir. Microsoft Learn ise getirisi yüksek değişimlerin düşük getirililerden önce yapılabileceğini belirtir. İki fikri birleştiren ölçüt tablosu, bizim yargımızdır:

Dilimlemenin başka bir yüzü, neyi değiştireceğinizi ölçmektir. Düşük gecikmeli canlı piyasa verisi motoru yazısında anlatılan sistemde yük, sentetik üretim yerine gerçek bağlantı izlerinin yeniden oynatılmasıyla üretildi; sorunun kaynakları ölçümle bulundu ve ardından yazıda "dört parça" olarak anlatılan yeniden yazım, ölçümün gösterdiği yayın (fan-out) katmanına odaklandı. Bu yeni yapılmış bir sistemdir, eski bir sistemin göçü değildir; yazının rakamlarını burada tekrarlamıyoruz. Ödünç aldığımız ilke şu: tüm sistemi değil, ölçümün gösterdiği yeri parça parça değiştirin.

Veri: en zor kısım

Kodu dilimlemek görece kolaydır, veriyi dilimlemek değil. Dört kural işi yönetilebilir tutar.

Genişlet, taşı, daralt. Danilo Sato'nun Parallel Change deseni, geriye dönük uyumsuz bir değişikliği üç aşamaya böler: önce eski ve yeni biçimi birlikte destekleyecek şekilde genişletirsiniz, sonra tüketicileri tek tek yeniye taşırsınız, en son eskiyi kaldırırsınız (Sato). Şemaya uyarlaması bize aittir: önce yeni sütunu ya da tabloyu ekleyin ve eskisine dokunmayın; okuyan ve yazan her bileşeni yeniye taşıyın; hiçbir tüketici kalmayınca eskiyi kaldırın.

Ortak veri ve tek yazıcı. Microsoft Learn, hem eski hem yeni sistemin kullanabileceği veri depolarının nasıl yönetileceğini önceden düşünmenizi ve iki sistemin bu kaynaklara aynı anda erişebildiğinden emin olmanızı ister. Eski ve yeni sistem aynı kayda yazıyorsa çift yazma tutarlılık sorunu doğurur; bizim yargımız, her veri için tek yazıcı belirlemektir.

Çeviri katmanı. Geçiş boyunca iki sistem birbirini çağırır. Microsoft Learn bu çağrıları çevirmek için anti-corruption layer (çeviri katmanı) önerir: yeni sistemin tasarımını eskinin kavramlarından korur; katman yoksa yeni sistem eskinin kurallarını miras almak zorunda kalabilir.

Çıkarma, eşzamanlama, doğrulama. Microsoft Learn'ün veritabanı örneğinde ilgili tablolar önce yeni bir alan veritabanına ETL ile yüklenir, değişiklik veri yakalama (CDC) ile eşzamanlı tutulur ve kesimden önce iki veritabanı arasındaki tutarlılık doğrulanır. Eski veritabanına dönüş, eski nesneler ve eşzamanlama süreçleri duruyorken mümkündür; bunlar silindikten sonra dönüş, nesneleri geri kurmayı ve değişiklikleri yeniden oynatmayı gerektirir ve çaba ile riski önemli ölçüde artırır. Belge bu yüzden eski nesnelerin kaldırılmasını, yeni sistem doğrulandıktan sonra atılan bilinçli bir son adım olarak ele almayı söyler. Bir ürün önermiyoruz; ilke araçtan bağımsızdır.

Tutarlılığı sık ve ucuz kontrol etmek için eski ve yeni arasında sayım ve özet kıyası (kayıt sayıları, toplamlar) yeterlidir. Piyasa verisi yazısında uzun süren bir dayanıklılık testi sırasında ucuz bir tutarlılık kontrolü, bir sızıntıyı bellek alarmına dönüşmeden çok önce ortaya çıkardı; yine bir göç değil, aynı ilkenin örneği.

Kesim ve geri dönüş

Kesim, yeni dilimin gerçek kullanıcıya açıldığı andır. Thoughtworks yazısı kesim stratejilerini adlandırır; aşağıda dördü, bizim okuma notumuzla ve geri dönüş sütunuyla yan yana.

Hangi yöntemi seçerseniz seçin, geri dönüş ölçütü kesimden önce yazılır: hangi gösterge bozulursa, kim karar verir, nereye dönülür. Ölçüt yazılmadan kesime girmek, karar anında tartışma yaratır. Thoughtworks, Divert the Flow bağlamında paralel çalıştırmayı bir süre açık bırakmayı ve eski ile yeni uygulama fazla ayrışırsa uyarı üretmeyi ek güvenlik önlemi olarak anlatır; eski ile yeniyi yan yana çalıştırıp karşılaştırmanın yolu budur. Gerçek davranışı yeniden oynatarak ölçmenin işe yaradığını piyasa verisi yazısı da gösterir.

Geçiş için kurulan ara mimari geçicidir. Fowler, bunun için kurulan kodun modernizasyon bitince gideceğini ve riskin azalmasının bu maliyeti aştığını yazar; Microsoft Learn ise cephenin tek hata noktası ya da darboğaz olmaması gerektiğini, bittiğinde genellikle kaldırıldığını ya da eski istemciler için bir bağdaştırıcı olarak tutulabileceğini belirtir. Bu yüzden her dilimin planında bir kapanış satırı olur: hangi koşul gerçekleşince ara mimari sökülür.

Geçiş dilimi planı şablonu

Aşağıdaki iki tabloyu kopyalayıp her dilim için her tabloda aynı dilim adıyla bir satır doldurun. Boş hücre bir sorudur; doldurulamayan hücre, dilimin hazır olmadığını gösterir. Dilim adlarını ve sırayı siz belirleyin.

Birinci tablo dilimin ne olduğunu ve neye dayandığını yazar.

İkinci tablo dilimin nasıl devreye alınacağını ve nasıl kapatılacağını yazar.

Kullanım: önce birinci tablodaki sınır ve veri sütunlarını doldurun, çünkü ikisi de ilk dilimin seçimini belirler. Eski davranışın kanıtı boşsa dilim planda "bilinmiyor" durumunda kalır ve önce sabitleme işi yapılır. Kabul ölçütü, dilimin eski davranışa karşı nasıl onaylanacağını yazılı söyler; bu satırın bir teklifte nasıl yazılacağını yazılım teklifi nasıl okunur yazısındaki kapsam belgesi şablonunun "teslimatlar ve kabul ölçütleri" maddesi gösterir; dilim başına bir satır olarak uygulayın. Her dilimden sonra kapanış satırını güncelleyin.

Üçüncü tablo, kesim öncesi kontrol tablosu, kesimden hemen önce doldurulur. Satırlar bizim çerçevemizdir; sayı ya da süre içermez.

Yeniden yazmanın doğru olduğu durumlar

Eski yazılımı yeniden yazmak kötü değildir; plansız ve büyük patlamalı yeniden yazmak risklidir. Microsoft Learn, küçük bir sistemi değiştirmek basitse kademeli geçişin uygun olmayabileceğini yazar; bu durumda yeniden yazma makul olabilir (bizim çıkarımımız): davranışı net, dış bağımlılığı az, sahibi belli bir sistem. Spolsky'nin yazısı da aynı ayrımı yapar: bir fonksiyonu atmak ya da bir sınıfı yeniden düzenlemek sorun değildir, tüm programı atmak tehlikelidir. Portfolyomuzdaki Kurumsal Web Sitesi Yenileme kartı bir yazılım göçünü değil, bir kurumsal sitenin baştan kurulmasını anlatır; kart "dokunulamayacak kadar kırılgan bir altyapıda çalışan aynı siteyle tekrar tekrar karşılaşıyoruz" der ve "bunları modern bir altyapı üzerinde baştan kuruyoruz" diye ekler. Bu cümleler yalnızca bizim de bu tür işte baştan kurmayı seçtiğimizi gösterir; hangi yolun sizin sisteminize uyduğunu yukarıdaki karar testi belirler. Yapay zekayla hızla yazılmış bir uygulamada hangi katmanın yeniden kurulacağı sorusu için vibe coding uygulaması üretime hazır mı yazısındaki denetime bakın.

Kararı yazılı bir değerlendirmeye ve yol haritasına dökmek istiyorsanız yazılım danışmanlığı ve modernizasyon sayfamıza bakın.

Biz bunu nasıl yapıyoruz

Burada yalnızca sitemizde yazdığımızı tekrarlıyoruz. Her proje, onayladığınız yazılı teklifle başlayan ücretli bir çalışmadır. Kapsam, takvim ve maliyet, herhangi bir ücretlendirme başlamadan önce yazılı olarak elinizde olur; onayınızdan önce tahsilat yoktur.

Aldığımız her teknik kararın nedenini yazılı hale getiririz ve kodunuzu yazan mühendisle doğrudan konuşursunuz. Platformlar yerinde durmaz: bağımlılıklar destekten düşer, API'ler değişir, güvenlik uyarıları çıkar; bakımını üstlendiğimiz projelerde neye bağlı olduğunuzu takip eder, ilgilenilmesi gerekeni size söyleriz. Teslim edilen işin mülkiyeti, kullanım koşullarımızda belirtildiği gibi bedelin tamamı ödendiğinde size geçer; altyapıyı bir gün başka bir ekibe taşımak isterseniz hesaplar, alan adları ve dokümantasyonla temiz bir devir için yanınızdayız. Başka bir firmanın bıraktığı projeyi devralma sorusunun yanıtı özel yazılım geliştirme sayfamızda, adımlar Süreç sayfasında. Projenizi anlatın.

Sık sorulan sorular

Eski yazılımı yeniden yazmak ne zaman doğrudur?

Sistem küçükse, tamamını değiştirmek basitse, davranışı net ve dış bağımlılığı azsa. Microsoft Learn bu durumda kademeli geçişin gereksiz bir yük olabileceğini yazar. Sistem büyükse ve iş geçiş boyunca değişiyorsa tek hamlelik yeniden yazma iki hareketli hedefi kovalamak demektir.

Strangler fig deseni nedir, her sistemde uygulanır mı?

İşlevi bir cephe üzerinden dilim dilim yeni sisteme taşıyıp eskiyi sonunda kapatma yaklaşımıdır; adı Fowler'ın gördüğü bir asma türünden gelir ve yazılım modernizasyonunda kullanılan bir desendir. Her sistemde uygulanmaz. Microsoft Learn dört durumda uygun olmayabileceğini yazar: isteklere müdahale edilemiyorsa, kaynak koduna ya da değiştirilebilir bir entegrasyon noktasına erişilemiyorsa, sistem küçük ve tamamını değiştirmek basitse, eski çözümün hızla tamamen kapatılması gerekiyorsa.

Eski sistem çalışırken yeni özellik eklenebilir mi, geçiş sırasında sistemi kapatmak gerekir mi?

Kademeli yaklaşımda eski sistem ayakta kalır, cephe istekleri yönlendirir. Fowler, yaklaşımın çoğu zaman eskinin üstüne ama ondan ayrı kurulan küçük eklemelerle, çoğunlukla yeni özelliklerle başladığını anlatır. Kapatma gerekip gerekmediği kesim yönteminize bağlıdır: "stop the world" yönteminde normal iş faaliyeti tanım gereği durur; kademeli yöntemlerde eski sistem ayakta kalır.

Veri geçişi nasıl yapılır, geri dönüş mümkün mü?

Genişlet, taşı, daralt sırasıyla: yeni yapıyı ekleyin, tüketicileri taşıyın, eskiyi en son kaldırın. Her veri için tek yazıcı belirleyin ve kesimden önce eski ile yeni arasındaki tutarlılığı doğrulayın. Geri dönüş, eski veritabanı ve eşzamanlama süreçleri duruyorken kolaydır; silindikten sonra pahalı ve risklidir (Microsoft Learn). Bu genel bir yöntem anlatımıdır; veritabanınıza özgü plan, kapsamla birlikte yazılı teklifte netleşir.

Hiç dokunmadan, yalnızca çevresine yeni katman koymak mümkün mü?

Kod ve entegrasyon noktasına erişiminiz yoksa genellikle tek yol budur; yeni katmanı eskinin kavramlarından korumak için çeviri katmanı gerekir. Bedeli: eski sistemin sorunları yerinde kalır. Bu bizim mühendislik yargımızdır; erişim ve devir soruları için yarım kalmış proje yazısına bakın.

Kaynaklar

Aşağıdaki sayfalar 6 Kasım 2026'da açılıp okundu. Yazı genel bilgi içindir. Sayfalar zamanla değişebilir.

• Ian Cartwright, Rob Horn, James Lewis, Patterns of Legacy Displacement (Thoughtworks; 5 Mart 2024): Feature Parity, kesim stratejileri; ayrıca Divert the Flow (20 Ocak 2022).
• Microsoft Learn, Strangler Fig pattern (sayfada görünen son güncelleme 2 Haziran 2026): uygun olmayabileceği durumlar, cephe, çeviri katmanı, veritabanı örneği.
• Martin Fowler, Strangler Fig (22 Ağustos 2024) · Dark Launching (29 Nisan 2020).
• Danilo Sato, Parallel Change (13 Mayıs 2014) · Canary Release (25 Haziran 2014).
• Joel Spolsky, Things You Should Never Do, Part I (6 Nisan 2000).
• Michael Feathers, Characterization Testing (8 Ağustos 2016).