Zadbany kod, ale jak na standardy sprzed kilku lat. Przemyślenia o refaktoringu

Refaktoring kodu to temat rzeka, można o nim mówić dużo i nie wyczerpać tematu. Dlatego zacznę od tego, co będzie zawierał poniższy artykuł, abyś mógł łatwo znaleźć w nim wiedzę, która cię interesuje. Na samym początku, poznasz przyczyny powstawania niezrozumiałego kodu, który w odczuciu deweloperów musi zostać poprawiony. Dalej przedstawię swój punkt widzenia na samą potrzebę refaktoringu, po czym idąc tym tropem, dowiesz się na co warto zwrócić uwagę chcąc się zabrać do takiego procesu. Na koniec najważniejsze, z punktu widzenia programisty: Jak poradzić sobie w przypadku napotkania projektu z niezrozumiałym kodem, kiedy nie mamy kontaktu z jego twórcami. Co robić, jak żyć?

Tomasz Ferfecki. Programista z zawodu i powołania, posiadający 6-letnie doświadczenie w branży. Obecnie pracuje w firmie Unity Group. Przez ostatnie 3 lata zajmował się rozwojem rozwiązań e-commerce w firmach takich jak Grupa Unity oraz G2A. W swojej pracy ceni automatyzację monotonnych i powtarzających się procesów. Swoją pasję do automatyzacji przenosi na mini projekty, gdzie możliwe jest ich użycie. W ramach obecnej pracy zajmuje się inicjatywą cotygodniowego dzielenia wiedzy.

Powody powstawania niezrozumiałego kodu

Najczęściej występującą przyczyną powstawania niezrozumiałego kodu, z którą się spotykałem były nieustannie zmieniające się wymagania projektowe. Żadni kosmici, teorie spiskowe, żadne braki kawy nie są w stanie spowodować tyle zagmatwania, ile zamieszanie ze strony klienta. Wszak nikt nie potrafi tak pozmieniać logiki, jak grupa osób decyzyjnych w projekcie.

Projekt, który chce zostać na rynku, często musi się dynamicznie dostosowywać do jego wymogów. Niektórzy mogą uważać to za zło konieczne — bo ten zły i niedobry klient, znowu chce coś zmienić, a tak naprawdę, to jest największe dobro jakie może spotkać twój projekt. Klient chce płacić za zmiany w projekcie, aktualizacje są dobre (chyba, że jest to zmiana serwisowa — wtedy smuteczek). W zależności od klienta, projektu i rynku — tempo prac nad takim projektem jest odpowiednio dynamiczne.

Z tego powodu do zadań programisty należy jak najlepsze dotrzymanie biegu, w zaspokojeniu zmieniających się potrzeb biznesu. To jak ‘najlepiej’, niestety nie zawsze oznacza najlepszy kod, użycie odpowiednich wzorców projektowych pozwalających opisać w jasny i czytelny sposób procesy biznesowe. Czasami taka zmiana jest, niestety, hackiem który powstał, bo nie dało się inaczej jej wprowadzić w określonym czasie, jaki był dostępny.

Zadaj sobie pytanie: Czy mając tyle czasu, ile byś chciał byłbyś w stanie stworzyć idealny kod, który nie potrzebowałby refaktoringu?

Hack na kodzie, który został stworzony przez deweloperów, jest konsekwencją wszystkich wcześniejszych decyzji popełnionych podczas życia projektu. W ten sposób jedne zmiany pojawiają się, inne znikają, a efektem jest zagmatwany kod. Wprowadzając modyfikacje bez zastanowienia, można dojść do pewnego momentu, w którym wprowadzenie kolejnej zmiany nie będzie możliwe. Jedyne co będziesz mógł, to popatrzeć na swoje dzieło i gorzko zapłakać.

Zobacz też

Backend Infrastructure as Code. Czym jest biblioteka AWS CDK – wady i zalety

Potrzeba refaktoringu, czy potrzeba programisty?

