Szukasz lepszego sposobu na połączenie głębokiego refaktoryzacji architektury z programowaniem opartym na funkcjach

Opis problemu:

Dany:

• TFS jako kontrola źródła
• Ciężka aplikacja kliencka z mnóstwem starszego kodu ze złym lub prawie nieobecnym projektem architektury.
• Klienci stale potrzebują nowych funkcji z jakością dźwięku, szybką
  dostawą i stale narzekają na nieprzyjazny interfejs użytkownika.

Problem:

Aplikacja niewątpliwie wymaga głębokiego refaktoryzacji. Proces ten nieuchronnie powoduje niestabilność aplikacji i konieczna jest dedykowana faza stabilizacji.

Próbowaliśmy:

Refaktoryzacja w systemie głównym z okresowymi połączeniami z systemu głównego (MB) do gałęzi funkcji (FB). (mój błąd) Wynik: wiele niestabilnych gałęzi.

Co radzimy:

Link do artykułu (pdf)
Utwórz dodatkową gałąź dla refaktoryzacji (RB) okresowo synchronizując ją z MB poprzez scalanie z MB do RB. Po ustabilizowaniu RB zastępujemy master RB i tworzymy nowy oddział do dalszego refaktoryzacji. To jest plan. Ale tutaj spodziewam się prawdziwego piekła połączenia MB z RB po połączeniu dowolnego FB z MB.

Główna zaleta: stabilny mistrz przez większość czasu.

Czy są jakieś lepsze alternatywy dla procee?

W przeszłości miałem podobną sytuację. Co ja zrobiłem:

• ocenić aktualny stan projektu; w większości sytuacji architektura (lub jej brak) jest głównym problemem => przemyśl to
• zwykle występują funkcje robocze, problemem jest wysokie połączenie między różnymi częściami projektu; Oceniłem, które funkcje działają i wykorzystałem je ponownie, ale w mojej własnej architekturze

• rozmawiać z klientem; Nie wiem, co mówi twój menedżer, ale myślę, że ważne jest, aby porozmawiać z klientem i być szczerym; musi wiedzieć, że pracujesz nad jakością jego produktu. Zgodziłem się na plan wydania:

• w fazie łączenia 2 rozwiązań (uczynienia architektury + ponownego wykorzystania funkcji ze starego projektu) jedyne rzeczy, które zostały wydane (nowe funkcje), zostały wykonane na starym produkcie; jednak nowe wersje zawierały tylko ważne poprawki błędów. Tak więc niewiele wydano na starym produkcie. W związku z tym zmienione elementy można łatwo połączyć z nowym rozwiązaniem.

• pierwsze nowe wydanie (wydanie nowego produktu) zawierało tylko to, co zawierał stary produkt (brak nowych funkcji); po ustabilizowaniu go (stabilizacja nie trwała długo) pracowałem z jednym projektem

Myślę, że nie możesz uciec od (stosunkowo krótkiego) okresu sporadycznych wydań. Ważne jest, abyś mógł uzgodnić to z klientem.