Najlepsze praktyki dotyczące refaktoringu kodu, które pomogą Ci w pracy

Często podczas tworzenia aplikacji zauważamy, że dodawanie nowych funkcjonalności zaczyna sprawiać problemy. Działając pod presją czasu, zaczynamy je omijać, stosując dziwne i niezrozumiałe zmiany w kodzie. Takie postępowanie może zmusić nas do napisania części aplikacji od nowa i niedowiezienia jej na czas. Jest to oczywiście jeden z ciemniejszych scenariuszy, ale z pewnością realny. Rozwiązaniem jest refaktoring kodu. W tym artykule przybliżymy Wam, czym jest i dlaczego jest tak ważny.

Definicja refaktoringu

Refaktoryzacja to proces wprowadzania zmian w programie, których wynikiem nie są nowe funkcjonalności, a ulepszenie obecnej infrastruktury i jej jakości. Działaniami, które podejmujemy podczas refaktoringu są modyfikowanie kodu i dopasowanie go do obowiązujących w danym projekcie standardów oraz poszukiwanie nowych standardów, które powstały podczas tworzenia projektu i ich definiowanie.

Dlaczego refaktorowanie swojego kodu jest ważne?

Refaktoryzacja sprawia, że nasz kod jest łatwiejszy do zrozumienia. Bardzo często jest tak, że deweloper częściej czyta kod, niż go pisze. Wiedząc to, powinniśmy zadbać o to, aby nasz kod był łatwy do zrozumienia. Pozwoli to szybciej pracować i ułatwi wdrażanie nowych członków zespołu. Regularne sprawdzanie i “czyszczenie” naszego kodu jest bardzo istotne.

Refaktoryzacja sprawia, że nasz kod jest łatwiejszy do modyfikowania. Dobrze zaprojektowana aplikacja, jest o wiele łatwiejsza w rozwoju. Jeśli od początku będziemy dbali o odpowiednią strukturę naszego oprogramowania oraz będziemy poprawiali rzeczy, które nie pasują do przyjętych reguł i standardów, pozbędziemy się problemów, które mogą nas spotkać w przyszłości. Wasze koleżanki i koledzy z zespołu będą Wam za to wdzięczni!

Refaktoryzacja pozwala nam lepiej zrozumieć czyjś kod. Gdy przeanalizujemy część kodu stworzoną przez kogoś innego, możemy nabyć wiedzę, którą później będziemy mogli wykorzystać w przyszłości. Refaktoring jest dobrym sposobem na dzielenie się wiedzą, co jest bardzo ważne podczas pracy w zespole.

Refaktoring kodu - najlepsze praktyki

Podczas naszej programistycznej drogi zawodowej spotykamy się z wieloma regułami, które powinniśmy stosować podczas naszej pracy. Tym bardziej nie powinniśmy zapominać o nich w czasie refaktoringu. Przyjrzymy się kilku z nich.

Dobre poznanie aplikacji

Zanim zaczniemy w jakikolwiek sposób modyfikować obecny już kod, powinniśmy być pewni, że dobrze rozumiemy naszą aplikację od strony kodu oraz - co ważniejsze - od strony biznesowej. Pamiętajmy, że refaktoring polega na ulepszaniu a nie modyfikowaniu kodu. Nie chcemy zmieniać sposobu, w jaki działa nasza aplikacja.

Reguła KISS - Keep it Simple, Stupid

Dbajmy o to, aby funkcjonalności, które posiada nasza aplikacja były stworzone w jak najprostszy sposób. Pozwoli to na łatwiejsze zrozumienie i modyfikowanie ich przez kogoś innego. Oszczędzi nam to również czas, który będziemy potrzebowali na debugowanie, jeśli coś będzie działać nie do końca tak, jak byśmy sobie tego życzyli.

Tworzenie funkcji w oparciu o zasady SOLID

SOLID to akronim, który przedstawia zbiór reguł. Został utworzony przez Roberta C. Martina, znanego szerzej jako Uncle Bob. Uznawany jest on przez wielu programistów jako autorytet.

Reguły te powinniśmy stosować w aplikacjach tworzonych w sposób obiektowy. Przeanalizujmy, co kryje się pod każdą z tych liter.