Każdego z programistów naszła kiedyś myśl w stylu: a może by to przepisać od nowa, przecież tym razem wyjdzie mi to lepiej. Posiadam większą wiedzę, jestem teraz bardziej doświadczony. Jeżeli dotychczas ktoś nie miał takiej myśli, to może ona kiedyś się pojawić, jak wróci do swojego starego kodu.

Często, jak się spogląda na taki stary kod, to stary kod spogląda na ciebie (nie jest to miłe spojrzenie). Nawiedzają cię wtedy mroczne myśli w stylu: kto to tak napisał i dlaczego akurat ja muszę coś poprawiać w tej abominacji. Nie czujesz więzi z takim kodem — czasami nie czujesz więzi nawet z własnym kodem — i jesteś przekonany, że możesz napisać to lepiej i szybciej. Czy ten kod rzeczywiście wymaga poprawy? A może to ty nie potrafisz go zrozumieć? Jak jest naprawdę?

Czy jest to słuszne uczucie, za którym powinieneś podążać?

Krótka odpowiedź brzmi: nie. Dłuższa: to zależy. Największym problemem, który napotykam z zastanym kodem jest dla mnie brak jego czytelności. Ile czasami problemów sprawia przeczytanie ze zrozumieniem paru akapitów treści do zadania lub dokumentacji. O ile przez to trudniejsze jest zrozumienie tego co się dzieje w jakimś module naszego projektu?

Jeżeli czegoś nie rozumiemy, to powinniśmy starać się zrobić wszystko, aby ten kod zrozumieć. Jednak często łatwiej podjąć decyzję o refaktoringu, bo tak jest nam prościej. Im więcej w swoim życiu napiszemy kodu, tym lepiej wiemy, kiedy jest rzeczywisty czas na refaktoring, a kiedy to tylko nasza fanaberia.

Korzystaj z wiedzy współpracowników i szanuj tę wiedzę, nie wiadomo bowiem, kiedy przyjedzie autobus po twojego kolegę.

Rodzaje refaktoringu

Zacznijmy od definicji czym jest refaktoring. Refaktoryzacja kodu, to proces restrukturyzacji istniejącego kodu komputerowego bez zmiany jego zachowania. Brzmi prosto, prawda? Ale nie istnieje coś takiego jak jeden rodzaj refaktoringu. Można podzielić go na trzy rodzaje:

• Drobny — zmiany, które ułatwiają czytanie kodu, nie wprowadzają drastycznych zmian w strukturze lub sposobie wykonywania,
• Zaawansowany — zmiany, których dokonujemy, korzystając z części obecnego szkieletu logicznego, w którym został napisany kod,
• Zaoranie — rezygnujemy ze wszystkiego, co jest i piszemy od zera.

Na tym etapie brzmi to ciągle prosto, dlatego dodamy sobie kolejną warstwę zależności. Bardzo dużo może się zmienić w przypadku, gdy będziemy chcieli przeprowadzić refaktoring na różnych poziomach aplikacji. W zależności czy chcesz przeprowadzić refaktoring na poziomie metody, klasy, modułu czy projektu, to z tym większym poziomem ryzyka musisz się liczyć.

Poderwiesz się i krzykniesz: – Jakim ryzykiem! Jestem najlepszym programistą, wiem jak coś zmienić, żeby nie zepsuć. Niestety, wszyscy jesteśmy też ludźmi. I czasami popełniamy błędy, które będą mogły pogrążyć klienta. Ryzyko popełnienia błędu w dużych starych projektach jest o tyle niebezpieczne, że na początku wydaje się nam, iż wszystko działa tak, jak powinno — a tak naprawdę — nic nie działa, jak powinno (I wszystko się pali).

Na powyższym diagramie łatwo można zobrazować sobie, jak rośnie ryzyko nieprzyjemnych konsekwencji. Oczywiście, nawet jak się uda przeprowadzić poprawny refaktoring za pierwszym i drugim razem, to nie znaczy, że uda się za trzecim. Można dodać do tego wykresu dodatkowe poziomy abstrakcji, takie jak liczba osób pracujących nad projektem, złożoność cykolometryczna kodu lub częstość modyfikacji plików z systemu kontroli wersji. Sprowadza się to do jednego wniosku:

