Strategia refaktoryzacji na dużą skalę

Nigdy nie słyszałem o określeniu "zastosowanie dusiciela" - podoba mi się. Tam, gdzie to możliwe, zawsze byłoby to dobre podejście, z pewnością minimalizuje ryzyko i jest dość pragmatyczne, odpryskując na wielki Gmach kawałek po kawałku.

Gdzie to nie działa z mojego doświadczenia, to gdzie potrzebne są od razu dość znaczące zmiany - zmiany, które będą wymagały odrobiny refaktoryzacji (lub dużo hakowania). W tej sytuacji często uważałem, że zmiany, które musiałem zrobić, były w samym sercu z wielkiej kuli błota i nie było opcji, ale pobrudzenie - nawet to, co powinno być standardową konserwacją lub niewielkimi zmianami ulepszeń, było po prostu straszne, a główny refaktor był najlepszym rozwiązaniem.

W takich przypadkach wybrałbym divide and conquer - pierwszym celem, do którego zawsze zmierzam, jest testability, gdy już się ma, że cała reszta jest o wiele łatwiejsza. W rzeczywistości jest to często jeden z głównych sterowników, które mam do refaktoryzacji z dala od wielkiej kuli błota – tego rodzaju kod jest często bardzo prawie nie do przetestowania, mam nadzieję, że są przykładowe wejścia i wyjścia interfejsu użytkownika, ale czasami nawet tego brakuje.

Więc w obliczu kodu, w którym wszystko jest wrzucane do interfejsu użytkownika, zwykle zaczynam od uwzględnienia dyskretnych jednostek funkcjonalności w klasy i metody, a następnie spychając te części kodu w dół do warstwy domeny lub usługi. Robienie tego krok po kroku znacznie zmniejsza szansę na złamanie czegoś i ułatwia wskazywanie, gdzie znajdował się kod łamania, gdy wszystko idzie źle.

Uruchom wszystkie dostępne przypadki testowe pod koniec każdej zmiany i upewnij się, że nadal spełniasz jakąś linię bazową.

Jeśli piszesz dobre testy jednostkowe, możesz zacząć zmniejszać skalę problemu i odkryłem, że wkrótce praktyczne staje się podejście dusicielskie - przy przyzwoitych testach jednostkowych lub przynajmniej odpowiednim frameworku pozwalającym na pisanie przyzwoitych testów jednostkowych staje się znacznie bardziej praktyczne stopniowe zastępowanie części testów jednostkowych. funkcjonalność.

Natknąłem się na "metodę Mikado", która wydaje się obiecująca dla atakowania problemów tego rodzaju.

Http://mikadomethod.wordpress.com/

Jest też mowa o metodzie Mikado z Øredev 2010.

Http://oredev.org/2010/sessions/large-scale-refactorings-using-the-mikado-method

Zależy od tego, czy musisz mieć zawsze działający stan, aby można było naprawiać błędy i wdrażać je zawsze, wtedy Devide i Conquer byłoby dobrym rozwiązaniem. Jeśli zachowasz stary kod podczas pracy nad nowym (i będziesz mieć możliwość stosowania poprawek błędów w obu bazach kodu), lepszym rozwiązaniem może być ponowne zapisanie.

Jeśli przez refaktoryzację masz na myśli Ulepszanie kodu bez modyfikowania funkcjonalności, zacząłbym od stworzenia linii bazowej automatycznego testowania regresji. Istnieje wiele narzędzi, które pomogą w tym. Używam TestComlete choć istnieją dobre tanie alternatywy.

Po ustaleniu podstawy testu regresyjnego, osobiście wybrałbym divide and conquer, ponieważ z mojego doświadczenia wynika, że jest to najbardziej prawdopodobne. Gdy masz testową bazę, ma to znaczenie mniej, które podejście wybrać.

Dla mnie to zależy od sytuacji.

Jeśli jest to bardzo mały projekt, skusiłbym się na przepisanie go od podstaw...jednak nie często masz ten luksus.

W Przeciwnym Razie poszedłbym na odpryski kawałek po kawałku. Napiszę testy jednostkowe, aby zweryfikować istniejącą funkcjonalność i powoli wykorzystam TDD, aby przekształcić kod w elegancki i dobrze zaprojektowany system. W zależności od tego, jak długo ten proces potrwa, prawdopodobnie zacznie wyglądać jak StranglerApplication, o którym wspomniałeś powyżej.

BigBang jest bardzo ryzykowny, ponieważ nie ma łatwego sposobu sprawdzenia, czy zaktualizowany system działa tak samo, jak stary.

Divide and Conquer jest mniej ryzykowne niż BigBang...ale jeśli jest wystarczająco duży system może skończyć się tak samo problematyczne jak BigBang.

Big bang / Big re-design / przepisywanie SW ... czy jakakolwiek inna nazwa nie zadziała na żywą SW. Powody są następujące:

• Nadal musisz wspierać istniejące oprogramowanie (prawdopodobnie) tymi samymi zasobami, które posiadasz.

• Prawdopodobnie nie masz wymagań dotyczących przepisywania. Twój stary kod ma wszystkie wymagania osadzone w nim. Żaden z Twoich inżynierów nie zna wszystkich domen SW i wszystkich wymagań.

• Przepisanie zajmie trochę czasu. Na pod koniec tego czasu przekonasz się, że istniejący SW zmienił się, aby wspierać rzeczy, które były wymagane w tym czasie. Twój nowy program SW faktycznie rozdzielony od oryginału i scalony będzie potrzebny (co również zajmie trochę czasu).

Czy total rewrite jest opcją? Z mojego doświadczenia wynika, że przepisywanie od podstaw często może być bardziej efektywne niż próba posprzątania istniejącego bałaganu. Nadal zachowujesz części istniejącego kodu, ale w nowym kontekście. To samo dotyczy gui i bazy danych, jeśli go posiadasz. Przepisać od podstaw i zabrać ze sobą to, co można użyć.

Zaczynanie od czystej nowej architektury i przenoszenie starych peices kodu do tej nowej architektury kawałek po kawałku i refaktoryzacja go do nowego łuku byłoby dobrym rozwiązaniem. Myślę, że podejście oddolne przy przenoszeniu funkcji byłoby dobre.