Derin mimari yeniden düzenleme ile özellik tabanlı geliştirmeyi birleştirmenin daha iyi bir yolunu arıyorum

Sorun bildirimi:

Verilen:

• Kaynak Kontrolü Olarak TFS
• Kötü veya neredeyse yok mimari tasarımı ile tonlarca eski kod ile ağır masaüstü istemci uygulaması.
• Ses kalitesi, hızlı
  teslimat ve sürekli olarak kullanıcı dostu olmayan kullanıcı arayüzünden şikayet eden yeni özelliklere ihtiyaç duyan müşteriler .

Sorun:

Uygulama şüphesiz derin bir yeniden düzenleme gerektirir. Bu işlem kaçınılmaz olarak uygulamayı kararsız hale getirir ve özel stabilizasyon aşamasına ihtiyaç vardır.

Denedik:

Master'dan (MB) özellik alanına (FB) periyodik birleşmelerle master'da yeniden düzenleme. (benim hatam) Sonuç: Birçok kararsız dalları.

Neler tavsiye edilir:

Makaleye bağlantı (pdf)
Yeniden düzenleme (RB) için MB'den RB'ye birleştirme yoluyla MB ile periyodik olarak eşitlemek için ek dal oluşturun. RB stabilize edildikten sonra master'ı RB ile değiştirir ve daha fazla yeniden düzenleme için yeni bir dal oluştururuz. Plan bu. Ancak burada, herhangi bir FB'yi MB ile birleştirdikten sonra MB'yi RB ile birleştirmenin gerçek cehennemini bekliyorum.

Ana avantajı: Kararlı usta çoğu zaman.

Proseslere daha iyi alternatifler var mı?

Geçmişte de benzer bir durum yaşadım. Ben ne yaptım:

• projenin mevcut durumunu değerlendirmek; çoğu durumda mimari (ya da eksikliği) ana sorun => yeniden düşün
• genellikle çalışma özellikleri vardır, sorun projenin çeşitli bölümleri arasındaki yüksek bağlantıdır; Hangisinin çalışma özellikleri olduğunu değerlendirdim ve onları tekrar kullandım, ancak kendi mimarimde

• müşteriyle konuşun; Yöneticinizin ne dediğini bilmiyorum, ancak müşteriyle konuşmak ve dürüst olmak önemli olduğunu düşünüyorum; Ürününün kalitesi üzerinde çalıştığınızı bilmesi gerekiyor. Bir tahliye planı için bir anlaşma yaptım:

• 2 çözümü birleştirme aşamasında (eski projeden mimari + yeniden kullanım özellikleri yapma) eski ürün üzerinde piyasaya sürülen tek şey (yeni özellikler) yapıldı; ancak yeni sürümler yalnızca önemli hata düzeltmelerini içeriyordu. Bu yüzden eski üründe çok az sürüm yapıldı. Bu nedenle, değişen şeyler kolayca yeni çözüme birleştirildi.

• ilk yeni sürüm (yeni ürünün piyasaya sürülmesi) yalnızca eski ürünün içerdiği içeriği içeriyordu (yeni özellik yok); sabitledikten sonra (stabilizasyon uzun sürmedi) tek bir proje ile çalıştım

Bence (oldukça kısa) düzensiz sürümlerden kaçamazsınız. Müşterinizle bu konuda anlaşabilmeniz önemlidir.