Im więcej chcesz naraz zmienić, tym bardziej ryzykowna staje się poprawa

Przechodząc do tego, jak przeprowadzić refaktoring, odeślę do genialnej książki Michaela Feathersa “Praca z zastanym kodem. Najlepsze techniki”. Jest to doskonała lektura dla osób, które chcą zacząć swoją przygodę z refaktoringiem lub pragną uzupełnić swoją wiedzę.

Zobacz też

Backend Zasady czystego kodu C# w pigułce

Co zrobić jak nikt nie może nam pomóc?

Załóżmy bardzo niekorzystną sytuację, w której się znaleźliśmy. Dostaliśmy się do firmy, w której mamy rozwijać dobrze zadbany, 6-letni projekt. Klient potrzebuje zaimplementować dużą liczbę zmian, rzucił pieniądze na stół i mówi — napie*dalać. W życiu jak to w życiu, nie ma nic za darmo. A cena okazuje się dosyć duża. Otóż, zapomniano wspomnieć o paru małych drobiazgach, kiedy zgodziłeś się rekrutować do tego jakże ekskluzywnego zespołu.

Projekt, który mamy rozwijać nie ma już oryginalnych twórców systemu. Aplikacja też nie posiada żadnego zestawu testów jednostkowych, natomiast testy automatyczne nie istnieją lub są na tyle szczątkowe, że równie dobrze mogło ich nie być. Niedopowiedzenia dotyczą też kwestii zadbania kodu — jest zadbany, ale jak na standardy sprzed czterech lat.

Sytuacja wymieniona powyżej wydaje się mocno nieciekawa, ale jak najbardziej możliwa. W takim momencie cała radość z implementacji kodu, może zostać łatwo przysłonięta niezbędną walką z kodem.

Oferty pracy z

Co zatem można zrobić?

Pierwszym krokiem jest zebranie całej możliwej wiedzy o projekcie, o jego procesach biznesowych, czarach i dziwach. Warto zacząć od przeglądnięcia dostępnej wiedzy o projekcie. Można zapomnieć, w takim przypadku, o jakiejkolwiek dokumentacji, która byłaby na bieżąco. Dlatego nieocenionym źródłem informacji są narzędzia do śledzenia błędów i zarządzania projektami (Jira, Trello, Redmine lub cokolwiek innego sobie wymyślili). Czasami może się zdarzyć, że cała komunikacja odbywała się drogą mailową (sic).

Warto spróbować dostać się do tej wiedzy i umieć się w niej odnaleźć. Dalej, łapiemy każdą osobę, która miała jakąkolwiek styczność z projektem. Programistów, testerów, project managerów, administratorów — nawet panią Krysię, jeżeli zajmowała się porządkiem w biurze, w którym pracowano nad projektem. Wiedzę, którą chcemy od nich uzyskać można podzielić na następujące punkty:

• Logika biznesowa:
  • W jaki sposób powinna działać aplikacja,
  • Z jakimi innymi aplikacjami się łączy,
  • Jak wygląda główna ścieżka, po której porusza się klient,
  • Tym więcej można zadać pytań im lepiej wiem czym jest aplikacja.
• Wąskie gardła aplikacji:

Warto zlokalizować miejsca, w których problemy występowały w przeszłości częściej, niż dwa lub trzy razy. Z dużą dozą prawdopodobieństwa można stwierdzić, że prędzej czy później problem wystąpi ponownie. A obszar, w którym on wystąpi będzie wymagał refaktoringu.

Poznaj jak najlepiej projekt, z którym będziesz pracował. Mając wiedzę jesteś już w stanie rozwijać aplikację według własnej woli i umiejętności. Z mojej strony mogę ci tylko życzyć powodzenia.

Zdjęcie główne artykułu pochodzi z stocksnap.io.