Planujesz refactoring? Pamiętaj o tych 5 rzeczach!

Pisząc ten wpis, wspominam czasy, kiedy tworzyłem co tydzień, albo i dwa razy w tygodniu, artykuł na bloga. Były to naprawdę świetne czasy z dwóch powodów. Po pierwsze były to moje początki w sieci. Więc mam punkt odniesienia, jak to wyglądało kiedyś, a jak wygląda teraz. Drugi powód to fakt, że pisałem o rzeczach, które mnie interesowały. Dzieląc się pozyskiwaną wiedzą z innymi, sam się uczyłem wielu rzeczy.

Jednak z biegiem czasu moje priorytety się pozmieniały. Teraz bardziej skupiam się na vlogu i na innych działalnościach, a blog po prostu jest. Nie mniej, postanowiłem wrócić do pisania. Tak od czasu do czasu. Nie będzie to nic regularnego, ale mam nadzieję, że wartościowego dla Ciebie.

Dzisiaj na tapet postanowiłem wziąć temat, który jak widać po tytule, dotyczyć będzie refaktoryzacji kodu. Uwielbiam refaktoring. Robiłem go naprawdę często. Z tego powodu chciałbym się podzielić z Tobą kilkoma rzeczami, jakie udało mi się wypracować, doświadczyć przez te kilka lata programowania.

1. Zastanów się nad celem (po co to w ogóle robię?)

Refaktoring z założenia ma nic nie zmienić w zachowaniu aplikacji, ale poprawić jej strukturę. Z tego powodu biznesowo to się często może nie opłacać. Dlatego, zanim zaczniesz, zastanów się, czy naprawdę warto to robić. Jeśli nie ma zwrotu z planowanej inwestycji, to co to za inwestycja? Myślę, że nie chciałbyś włożyć swoich oszczędności w spółkę, która nie odniesie większego sukcesu, a nawet może zbankrutować.

Tak samo jest z refaktoryzacją. Zastanów się, czy to, co planujesz zrobić, ma sens. Czy poprawi wydajność? Czy zwiększy czytelność kodu? A może przygotuje go na przyszłe zmiany? Jeśli kod jest stabilny, ale brzydki, to naprawdę nie ma co go ruszać. Najwyżej raz na pół roku trzeba kogoś będzie “poświęcić”, aby wprowadził w nim drobną zmianę. Będzie to nieprzyjemne, na pewno dla tej osoby, ale z biznesowego punktu widzenia będzie to najlepsze rozwiązanie.

Odrób pracę domową na samym starcie. Dobrze przemyśl, co chcesz osiągnąć. Zadaj sobie pytanie: “Czy ta refaktoryzacja przyniesie wartość?”. Jeśli odpowiedź brzmi “nie”, to lepiej odpuść i skup się na czymś innym, co ma realną szansę taką wartość przynieść.

2. Zwizualizuj sobie efekt refaktoryzacji (co chcę osiągnąć?)

Istotne jest zdanie sobie sprawy, w jakiej sytuacji jest projekt. Trzeba mieć obraz - As-Is. Następnie warto rozrysować sobie, jak system ma wyglądać docelowo, czyli To-Be. Dopiero wtedy mając Big Picture, można zobaczyć, co jest możliwe do zrealizowania. I na tym budować faktyczny plan działania. Widząc szerszą perspektywę, łatwiej jest dostrzeć właśnie to, co chce się osiągnąć.

Jak jesteś w stanie się domyślić, nie chodzi tutaj o wygląd kodu. Jakie ma mieć zmienne, jak ma być podzielony na klasy czy moduły. Nie mówię, że to nie jest istotne, bo jest. Ma jednak marginalne znaczenie w kontekście całości. Jeśli model jest rozproszony, niedopasowany to zmiana nazw metod nic tutaj nie wniesie.

Jasne, zasada skauta jest dobrą zasadą, ale nie jest to najważniejszy aspekt refaktoryzacji. Widząc całość, cel strategiczny, można planować kroki na poziomie kodu. I wtedy takie dobre praktyki jak wyżej wspomniana zasada skauta, czy SOLID, mogą być naprawdę pomocne. Nie są one jednak celem samym w sobie.

3. Zacznij od najtrudniejszego miejsca (co może spowodować, że refaktoryzacja się nie powiedzie?)

Często kuszące jest rozpoczęcie od małych, łatwych zmian, żeby poczuć wzrost dopaminy w organizmie. Będzie to na pewno przyjemne, ale niekoniecznie efektywne. Jeśli projekt jest duży i złożony, to najtrudniejsze fragmenty kodu będą najbardziej problematyczne. To one mogą spowodować, że refaktoryzacja się nie powiedzie.

