Przeczytaj 50 linii kodu lub użyj refaktoryzacji metody extract? - Wglądy od Dereka Comartina

Przykład: Rejestracja użytkownika w systemie czatu

Na początku filmu Derek przedstawia przykład: funkcję rejestracji w systemie czatu. Jest to zwięzły, ale realistyczny blok kodu o długości około 50 wierszy, który wykonuje kilka zadań:

• Sprawdza, czy nazwa użytkownika nie jest pusta

• Sprawdza, czy nazwa użytkownika jest już zajęta

• Obsługuje kanały z ograniczeniami wiekowymi

• Zapisuje nowy obiekt użytkownika

• Wysyła wiadomość e-mail z linkiem aktywacyjnym

Ten kod znajduje się w jednej funkcji i na pierwszy rzut oka może wydawać się świetnym kandydatem do refaktoryzacji metodą wyodrębnienia. Jednak, jak ostrzega Derek, ślepe refaktoryzowanie bez zrozumieniuiuiuiuia skutków może w rzeczywistości pogorszyć przejrzystość.

Zaczynamy od refaktoryzacji: wybierz metodę Extract

Derek zaczyna tak, jak wielu programistów — od podzielenia fragmentu kodu na mniejsze części. Pokazuje, jak wybrać metodę Extract za pomocą menu kontekstowego lub skrótu klawiaturowego w większości środowisk IDE lub edytorów kodu.

Wyciąga:

• validateUsername, aby sprawdzić, czy nazwa użytkownika nie jest pusta

• existingSignUpNotActivated w celu sprawdzenia, czy konto jest nieaktywne

• validateExistingUser do obsługi wszystkich sprawdzania istniejących użytkowników

• filterAgeRestrictedChannels do przetwarzania kanałów dla użytkowników poniżej 18 roku życia

• sendEmail w celu wysłania wiadomości powitalnej

Każdej nowej funkcji nadaje znaczącą nazwę, co jest jedną z najważniejszych wskazówek często promowanych w praktykach czystego kodowania. Jednak przeglądając te zmodyfikowane wersje, Derek zaczyna wskazywać na luki w logice — nie w funkcjonalności, ale w czytelności i przebiegu kontroli.

Problem 1: Ukryte szczegóły implementacji

Jedną z pierwszych sygnałów ostrzegawczych, na które zwraca uwagę Derek, jest to, że szczegóły implementacji są teraz ukryte za wyodrębnionymi metodami.

Na przykład metody validateUsername i validateExistingUser faktycznie generują wyjątki. Jednak jako programista czytający zrefaktoryzowany kod nie miałbyś o tym pojęcia, chyba że uzyskałbyś dostęp do jego wewnętrznych elementów.

Tego rodzaju refaktoryzacja może ukryć logikę sterowania, co prowadzi do błędów lub pominięcia walidacji. Zakres i przebieg nie są już oczywiste. Zamiast uczynić kod bardziej przejrzystym, tworzysz labirynt abstrakcji, w którym skutki uboczne, takie jak wyjątki lub zmodyfikowane zmienne, nie są już widoczne w formie, w jakiej logika została pierwotnie napisana.

Problem 2: Pośredniość i łańcuchy fragmentów

Następnie Derek zwraca uwagę na problem pośrednictwa — gdy jedna metoda wywołuje inną i tak dalej. Pokazuje on, w jaki sposób metoda validateExistingUser składa się z samej metody existingSignUpNotActivated.

Nie czytasz już prostego bloku kodu od góry do dołu. Przeskakujesz między metodami, plikami i klasami tylko po to, aby prześledzić, co się dzieje. I chociaż edytor może pomóc w poruszaniu się po tym tekście, staje się on obciążeniem dla procesów poznawczych czytelnika.

Staje się to jeszcze bardziej uciążliwe w większych systemach, gdzie refaktoryzacja obejmuje wiele plików lub komponentów. Nagle Twój "czysty kod" wydaje się trudniejszy do zrozumieniuiuiuiuia niż pierwotne "nieuporządkowane" 50 wierszy.

Problem 3: Zmienne lokalne i mutacja stanu

Jedna z najważniejszych lekcji zawartych w tym filmie dotyczy obsługi zmiennych lokalnych i mutacji stanu.

