Jeżeli nie czytałeś blogów na temat historii piramidy refaktoryzacyjnej, które pomagają utrzymać Czysty Kod, przeczytaj najpierw poniższe artykuły.
Jak zauważyłem Piramidę Refaktoryzacji
Jak czyścić kod według koncepcji piramidy refaktoryzacji?
Jak zasady SOLID wspierają refaktoryzację?
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. Przykłdem jest Naturalny Porządek Refaktoryzacji autorstwa Mariusza Sieraczkiewicza z BSN IT. Inne są oparte o triggery które mają wyzwalać refaktoryzację w danych sytuacjach. Na przykład 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). Martin 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 Jak czyścić kod według koncepcji piramidy refaktoryzacji?) 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. Po pierwsze jest to zachęca do wykonywania czynności w określonej kolejności. Dodatkowo 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. Tutaj na wyższych warstwach poszczególnych testów jest coraz mniej ale dotyczą one 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. Często jednak refaktoryzacja obejmuje większy zakres funkcjonalności. 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.