Dlatego nie bój się i atakuj te najtrudniejsze miejsca. To najpewniej one są źródłem największego bólu, jaki przyszło odczuwać programistom dotykającym tego fragmentu kodu. Jeśli Ci się powiedzie, to reszta będzie już tylko formalnością. Natomiast jeśli nie to nie przepaliłeś czasu na mało istotne rzeczy. W ten sposób zwiększasz szanse, że nie zrazisz do siebie ludzi biznesu. Być może nawet zyskasz ich szacunek dzięki racjonalnemu podejściu do rozwiązywania wybranego problemu.

Jest to myśl fail fast. Szybka “porażka” pozwoli Ci bardziej przyziemnie rozeznać się, w jakiej sytuacji się znajdujesz. Zaoszczędzi Ci godzin frustracji, nie wypali energii i nie zniechęci do dalszej pracy. Będziesz mógł sprawnie zrobić krok wstecz i znaleźć inne rozwiązanie lub też inny problem do zaatakowania.

4. Zabezpiecz się testami (jak nie zrobić sobie krzywdy?)

Refaktoryzacja bez testów jest jak naprawa samolotu w trakcie lotu. Każda pomyłka może srogo kosztować. No dobra, w programowaniu zawsze można zrobić rollback, ale to nie znaczy, że nie warto się zabezpieczyć przed wprowadzeniem błędu. Warto mieć siatkę bezpieczeństwa, która da nam szybką informację zwrotną czy nic nie popsuliśmy.

Istotne jest tylko na jakim poziomie taką siatkę wprowadzić. Jeśli naprawiamy klasę, to pewnie testy jednostkowe na poziomie tej klasy będą wystarczające. Chyba że będzie to anemiczna klasa, której reguły są rozproszone po całym systemie. Wtedy warto również pomyśleć o testach jednostkowych, ale na poziomie wyższej abstrakcji, czyli na poziomie kilku klas lub danego modułu. Może się też zdarzyć, że nasz kod jest bardzo sprzężony z wybranym frameworkiem. W takim wypadku testy integracyjne weryfikujące integrację aplikacji z frameworkiem będą najlepszym rozwiązaniem.

Mam nadzieję, że czujesz, o co chodzi. Może się zdarzyć, że kod będzie na tyle poplątany, że tylko testy end-to-end będą w stanie nas zabezpieczyć przed wprowadzeniem błędu. Dlatego warto dobrać odpowiedni poziom testów do konkretnej sytuacji.

Natomiast wraz z następnymi krokami refaktoryzacji możemy schodzić z poziomu testów. Choćby nawet z powodu tego, że kod będzie (a przynajmniej powinien być) coraz stabilniejszy, bardziej testowalny. Zamiast utrzymywać ciężkie testy end-to-end, możemy je stopniowo zastępować lżejszymi testami integracyjnymi, a nawet jednostkowymi.

Dlatego dbaj o siatkę bezpieczeństwa. Bo jak mówi klasyk - “Nieprawidłowym pytaniem jest, czy kod będzie przetestowany. Bo na pewno będzie. Pytanie brzmi, kiedy?”. To jest prawdziwe w każdej sytuacji, ale w przypadku refaktoryzacji jest to szczególnie istotne.

5. Nie naprawiaj całego świata na raz (jak chociaż trochę poprawić obecną sytuację?)

W trakcie refaktoryzacji łatwo wpaść w pułapkę, że chcemy naprawić wszystko naraz. Tutaj od razu przyznam, że ja tak miałem nie raz… Często miałem wrażenie, że muszę od razu wszystko poprawić. A to jeszcze tutaj coś podmienię, a to jeszcze tamto poprawię. I tak dalej, i tak dalej. W rezultacie kończyłem z wieloma zmianami, które coś psuły i musiałem wszystko wycofywać. To było frustrujące i czasochłonne. Czasami jednak udało mi się doprowadzić taki refaktoring do stanu użytkowania. Jednak tutaj napotykałem kolejny problem. Ludzie, z którymi pracowałem, musieli zrobić review tego kodu. A to było dla nich przytłaczające. Zbyt wiele zmian naraz sprawiało, że trudno było im zrozumieć, co się zmieniło i dlaczego…

Także nie rób tych samych błędów. Refaktoryzacja to proces, który powinien być stopniowy. Każda drastyczna zmiana powinna być zaprezentowana oddzielnie. W ten sposób i Tobie będzie łatwiej ją wprowadzić, i innym zrozumieć Twój zamysł.

Podsumowanie

Refaktoryzacja to ważny proces, który może przynieść wiele korzyści, ale wymaga przemyślenia i planowania. Nie warto jej robić dla samego faktu robienia. To jest inwestycja. Wkładamy swój czas i energię, aby poprawić kod, a nie tylko go zmieniać. Dlatego warto zastanowić się nad celem, zwizualizować efekt, zacząć od najtrudniejszego miejsca, zabezpieczyć się testami i nie naprawiać całego świata na raz. Jednak co najważniejsze, że refaktoryzacja musi przynieść realny zysk dla projektu.