Derek zwraca uwagę na metodę filterAgeRestrictedChannels. Nie zwraca wyniku — bezpośrednio modyfikuje przekazaną listę kanałów. Oznacza to, że modyfikujesz stan lokalny z poziomu innej metody i jeśli nie przyjrzysz się tej metodzie dokładnie, zmiana ta pozostaje ukryta.

To narusza oczekiwanie, że funkcja jest albo czystą operacją, albo wyraźnie sygnalizuje, kiedy coś zmienia. Kiedy zastępujesz logikę nową metodą, która nie zwraca wartości, ale zmienia je wewnętrznie, wprowadzasz ryzyko i zamieszanie.

Alternatywna wersja Dereka po refaktoryzacji

Jak więc Derek faktycznie refaktoryzuje swój stary kod?

Proponuje on znacznie prostsze podejście:

1. Zachowaj logikę, która sama w sobie jest zrozumiała. Wstępna kontrola pod kątem pustej nazwy użytkownika pozostaje w metodzie głównej, ponieważ jest łatwa do zrozumieniuiuiuiuia i nie zaśmieća kodu.

2. Zwracaj wyniki zamiast modyfikować dane. Zamiast modyfikować listę kanałów, funkcja filterAgeAppropriateChannels zwraca teraz przefiltrowaną listę. Dzięki temu przepływ danych jest przejrzysty i zapobiega nieoczekiwanym skutkom ubocznym.

3. Stosuj proste, przewidywalne metody wyciągania danych. Jedyną inną wyodrębnioną metodą jest isExistingUserAlreadyActivated, która wyraźnie zwraca wartość logiczną bez zgłaszania wyjątków. Ujmuje logikę bez ukrywania szczegółów.

4. Należy unikać efektów ubocznych w kodzie, takich jak wysyłanie wiadomości e-mail. Derek pozostawia logikę e-maila na miejscu w celach demonstracyjnych, ale sugeruje, że w rzeczywistym systemie powinno to być obsługiwane poprzez zdarzenie w oddzielnym procesie lub wątku — a nie coś powiązanego bezpośrednio z przesłaniem formularza użytkownika.

W sumie Derek używa tylko dwóch metod wyodrębniania, a resztę logiki pozostawia w kodzie — ponieważ jest to łatwiejsze do odczytania, zrozumieniuiuiuiuia i kontrolowania.

Końcowe wskazówki dotyczące refaktoryzacji metody Extract

Film Dereka zawiera praktyczne wskazówki dotyczące skutecznego stosowania refaktoryzacji metodą extract:

• Używaj sensownych nazw, które dokładnie opisują działanie metody.

• Należy unikać efektów ubocznych, takich jak zmiana stanu lub zgłaszanie wyjątków, chyba że są one oczywiste.

• Zwracaj wartości zamiast modyfikować parametry wejściowe.

• Nie ukrywaj logiki za wieloma warstwami abstrakcji.

• Jeśli metoda wydaje się czytelna w swojej oryginalnej postaci, nie dziel jej na wiele funkcji tylko dla samego refaktoryzowania.

Czasami najlepszą abstrakcją jest brak abstrakcji — zwłaszcza gdy odbywa się to kosztem jasności i świadomości zakresu.

Wnioski

Podejście Dereka Comartina podważa pogląd, że refaktoryzacja zawsze poprawia kod. W przypadku refaktoryzacji metody extract często mniej znaczy więcej. Zamiast nadużywać metody select Extract do rozbijania logiki, zastanów się, co wnosi wartość dodaną, co sprawia, że kod jest łatwiejszy do zrozumieniuiuiuiuia, a co ukrywa ważne szczegóły.

Korzystając z jasnych przykładów i bezpośredniego wglądu w rzeczywisty kod, Derek w swoim filmie pokazuje, że czasami 50 linii w jednej metodzie, czytanych od góry do dołu jak opowiadanie, jest lepszych niż dziesięć mniejszych metod rozrzuconych po całym kodzie.

Jeśli kiedykolwiek sięgałeś po skrót klawiaturowy, aby utworzyć nową metodę, pamiętaj o radzie Dereka: zatrzymaj się, oceń sytuację i upewnij się, że refaktoryzacja służy czytelnikowi — a nie tylko środowisku IDE.