Szybkie spojrzenie na definicj\u0119 w Wikipedii<\/a>:<\/p>\n\n\n\n Refaktoryzacja (czasem te\u017c refaktoring, ang.<\/a> refactoring<\/em>) \u2013 proces wprowadzania zmian w projekcie\/programie, w wyniku kt\u00f3rych zasadniczo nie zmienia si\u0119 funkcjonalno\u015b\u0107. Celem refaktoryzacji jest wi\u0119c nie wytwarzanie nowej funkcjonalno\u015bci, ale utrzymywanie odpowiedniej, wysokiej jako\u015bci organizacji systemu (\u2026).<\/p><\/blockquote>\n\n\n\n Porozmawiajmy zatem o refaktoryzacji legacy code. Mo\u017ce tym razem b\u0119dzie lepiej ni\u017c zwykle. Poniewa\u017c zazwyczaj, kojarzy mi si\u0119 to z walk\u0105 z mitologiczn\u0105 Hydr\u0105. Odcinamy g\u0142ow\u0119 \u2013 jest sukces \u2013 ale ju\u017c za chwil\u0119 na jej miejsce wyrastaj\u0105 dwie nowe, czyli nasze b\u0142\u0119dy w kodzie, niezgodno\u015bci z innymi funkcjonalno\u015bciami.<\/p>\n\n\n\n Zejd\u017amy zatem na ziemi\u0119 i rozwa\u017cmy opcje:<\/p>\n\n\n\n Na pocz\u0105tek, doce\u0144my legacy kod aplikacji. On dzia\u0142a, nie ma wielu b\u0142\u0119d\u00f3w, a co najwa\u017cniejsze \u2013 istnieje i funkcjonuje.<\/p>\n\n\n\n Zastan\u00f3wmy si\u0119, co chcemy osi\u0105gn\u0105\u0107 dzi\u0119ki refaktoryzacji:<\/p>\n\n\n\n Koniecznie zadajmy pytanie, jakie obszary aplikacji b\u0119d\u0105 rozwijane w przysz\u0142o\u015bci albo z jakimi zazwyczaj mamy najwi\u0119kszy problem. Mo\u017ce w\u0142a\u015bnie te modu\u0142y powinni\u015bmy refaktoryzowa\u0107.<\/p>\n\n\n\n Nie trzeba zmienia\u0107 cz\u0119\u015bci aplikacji, kt\u00f3ra dzia\u0142a, nie ma b\u0142\u0119d\u00f3w i nie b\u0119dzie rozwijana. Prawdopodobnie by\u0142oby to nieop\u0142acalne.<\/p>\n\n\n\n Przeanalizujmy zatem prosty wykres poni\u017cej. Najlepszym kandydatem b\u0119dzie cz\u0119\u015b\u0107 aplikacji o du\u017cej z\u0142o\u017cono\u015bci kodu, gdzie zachodzi najwi\u0119cej zmian.<\/p>\n\n\n\n Chcia\u0142bym zaproponowa\u0107 kilka sposob\u00f3w radzenia sobie z naszym kodem \u2013 Hydr\u0105. W ten spos\u00f3b u\u015bwiadomimy sobie cel naszej pracy. Cel jest wa\u017cny, poniewa\u017c bez niego mo\u017cemy utkn\u0105\u0107 w \u015blepym zau\u0142ku, d\u0105\u017cy\u0107 do perfekcji, pracowa\u0107 w niesko\u0144czono\u015b\u0107 i nigdy nie zako\u0144czy\u0107 refaktoryzacji.<\/p>\n\n\n\n Proponuj\u0119, d\u0105\u017cy\u0107 do celu metod\u0105 ma\u0142ych krok\u00f3w. Mo\u017ce b\u0119dzie trzeba podzieli\u0107 dzia\u0142ania na kilka mniejszych cz\u0119\u015bci. Konieczne b\u0119d\u0105 narz\u0119dzia takie jak wzorce projektowe, dobre praktyki, SOLID. Mo\u017ce wprowadzenie albo usuni\u0119cie warstwy przyniesie korzy\u015b\u0107?<\/p>\n\n\n\n Opr\u00f3cz narz\u0119dzi warto, je\u015bli jest to mo\u017cliwe, poprosi\u0107 autora lub inne osoby pracuj\u0105ce z kodem o pomoc. Pomocny oka\u017ce si\u0119 ka\u017cdy, kto zna system, tak\u017ce od strony u\u017cytkownika. Kr\u00f3tka rozmowa na temat funkcji programu, niuans\u00f3w, historii zmian wok\u00f3\u0142 kluczowych element\u00f3w przyniesie wiele korzy\u015bci.<\/p>\n\n\n\n W przypadku, kiedy zaczynamy, a dany obszar jest skomplikowany, rozpocznijmy od tej metody. Co do zasady ta refaktoryzacja b\u0119dzie do wyrzucenia \u201edo kosza\u201d. Celem dzia\u0142ania jest rozpoznanie kodu \u2013 jak po\u0142\u0105czono go z innymi modu\u0142ami i jakie ma zale\u017cno\u015bci. Rozpoznali\u015bmy ju\u017c cz\u0119\u015b\u0107 aplikacji i schodzimy ni\u017cej o kolejne poziomy. Na pocz\u0105tku, czytaj\u0105c kod, zastosujmy tymczasowe komentarze. Pozwol\u0105 nam lepiej zrozumie\u0107 ca\u0142o\u015b\u0107, spos\u00f3b dzia\u0142ania i zale\u017cno\u015bci. Dekomponujmy d\u0142ugie metody na mniejsze cz\u0119\u015bci. Co to znaczy d\u0142ugie? Mo\u017ce takie, kt\u00f3re nie mieszcz\u0105 si\u0119 na ekranie komputera (nie, obracanie ekranu pionowo, nie jest rozwi\u0105zaniem). Dla ka\u017cdej instrukcji warunkowej, przekierowania, p\u0119tli (IF, ELSE, FOR, BREAK) dodajemy +1 do naszej z\u0142o\u017cono\u015bci. Przyjmijmy, \u017ce dla z\u0142o\u017cono\u015bci powy\u017cej 6, powinni\u015bmy rozdzieli\u0107 metod\u0119 na mniejsze cz\u0119\u015bci. Skupmy si\u0119 przez chwil\u0119 na szczeg\u00f3\u0142ach. Zauwa\u017cyli\u015bmy, \u017ce w danej refaktoryzowanej klasie jest metoda prywatna. Na tyle skomplikowana, \u017ce warto by\u0142oby j\u0105 przetestowa\u0107. Zamiast zmienia\u0107 j\u0105 na publiczn\u0105, proponuj\u0119 przenie\u015b\u0107 j\u0105 do nowej klasy i dopiero w\u00f3wczas dokona\u0107 zmiany. Zastosowali\u015bmy wszystkie techniki i znane nam chwyty, ale jednak w pewnym momencie utkn\u0119li\u015bmy. Logika biznesowa, cho\u0107 legacy, to dzia\u0142a. Refaktoryzacja to proces wprowadzania zmian w kodzie \u2013 zasadniczo nie zmienia funkcjonalno\u015bci, a poprawia jako\u015b\u0107 kodu. W tym artykule poznali\u015bmy kilka sposob\u00f3w radzenia sobie z refaktoryzacj\u0105 kodu. Poznaj\u0105c dany problem, nale\u017cy dobiera\u0107 odpowiednie narz\u0119dzia oraz cele. Ich obranie zawsze jest kluczowe, poniewa\u017c na tej podstawie stworzymy plan.<\/p>\n\n\n\n Pami\u0119tajmy r\u00f3wnie\u017c o pracy zespo\u0142owej \u2013 konsultujmy plany z innymi i wspierajmy si\u0119 wiedz\u0105 o aplikacji. W ten spos\u00f3b mo\u017cna owocniej realizowa\u0107 za\u0142o\u017cone nadrz\u0119dne plany d\u0142ugoterminowe.<\/p>\n\n\n\nRefaktoryzacja Legacy code<\/strong><\/h2>\n\n\n\n
W takim razie co mo\u017cemy zrobi\u0107?<\/strong><\/h2>\n\n\n\n
![\"Najlepszy](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2022\/10\/Ryc.-1-4.png\")
<\/a>Jak poradzi\u0107 sobie z refaktoryzacj\u0105?<\/strong><\/h2>\n\n\n\n
Znaj\u0105c ju\u017c potrzeby i problemy, u\u0142\u00f3\u017cmy plan d\u0142ugoterminowy, kt\u00f3ry b\u0119dzie zak\u0142ada\u0142 konkretne, du\u017ce zmiany, jakich zazwyczaj nie jeste\u015bmy wstanie bezpiecznie wprowadzi\u0107 w kr\u00f3tkim czasie. Taki plan mo\u017ce zak\u0142ada\u0107 np. zmian\u0119 dzia\u0142aj\u0105cego komponentu w jednej cz\u0119\u015bci aplikacji na nowsz\u0105 wersj\u0119 lub wprowadzenie jednolitego wzorca projektowego.<\/p>\n\n\n\nRefaktoryzacja strategiczna<\/strong><\/h3>\n\n\n\n
Everyday refactoring<\/strong><\/h3>\n\n\n\n
Pracujmy codziennie z kodem, zw\u0142aszcza przy okazji wprowadzania zmian i poprawek wymaganych przez u\u017cytkownik\u00f3w. Pami\u0119tajmy jednak o naszym celu nadrz\u0119dnym, strategicznym. W ten spos\u00f3b zapewnimy ci\u0105g\u0142e wsparcie dla aplikacji i zbli\u017cymy si\u0119 do konkretnego planowanego efektu.<\/p>\n\n\n\nPotrzebujemy narz\u0119dzi<\/strong><\/h3>\n\n\n\n
Refaktoryzacja \u2013 szkic<\/strong><\/h2>\n\n\n\n
Mo\u017cemy wyj\u0105\u0107 ca\u0142\u0105 klas\u0119 do oddzielnego projektu i spr\u00f3bowa\u0107 wydzieli\u0107 odpowiedzialno\u015bci. Je\u015bli to mo\u017cliwe \u2013 przetestowa\u0107. A p\u00f3\u017aniej wyci\u0105gnijmy wnioski.
Dzi\u0119ki temu b\u0119dziemy skupieni na konkretnej cz\u0119\u015bci, nie ca\u0142o\u015bci, na tym samym poziomie z\u0142o\u017cono\u015bci. Pomo\u017ce nam to wr\u00f3ci\u0107 do w\u0142a\u015bciwej refaktoryzacji z gotowym przepisem na sukces.<\/p>\n\n\n\nNarz\u0119dzia Everyday refactoring<\/strong><\/h3>\n\n\n\n
Zastosujmy nowe nazwy dla metod, klas – tam, gdzie uwa\u017camy to za s\u0142uszne.<\/p>\n\n\n\n
Istnieje metoda szacowania z\u0142o\u017cono\u015bci kodu<\/strong> (Z\u0142o\u017cono\u015b\u0107 cyklomatyczna McCabe\u2019a).<\/p>\n\n\n\n
U\u0142atwi\u0107 ca\u0142y proces mo\u017ce tak\u017ce sortowanie metod w klasie \u2013 tematycznie, jedne obok drugich.
Id\u0105c krok dalej, oznaczmy metody publiczne, opiszmy je interfejsem. St\u0105d ju\u017c prosta droga do wydzielenia cz\u0119\u015bci do osobnych klas \u2013 odpowiedzialno\u015bci.<\/p>\n\n\n\nTesty i metody prywatne do oddzielnych odpowiedzialno\u015bci<\/strong><\/h3>\n\n\n\n
Najprawdopodobniej jest to gotowa osobna odpowiedzialno\u015b\u0107. Stara klasa staje si\u0119 coraz prostsza. Od tego momentu mo\u017cemy du\u017co \u0142atwiej przeprowadzi\u0107 test wcze\u015bniejszej metody. Przetestowa\u0107 mo\u017cemy manualnie, a najlepiej napisa\u0107 test (jednostkowy, integracyjny). W ten spos\u00f3b zweryfikujemy poprawno\u015b\u0107 dzia\u0142ania partii kodu.<\/p>\n\n\n\nAnti-corruption layer<\/strong><\/h2>\n\n\n\n
A mo\u017ce problemem jest biblioteka zewn\u0119trzna, kt\u00f3rej nie mo\u017cemy aktualizowa\u0107? Postaraj si\u0119 ograniczy\u0107 u\u017cywanie kodu legacy poprzez warstwy abstrakcji tak, aby rodzaj biblioteki by\u0142 jedynie implementacj\u0105, a jej elementy nie by\u0142y przekazywany pomi\u0119dzy innymi cz\u0119\u015bciami aplikacji.
W takiej sytuacji zastosowa\u0107 mo\u017cemy anti-corruption layer. Czyli warstw\u0119 po\u015bredni\u0105, odcinaj\u0105c\u0105 nas od kodu legacy. B\u0119dzie komunikowa\u0107 nasz nowy kod ze starym. Budujemy warstw\u0119 abstrakcji wywo\u0142uj\u0105c\u0105 funkcje starej cz\u0119\u015bci.
Pami\u0119tajmy jednak, aby nie przekazywa\u0107 dalej poza anti-corruption layer \u017cadnych element\u00f3w z kodu legacy. Dodajmy w\u0142asne implementacje obiekt\u00f3w. W ten spos\u00f3b zamykamy kod legacy \u201epod pokrywk\u0105\u201d. Nadal tam jest, ale nie musimy si\u0119 ju\u017c zastanawia\u0107, jak on dzia\u0142a. Mamy w\u0142asn\u0105 warstw\u0119 komunikacji.<\/p>\n\n\n\n![\"Refaktoryzacja](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2022\/10\/2021-07-20_19h35_52.png\")
<\/a>Podsumowanie<\/strong><\/h2>\n\n\n\n
Z pewno\u015bci\u0105 ka\u017cdy znajdzie dla siebie konkretne zastosowanie, nie zawsze b\u0119dzie konieczne wykorzystanie wszystkich jednocze\u015bnie.<\/p>\n\n\n\n\u0179r\u00f3d\u0142a<\/h2>\n\n\n\n