fbpx

Jakie są rodzaje refaktoringu

Opublikowane przez Jerzy Wickowski w dniu

rodzaje refaktoringu

Przedstawiam dzisiaj kilka rodzajów refaktoringu. Każdy z nich jest przydatny w innej sytuacji, wart poznania i zrozumienia. Niezależnie czy pracujesz nad starym sępem developerskim, który od lat krąży nad stepami produkcji, czy może dopiero karmisz słodkiego kodowego pisklaka z żółtymi i miękkimi piórkami. To od Ciebie zależy stan i jakość kodu w projekcie. Zobacz, jak można podejść do konserwacji kodu i jakie są rodzaje refaktoringu.

Refaktoring duży/remontowy

To ten typ, pożerający bezmiar czasu i pieniędzy. Zjawia się w sytuacji, gdy kod jest nieczytelny, wręcz obrzydliwy. Jest go po stokroć razy więcej niż ludzki mózg jest w stanie przetworzyć. Olbrzymie klasy, jednoliterowe zmienne, spaghetti, lasagne, ravioli. Metody mające po kilkaset linii, a warunki zagnieżdżone wielokrotnie. Limes wartości metryki WTF na sekundę dąży do nieskończoności. 

Największym problem z tego typu bytami jest niemożliwość podziału pracy pomiędzy kilka osób, ponieważ zmiany mogą być tak częste i tak duże, że merdżowanie stanie się koszmarem na jawie. Taki refaktoring nie powinien być nigdy wykonywany. Programiści całego świata! Nie pozwólcie na powstawanie takiej zgnilizny. Konserwujcie swój kod regularnie, poprawiajcie i dbajcie o jego jakość i czytelność.

Refaktoring mały/wejściowy

Ten pan jest z pozoru podobny to tego wyżej, ale zdecydowanie bardziej uprzejmy. Grzecznie puka do drzwi, by przekroczyć próg Twojego kodu źródłowego. Zwłaszcza przed wprowadzaniem zmian. Jest to doskonała okazja i wspaniały sposób na poprawę kodu, przykrytego już warstwą kurzu. 

Teoretycznie jesteś w stanie wprowadzić wymagane zmiany bez naruszania aktualnej struktury. Możesz dodać kolejnego ifa i dopisać kolejną metodę do ‚Managera’. Jednak zatrzymaj się na chwilę i zastanów się, czy nie ma tam zbyt dużej klasy albo bardzo skomplikowanego układu warunków. Jeżeli tak to weź głęboki oddech i to popraw. Nie zajmie to długo, ale wprowadzanie zmian teraz i w przyszłości, będzie dużo łatwiejsze.

Refaktoring codzienny/polerka

Ten bohater wkłada kapeć między drzwi, abyś przed opuszczeniem kontekstu miał jeszcze chwilę na rzut okiem czy na pewno wyłączyłeś gaz i żelazko. 

Gdy napiszesz nową funkcjonalność albo zmienisz istniejącą. Sprawdziłeś, że działa jak powinna. Chcesz ją zostawić, wrzucić do repo, zapomnieć, a następnie zabrać się za kolejne zadanie. Warto w tym momencie posprzątać po sobie. Przeczytać ten kod jeszcze raz. Może pozmieniać nazwy zmiennych albo wyciągnąć jakiś kawałek do osobnej metody. Bodaj sformatować go trochę inaczej. Takie kosmetyczne zmiany umilą Ci przyszłość.

Refaktoring ciągły/harcerski

Ostatnia postać na naszej liście to praworządny harcerz. Na pierwszy rzut oka niepozorny, ale gdy poznasz go lepiej to okazuje się porządny i solidny. On wie, że obozowisko zawsze zostawia się w lepszym stanie niż się je zastało. Weź z niego przykład. 

Przeglądając kod lub poprawiając drobnego buga, możesz natrafić na coś, co jest warte poprawy. Niejasna nazwa zmiennej, pokręcony warunek, czy las zakomentowanego kodu. Korzystając z okazji, że już tu jesteś i możesz uczynić kod lepszym. Zrób to. A przyszłe pokolenia Ci podziękują. A Robert Baden-Powell, będzie zadowolony.

Podsumowując

Refaktoring to nieodłączna część naszej pracy. Był, jest i będzie. W związku z tym nie należy się go bać, ani unikać. Trzeba go poznać i zrozumieć. Bo jego brak prowadzi do wykolejenia się projektu. Jeżeli przekonałem cię, że należy naprawiać, swój kod, ale nie wiesz jak zacząć to zapraszam Cię do artykułu o tym jak refaktorować.

Co sądzisz o takim podziale? Czy codziennie dbasz o swój kod? A może uważasz, że to strata czasu? Koniecznie daj znać!



Czy to był wartościowy artykuł? Zapisz się, a wyślę Ci dwa ebooki o czystym kodzie oraz będę informował Cię o nowych postach

2 Komentarze

zelazowy · 2016-09-05 o 14:34

Refaktoring „Ciągły/Harcerski” – mam z tym problem ;) Tzn z założenia zasada jest prosta i genialna. Problem jednak w tym, że jak piszę kod to jest to konkretne zadanie do zrobienia i musi przejść przez code review. Jeśli do kodu który piszę dorzucę jeszcze refaktoring to pojawia się problem kilku kontekstów. No bo z jednej strony mam kod realizujący zadanie, z drugiej porządki które niekoniecznie są z nim związane.

Mogę oczywiście robić to w osobnych commitach, ale te również powinny przejść przez CR choćby dlatego, że mimo że to refaktor to nie ma testów które sprawdzą poprawność zmian a weź tu znajdź chętnego na przeklikiwanie się przez kod legacy mając na głowie własne zadania ;)

Jerzy Wickowski · 2016-09-20 o 19:57

@zelazowy: Zgadam się z Tobą. Poruszyłeś tutaj dwie sprawy.
1. Jak jesteś w kontekście robienia czegoś innego, a zmiany są w innej części, przy okazji, Cię rozpraszają to oczywiście, że w takiej sytuacji nie warto zmieniać tego teraz. Jednak warto wrócić do tego miejsca w przyszłości np. po skończeniu aktualnej pracy.
2. Jednak jeśli masz problem z review/procesem/itp to polecam wrzucać refaktoring na innego brancza. Z użyciem GITa jest to proste i szybkie. „git branch refactoring”, commit, „git checkout -„. A na koniec robić dwa CR.

Oczywiście to wszystko może mieć sens lub nie. Zależy od kontekstu. Może również trzeba zmienić/usprawnić proces w firmie, bo utrudnia pracę.

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.


    Zapisz się

    Wyślę Ci dwa dokumenty mówiące o jakości kodu. Dodatkowo będę Cię informował o nowych postach i nowościach.