Yazılım Yeniden Mühendisliği
Yazılım yeniden mühendisliği, mevcut bir sistemin incelenmesi ve değiştirilerek yeni, geliştirilmiş bir biçimde yeniden oluşturulması sürecidir; bu genellikle eskimiş eski yazılımları temel davranışlarını koruyarak modernize etmek amacıyla yapılmaktadır.
Tanım
Yazılım yeniden mühendisliği, bir konu sistemini anlamak amacıyla inceleme ve ardından biçimini veya platformunu iyileştirmek için yeniden uygulama veya yeniden yapılandırma sürecidir; bu süreçte işlevselliği önemli ölçüde korunmaktadır.
Kapsam
Bu konu, tersine mühendislik ve tasarım kurtarma; kod ve verilerin yeniden yapılandırılması; yeni platformlara, dillere ve mimarilere geçiş; eski sistemler için sarmalama (wrapping) ve artımlı modernizasyon stratejileri; dönüşüm sırasında davranışı korumak için test etme; ve yeniden mühendislik ile sürekli bakım veya değiştirme arasındaki karar kriterlerini kapsamaktadır.
Temel sorular
- Eski bir sistemin tasarımı, kodu ve verilerinden nasıl kurtarılır?
- Hangi stratejiler bir sistemi kabul edilebilir riskle taşır veya yeniden yapılandırır?
- Uygulama dönüştürülürken davranış nasıl korunur?
- Yeniden mühendislik, sürekli bakım veya tam değiştirmeye ne zaman üstün gelir?
Temel kuramlar
- Tersine mühendislik ve tasarım kurtarma
- Chikofsky ve Cross, tersine mühendisliği (bir sistemden daha üst düzey temsillerin kurtarılması) yeniden belgeleme, yeniden yapılandırma ve ileri mühendislikten ayıran bir taksonomi tanımlayarak tasarım kurtarma faaliyetlerini çerçevelemişlerdir.
- Artımlı eski sistem modernizasyonu
- Riskli 'büyük patlama' (big-bang) yeniden yazımları yerine, eski sistemler mevcut kod etrafına testler ekleyerek, değişim noktalarını izole ederek ve bileşenleri kademeli olarak yeniden yapılandırarak veya değiştirerek artımlı olarak modernize edilmektedir.
Klinik önem
Yeniden mühendislik, kuruluşların iş açısından kritik eski sistemlerin ömrünü ve değerini sıfırdan yeniden yazmaktan daha düşük riskle uzatmasını sağlamaktadır; eski sistemler genellikle yeri doldurulamaz, belgelenmemiş iş bilgilerini içerdiğinden, sağlam strateji ve davranış koruyucu teknikler esastır.
Tarihçe
1960'lardan 1980'lere kadar inşa edilen büyük sistemler eskimeye başladıkça, tersine mühendislik ve yeniden mühendislik 1980'lerin sonlarında ve 1990'larda ayrı konular olarak ortaya çıkmıştır; bu alan Chikofsky ve Cross'un taksonomisiyle resmileştirilmiştir. Test edilmemiş eski kodları yönetmeye yönelik pratik teknikler ise daha sonra Feathers tarafından kodlanmıştır.
Tartışmalar
- Artımlı yeniden mühendislik ve tam yeniden yazım
- Eski bir sistemi artımlı olarak modernize etmek mi yoksa tamamen yeniden yazmak mı gerektiği tartışmalıdır; yeniden yazımlar temiz bir başlangıç vaat etse de sıklıkla bütçeyi aşmakta ve gömülü bilgiyi kaybetmektedir, artımlı yeniden mühendislik ise daha güvenli ancak daha yavaştır.
Öne çıkan isimler
- Elliot Chikofsky
- James Cross
- Michael Feathers
İlgili konular
Temel eserler
- chikofsky1990
- feathers2004
- sommerville2015
Sıkça sorulan sorular
- Yeniden düzenleme (refactoring) ve yeniden mühendislik arasındaki fark nedir?
- Yeniden düzenleme (refactoring), genellikle devam eden geliştirmenin bir parçası olarak kaynak kodda küçük, davranış koruyucu iyileştirmeler yapmaktadır; yeniden mühendislik ise tasarımları kurtarabilen ve tüm bir sistemi yeni bir platforma veya mimariye taşıyabilen daha büyük ölçekli bir faaliyettir ve yeniden düzenleme bu faaliyetin bir tekniği olabilir.
- Eski bir sistemi neden sıfırdan yeniden yazmıyoruz?
- Eski sistemler genellikle yıllarca birikmiş, kötü belgelenmiş iş kurallarını içermektedir; sıfırdan yeniden yazım bu bilginin kaybedilmesi riskini taşımakta ve sıklıkla bütçeyi aşmaktadır, bu nedenle artımlı yeniden mühendislik, daha yavaş ilerlemesine rağmen genellikle daha düşük riskli bir yoldur.