Kanı değiştirin! Eski sistemi yeniden yazma kabusunu kendim bitirdim
Birçok mühendis eski projeler ve kod tabanları hakkında konuşuyor. Ancak eski kod defalarca hacklenirse, saklanmanın bir yolu yoktur ve bu "zamansız bombayı" çözmek için etkili çözümler öne sürülmelidir.
Alternatif yeniden yazma: bir kabusun başlangıcı
Karmaşık uygulamalar genellikle tüm vücudu etkiler.Bazı uygulamaları yeniden yapmak istediğinizde, diğer uygulamaların da etkileneceğini görürsünüz.
Daha da kötüsü, kodu değiştirmeden önce bir birim testi yazmaya çalıştığınızda, kodun orijinal olarak test edilebilir kod olarak tasarlanmadığını görürsünüz. Yani her türlü mücadele ve denemeden sonra bu uygulamayı dondurabilir ve bir daha asla dokunmak istemeyebilirsiniz ...
Öyleyse, durumu daha az kötü hale getirirken, sürdürülemez kodu değiştirmenin bir yolu var mı?
Kodu değiştirmenin belirli riskleri olduğunu ve yeniden düzenleme maliyetinin çok yüksek olduğunu biliyoruz. Bu durumda, kodu sıfırdan yeniden yazmak iyi bir fikir gibi görünüyor.
Bu düşünce çizgisini takip ederek, bundan sonra ne olacak?
Sonunda öldürmeyi seçtim
Şu anki projem bu sorunla ilgileniyor. Paralel olarak çalışan iki sistemimiz var: araba (eski sistem) ve rezervasyon (yeni sistem). Aslında rezervasyon, alışveriş sepetinin yerini almalıdır.
Proje üç yıl önce başladı, ancak üç yıl sonra proje hala bitmedi.
Genel olarak, rezervasyon alışveriş sepetinden daha iyidir, ancak bu, tüm yönlerin alışveriş sepetinden daha iyi olduğu anlamına gelmez. Bazı satın alma süreçlerinde rezervasyon kullanılır, ancak birçok işlem hala alışveriş sepetini kullanır.
Artık eski ve yeni sistemler paralel çalıştığı için yeni fonksiyonların uygulama süresi iki kat daha uzundur. İlginç bir şekilde, orijinal tasarım amacı istediğimiz yeni özellikleri desteklemek değil, rezervasyonun süresi geçmiş olduğundan, "alışveriş sepeti sistemini uygun şekilde yeniden yazmak" önerildi.
Bu düşünce çizgisini takip edersek, önümüzdeki birkaç ay içinde paralel çalışan iki sistemimiz olabilir. Açıkçası, bu iyi bir yol değil Sistem problemlerini etkili bir şekilde çözmenin başka bir yolunun "boğmak" olduğunu da biliyorum.
Eski kod tabanı nasıl "boğulur"
Yöntem basittir: Eski kod tabanını yavaş yavaş silin ve yenisini kullanın.
Spesifik işlemler aşağıdaki gibidir:
- Yeni kodun eski kod için bir vekil görevi görmesine izin verin. Kullanıcı yeni sistemi kullanır ve yeni sistem eski sisteme yönlendirilir.
- İşlemin her adımı yeni kod tabanında yeniden uygulanır ve bu işlem son kullanıcının görüşünde değişmez.
- Kullanıcıların yeni özellikleri kullanmasına izin vererek eski kodu yavaş yavaş soldurun. Eski, kullanılmayan kodu silin.
Gerçek işlem
Sistemimiz için, ödemeleri işlemek için bir alışveriş sepeti modülümüz var.
Yeniden yazmaya çalıştık, fikir alışveriş sepetinden daha yeni, daha iyi bir rezervasyon ödeme yöntemi oluşturmak. Ancak bu proje% 100 teslim edilmedi, çünkü yeniden yazma işi çok fazla zaman aldı, eski araba sisteminde yeni özellikler geliştirmek zorunda kaldık.
Sonunda iki modül oluşturduk.
Tekrar deneyelim, bu sefer araba modülünü "öldüreceğiz". Önceki yöntemden farklı olarak, bu sefer yeni rezervasyon modülünü bir proxy sunucusu olarak tanıtıyoruz.
Kurulumu kolaydır. Yakında, ödeme işleme mantığını kopyalamadan üretime teslim edebiliriz. Ardından kademeli olarak ödeme mantığını yeni rezervasyon modülüne taşımaya başlayabiliriz.
Mantığı taşırken, sepet modülündeki kullanılmayan koddan kurtulduk. Bu süreç biraz zaman alabilir, ancak yavaş yavaş eski, bakımı zor arabayı terk ediyor ve yeni ve daha iyi rezervasyonlar uygulamaya başlıyoruz.
son sözler
Bunun en iyi yanı, yeniden yazma sırasında yeni özellikler sunamama sorununu çözmektir. Bu teknikle, kodu kopyalamaya ve yeni işlevleri iki kez uygulamaya gerek kalmaz. Ek olarak, yeni sistemi mümkün olan en kısa sürede devreye almalı, daha hızlı geri bildirim almalı, iş yükünü en aza indirmeli ve işleri berbat etme riskini azaltmalısınız.
Son olarak, kodu 6 ay boyunca dondurmadan metodik olarak yeniden yazabilirsiniz. "Boğulma" şiddetli olsa da, bu metafor, tam olarak dönüştürmekten daha az riskli olan eski sistemden yavaşça kurtulmanın yolunu tam olarak açıklıyor. Eski kodun kullanılması gerçekten zor olduğunda, bu daha iyi tasarıma giden ilk adım olabilir.
Etki Alanı Odaklı Tasarım (DDD) ile uğraşıyorsanız, eski sistemleri aşamalı olarak kaldırmak için bu yöntemi kullanmanızı öneririm.
Eski sistemi bir kara kutu olarak ele alabilir, bir Bubble Context oluşturabilir ve DDD ilkelerini bu kutuya uygulayıp dağıtabilirsiniz. Bubble Context eski sistemle etkileşime girer. Yavaş yavaş, sürekli büyüyen Bubble bağlamında yeni özellikler uygulanacaktır. Aynı zamanda işinizde eski sistemi kullanmak için daha az fırsat vardır, bir güne kadar eski sistemi tamamen kapatabilirsiniz.
Orijinal bağlantı: https://understandlegacycode.com/blog/avoid-rewriting-a-legacy-system-from-scratch-by-strangling-it/
