Czasami spotykam się z pytaniem dlaczego wybrałem właśnie piramidę, jako sposób w którym usystematyzowałem moje podejście do refaktoryzacji zastanego kodu.

Jest wiele innych koncepcji, jak i kiedy dokonywać refaktoryzacji. Każda z nich ułatwia nam zmianę Zastanego Kodu na Czyst(sz)y Kod biorąc pod uwagę różne kryteria oraz różne perspektywy. 

Niektóre podejścia prezentują zestaw kolejnych kroków do wykonania w odpowiedniej kolejności jak Naturalny Porządek Refaktoryzacji autorstwa Mariusza Sieraczkiewicza z BSN IT. Inne są oparte o triggery które mają wyzwalać refaktoryzację w danych sytuacjach np. wystąpienia zapachów kodu (code smells) – polecam tutaj Smells to Refactorings Guide utworzony przez Joshue Kerievskiego.

Z kolei autor książki “Refaktoryzacja” czyli Martin Fowler przedstawił pomysł “Przepływów pracy nad refaktoryzacją” (Workflows of Refactorings) gdzie spojrzał na zagadnienie z bardziej ogólnej perspektywy poprzez przyczyny kiedy dokonujemy czyszczenia kodu. Mogą być nimi np. umożliwienie zrozumienia kodu, umożliwienie rozszerzenia kodu o nowe funkcjonalności bądź realizacja praktyki programowania sterowanego testami (TDD).

Ja natomiast wybrałem piramidę (tutaj przykład w Javie Piramida Refaktoryzacji – przykład) z następujących powodów.

  • Symbolika fundamentów i pracy od podstaw

Każda niższa warstwa piramidy jest fundamentem dla warstwy wyższej. To nie tylko zachęca do wykonywania czynności w określonej kolejności, ale przede wszystkim podkreśla że to właśnie wykonanie poprzedniej czynności umożliwi rozpoczęcie prac nad kolejną.

Dzieje się tak także wewnątrz poszczególnych warstw, które można dzielić na coraz mniejsze. Na przykład przekształcenia “ekstrakcja parametru” lub “dodanie parametru” będą mogły mieć miejsce dopiero po “ekstrakcji metody”.

  • Malejąca częstotliwość aktywności ze wzrostem poziomu

Przekształcenia z warstw niższych są wykonywane dużo częściej niż przekształcenia z warstw wyższych. Podstawowe przekształcenia są zautomatywowane w IDE, więc zajmują dosłownie sekundy.

Analogiczna sytuacja ma miejsce w przypadku piramidy testów gdzie na wyższych warstwach poszczególnych testów jest coraz mniej ale dotyczą one wówczas większego zakresu funkcjonalności.

  • Wsparcie piramidy testów

Poziom pokrycia testów ma wpływ na zakres zmian w kodzie których możemy bezpiecznie dokonać.

Czasem refaktoryzacje dokonujemy w jednej pojedynczej klasie – wówczas  mały test jednostkowy zapewne wystarczy. Ale bardzo często refaktoryzacja obejmuje większy zakres funkcjonalności a wtedy bardzo przydatne będą testy komponentowe czy też integracyjne pokrywające większy zakres działania systemu.

  • Podział na coraz mniejsze niezależne piramidy

Podejście do refaktoryzacji oparte na warstwach wspiera dodatkowo rozwiązywanie problemów z kodem na zasadzie dziel i rządź. Nie musimy od razu zrobić wielkiego porządku w danej metodzie wyłącznie na najniższej warstwie tj. przepływu. Podobnie będzie z pozostałymi warstwami.

Być może lepiej jeżeli podzielimy obecną logikę na 2 lub 3 części i zajmiemy się czyszczeniem tej części która w tym momencie podlega zmianom i rozwojowi. Takie podejście umożliwia dodatkowo zrównoleglenie prac jak i pominięcie prac nad kodem który działa i nie podlega obecnie zmianom a więc nie będziemy teraz w niego inwestować czasu i pieniędzy.

Nawet jeżeli pokusimy się o “przeskok” i wyciągniemy mniejszą metodę która na początku nadal zawiera dużą ilość wierszy, to robiąc porządek wewnątrz takiej metody ponownie wracamy do bardziej podstawowych refaktoryzacji jak “zamień pętlę na strumień”, “połącz zagnieżdżone warunki”, “podziel pętle” czyli do fundamentów piramidy.


Spread the word. Share this post!