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

9

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?

development-process refactoring Pavel Voronin
źródło
1
Możliwe ulepszenia (zamiast alternatyw) proponowanego procesu: Narzędzie scalania TFS jest dość niewygodne w porównaniu z różnymi alternatywnymi narzędziami różnicowymi. Jeśli jeszcze tego nie zrobiłeś, ręczne łączenie może być mniej bolesne, jeśli skonfigurujesz klienta TFS tak, aby korzystał z ładniejszego narzędzia różnicowego niż z wbudowanego narzędzia. Przydatne może być również narzędzie Microsoft TFS Power Tools. Zapewnia to możliwość uruchamiania różnic między zestawami zmian lub gałęziami, a nie tylko między poszczególnymi plikami.
Brian,

Odpowiedzi:

1

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.

Paul Ianas
źródło