• S - Single Responsibility Principle. Każda klasa powinna mieć jedno zastosowanie. Powinniśmy ograniczać, co może zrobić jedna klasa i w razie potrzeby tworzyć kolejne. W zamyśle każda klasa ma robić jedną rzecz i robić ją dobrze.
• O - Open/Closed Principle. Zgodnie z tą zasadą, kod ma być “łatwy do rozszerzenia, zamknięty na modyfikacje”. Powinniśmy zatem w odpowiedni sposób używać mechanizmów dziedziczenia i modyfikatorów dostępu.
• L - Liskov Substitution Principle. Ta zasada mówi o tym, aby nasz kod współpracował poprawnie ze wszystkimi klasami i podklasami, które dziedziczy.
• I - Interface Segregation Principle. Każdy interfejs, który tworzymy, powinien zajmować się jak najmniejszą liczbą rzeczy na raz, co ułatwi wprowadzanie w nich ewentualnych zmian.
• D - Dependency Inversion Principle. Powinniśmy zadbać o to, by wysokopoziomowe klasy nie zależały od tych niskopoziomowych. Jeśli tak jest, powinniśmy utworzyć klasy, które będą “mostami” pomiędzy nimi.

Może Cię też zainteresować: Poprawa jakości kodu z narzędziem PHP_CodeSniffer

DRY - Don’t Repeat Yourself

Jest to bardzo ważna zasada. Przestrzeganie DRY pozwala nam na rozwiązanie wielu problemów, na które możemy się natknąć podczas rozszerzania aplikacji. Powinniśmy unikać powtórzeń w kodzie jak ognia. Wszystkie funkcjonalności, które tworzymy powinny być na tyle uniwersalne, abyśmy nie musieli tworzyć nowych, bardzo zbliżonych do nich funkcji, które wykorzystamy raz. Pozbycie się powtórzeń pozwala nam na ograniczenie błędów, które możemy popełnić modyfikując funkcjonalność w jednym miejscu, a pomijając jej drugą wersję w innym miejscu.

Wybór odpowiedniego wzorca projektowego

Jeśli napotykamy jakiś problem, który nie wiem jak rozwiązać, możemy szukać pomocy we wzorcach projektowych (design patterns). Są one zbiorem rozwiązań często napotykanych problemów podczas wytwarzania oprogramowania. Można je podzielić na trzy grupy:

• Wzorce kreacyjne - wprowadzają elastyczniejsze mechanizmy tworzenia obiektów i pozwalają na ponowne wykorzystanie istniejącego kodu.
• Wzorce strukturalne - wyjaśniają, jak składać obiekty i klasy w większe struktury, zachowując przy tym elastyczność i efektywność struktur.
• Wzorce behawioralne - zajmują się efektywną komunikacją i podziałem obowiązków pomiędzy obiektami.

Współpraca z Project Managerem i Product Ownerem

Ciężko jest zrozumieć działanie aplikacji po samym kodzie. Tym bardziej, jeśli jest on źle napisany. Pomaga w tym aktywna współpraca z Product Ownerem i Project Managerem, którzy dokładnie znają aplikację od strony biznesowej, więc mogą odpowiedzieć na wszystkie pytania i niejasności, które mogą się pojawić podczas refaktoringu kodu.

Testy, testy i jeszcze raz testy

Po zakończonym refaktoringu kodu powinniśmy obowiązkowo sprawdzić, czy aplikacja dalej działa tak samo pod względem biznesowym, jak działała przed naszymi zmianami. W tym celu powinniśmy uruchomić testy automatyczne lub przekazać nasze zmiany do testera manualnego, który bardzo dobrze zna projekt i będzie w stanie wychwycić wszystkie zmiany, które nie powinny mieć miejsca.

Źródło: DZone

Refaktoring kodu - podsumowanie

Refaktoring jest bardzo istotnym procesem w wytwarzaniu oprogramowania. Jeśli zachodzi jego potrzeba, nie powinien być traktowany jako niechciany koszt, a raczej jako mądra inwestycja w projekt. Dobrze przeprowadzony refaktoring pozwoli zaoszczędzić dużo czasu, a co za tym idzie i pieniędzy, gdy w przyszłości będziemy musieli rozbudować aplikację.

W Droptica prowadzimy wiele ciekawych projektów, dołącz do naszego zespołu i twórz z nami solidne rozwiązania!