Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Jak NIE przeprowadzać refaktoryzacji

Daniel Bolella Software Engineer / Syncro Medical
Sprawdź, kiedy refaktoryzacja może zrobić więcej złego niż dobrego i jak przeprowadzić ją jak należy.
Jak NIE przeprowadzać refaktoryzacji

Wszyscy spotkaliśmy się z tym problemem. Nasza baza kodów stała się nieczytelna - z powodu braku dyscypliny, gonienia za terminami, przestarzałego kodu, czy po prostu upływu czasu. Czasami to nawet nie nasza wina, a kogoś, kogo już nie ma przy projekcie.

To prawda, że są różne poziomy kodu wymagającego refaktoryzacji. Czasem może potrzebujemy lekkiego sprzątania, ale jedno jest pewne: kiedy dokonujemy refaktoryzacji naszego kodu, ostatnią rzeczą, jaką chcemy zrobić, jest zniszczenie naszego oprogramowania.

Celowo mówię tutaj o niszczeniu, ponieważ przez prawie dekadę pracy z kodem widziałem już kilka kwiatków. 

Uzależniająca czynność

Przy projekcie, nad którym pracowałem wiele lat temu, mój zespół współpracował z kilkoma konsultantami, którzy (o ironio!) pomagali nam refaktoryzować nasz kod. Trzeba przyznać, że wycięliśmy dosyć sporo, znaleźliśmy poważne błędy i podjęliśmy decyzję, aby całkowicie przepisać pewne obszary, które nie wymagały już refaktoryzacji.

Uświadomiłem sobie jednak, że mój partner-konsultant był poważnie uzależniony. Jego narkotykiem była praca z narzędziem do analizy kodu o nazwie AppCode od JetBrains.

Krótko mówiąc, niektóre z narzędzi zaznaczają, gdzie jest możliwe użycie krótszego kodu lub zrobienie refactoringu. Jednak jedno z narzędzi wyróżnia kod, do którego nie odwołuje się nic innego w projekcie, wskazując w ten sposób prawdopodobnie martwy kod. W sumie to całkiem fajne narzędzie, ale można go porównać do młotka, który też jest przydatny, dopóki wbijasz nim gwoździe, a nie machasz nim bez ładu i składu.  

Być może chodziło o satysfakcję, gdy liczba linijek kodu stopniowo spadała lub fałszywe poczucie zaufania do narzędzia, które nie było Xcodem, i dlatego było o wiele bardziej wiarygodne. Tak czy inaczej, wydawało się, że im dalej idziemy, tym będziemy zwiększać tempo. Miałem poważne problemy z nadążaniem.

W końcu zaproponowałem, że może powinniśmy zwolnić i się zamienić. Niestety, to on był konsultantem i wiedział lepiej, poza tym, za bardzo się wczuł i nie można go było od tej czynności oderwać. Po prostu patrzyłem, a gdy mój niepokój narastał, zacząłem robić notatki na temat obszarów, które będę musiał ponownie odwiedzić. W końcu zrobiło się tego tak dużo, że sprawdzenie tego wszystkiego zajęłoby wieczność. Przynajmniej tak mi się wydawało.

Zgłaszałem swoje obawy szefowi, a nawet szefowi mojego szefa. Przewidziałem, że kiedy ostatecznie rozstaniemy się z dostawcą usług, spędzimy miesiące na naprawianiu nowych problemów. Uwierzyli mi i wspomnieli o tym producentowi. Jednak ich przełożeni powiedzieli, że to eksperci i nic na to nie poradzą, że nie mogę nadążyć za ich pracą. Skończyło się na tym, że to ja ucierpiałem, a nie konsultant, który zarabia więcej ode mnie. 


Następstwa

Zostaliśmy z aplikacją, która miała niekompletne funkcje i pakiet testów jednostkowych, które ignorowaliśmy, ponieważ powodowały zbyt wiele awarii. No i oczywiście projekt, którego nawet nie dało się zbudować. Przywrócenie go do życia zajęło tydzień, zanim mogliśmy dalej oszacowywać, co musieliśmy zrobić, żeby aplikacja ponownie nadawała się do wypuszczenia.

Początkowo naprawialiśmy coś tylko po to, żeby dowiedzieć się, że coś innego nie działa. W pewnym momencie ktoś odkrył, że cała funkcja „ustawień aplikacji” zniknęła. Wyciągnąłem wtedy notatnik i kopię maila, którego wysłałem moim przełożonym. Wraz z pełną liczbą zaległych problemów, potwierdzili oni moje przewidywania. Był tam nawet taki wpis: „prawdopodobnie usunął niektóre, jeśli nie wszystkie, ustawienia aplikacji”.

Zostałem oczyszczony z zarzutów. Moją nagrodą było to, że mogłem zająć się odbudową, która ostatecznie zajęła prawie tyle samo czasu, co refaktoryzacja.


Porządek

Aby skutecznie refaktoryzować, trzeba dobrze ten proces rozumieć i wiedzieć, jakie są jego cele i najlepsze praktyki. Świetnie jest zacząć od Boba Martina, znanego z serii „Czysty Kod" oraz „Agile Manifesto". Stosuje on harcerską zasadę „zostawienia po sobie większego porządku od tego, który się zastało”.

W programowaniu nie ma nic za darmo. Zależność od jednego narzędzia, które wydaje się wykrywać rzeczy, które ludzkie oko mogło przegapić, nie oznacza, że powinniśmy się temu całkowicie poddać. Musimy zaakceptować fakt, że potrzebny jest też czynnik ludzki, czyli rozumienie kontekstu. Ludzie piszą kod i mogą go w pełni zrozumieć, a maszyny nie (jeszcze).

Co prowadzi mnie do ostatniej porady: sukces refaktoryzacji nie jest określony przez liczbę wierszy i tabulatory, a przez kod, który może być łatwo odczytany przez dowolnego programistę i do tego działa.


Nie jesteś sam

Jeśli planujesz swoje podejście do refaktoryzacji lub rozpoczynania jej przy ograniczeniach czasowych (prawdopodobnie wywołanych przez aktualizacje systemu operacyjnego, przestoje lub masowy chaos w repozytorium), wiedz, że nie jesteś sam. Jest wielu ludzi, którzy będą w stanie pomóc.

  • Jeśli pracujesz w zespole, opracujcie razem plan i rozliczajcie się z niego nawzajem. Może to oznaczać programowanie w parach lub częste przeglądy kodu.
  • Rób swoje zamiany na osobnych gałęziach. Mierz siły na zamiary, bo ułatwia to przeglądanie, testowanie i scalanie zmian dla wszystkich zaangażowanych oraz wyłapie konflikty, które można łatwiej rozwiązać razem.
  • Dużo czytaj! Cała sieć wsparcia jest na wyciągnięcie ręki. Dostępna jest spora liczba artykułów dotyczących refaktoryzacji. Ponadto jest dużo książek, takich jak „Refaktoryzacja" Martina Fowlera.



Oryginał tekstu w języku angielskim przeczytasz tutaj.

Nie przegap treści Bulldogjob
Subskrybuj artykuły

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej