Zmiana nazwy zmiennej, nazwy metody s\u0105 to podstawy, kt\u00f3re ka\u017cdy wielokrotnie realizowa\u0142, jednak te kroki r\u00f3wnie\u017c s\u0105 uznawane za refaktoryzacj\u0119. Lepiej wprowadzi\u0107 n ma\u0142ych, bezpiecznych zmian ni\u017c rozgrzeba\u0107 po\u0142ow\u0119 systemu, co mo\u017ce doprowadzi\u0107 do jego zatrzymania. Nale\u017cy podejmowa\u0107 kroki technik\u0105 asekuracyjn\u0105. Trzymaj\u0105c si\u0119 tej zasady, poprawia si\u0119 nam nawet estymacja czasu. Ryzyko niepotrzebnego spalenia du\u017cej ilo\u015bci czasu b\u0119dzie mniejsze.<\/p>\n\n\n\n
Refaktoryzacja \u2013 kiedy jest potrzebna?<\/strong><\/h2>\n\n\n\nNiejednokrotnie trudno jest odpowiedzie\u0107 sobie na pytanie, kiedy powinni\u015bmy zacz\u0105\u0107 co\u015b poprawia\u0107. Ka\u017cdy z nas musi nauczy\u0107 si\u0119, kiedy i jak podejmowa\u0107 si\u0119 refaktoryzacji. Problemem jest tutaj to, \u017ce nie da si\u0119 tego wyja\u015bni\u0107 w ksi\u0105\u017ckowy, zero-jedynkowy spos\u00f3b. Jest to co\u015b, co poznajemy z czasem, ucz\u0105c si\u0119 szacowa\u0107 korzy\u015bci i straty. Inaczej m\u00f3wi\u0105c, ka\u017cda zmiana na poziomie kodu, wprowadzenie wzorca projektowego, dodatkowej abstrakcji, zmiana API ma swoje konsekwencje, kt\u00f3re zmusz\u0105 nas do wprowadzenia zmian na poziomie kodu<\/strong>, np. zmiany kompatybilno\u015bci.<\/p>\n\n\n\nZ drugiej strony, z ka\u017cd\u0105 zmian\u0105 mo\u017cemy co\u015b zyska\u0107. By\u0107 mo\u017ce wi\u0119ksz\u0105 elastyczno\u015b\u0107, wi\u0119ksz\u0105 \u0142atwo\u015b\u0107 wymiany implementacji, wi\u0119ksz\u0105 generyczno\u015b\u0107, kt\u00f3ra pozwoli nam w przysz\u0142o\u015bci \u0142atwiej wprowadzi\u0107 now\u0105 funkcjonalno\u015b\u0107. Dobrym przyk\u0142adem mo\u017ce by\u0107 zamiana instrukcji warunkowych na enumy.<\/p>\n\n\n\n
Przyk\u0142ad<\/strong><\/h3>\n\n\n\nPrzeanalizujmy przyk\u0142ad, w kt\u00f3rym mamy do obs\u0142ugi nowe API. W ramach przyk\u0142adu API ma dost\u0119pne tylko metody typu CRUD, kt\u00f3re przyjmuj\u0105 odpowiedni obiekt implementuj\u0105cy InformationType w zale\u017cno\u015bci od rodzaju operacji. Za\u0142\u00f3\u017cmy, \u017ce w tym momencie jeste\u015bmy na etapie implementacji uzupe\u0142niania danych do metod API. Najprostszym rozwi\u0105zaniem by\u0142oby obs\u0142u\u017cenie go za pomoc\u0105 if\u00f3w\/switch\u00f3w.<\/p>\n\n\n\n
![\"przyk\u0142ad](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/05\/1-1.png\")
<\/a><\/figure><\/div>\n\n\n\nNie s\u0105 to jednak zbyt dobre rozwi\u0105zania. Dodajemy nowy kod oparty na instrukcjach warunkowych \u2013ifach, switach, co nie jest najlepszym i czytelnym podej\u015bciem, poniewa\u017c taki kod prawdopodobnie b\u0119dzie si\u0119 rozrasta\u0142 w przysz\u0142o\u015bci. Osoba pisz\u0105ca kod b\u0119dzie dodawa\u0107 kolejne instrukcje warunkowe, co pogorszy jako\u015b\u0107, czytelno\u015b\u0107 i skomplikowanie logiki, jak i test\u00f3w. Innym mo\u017cliwym rozwi\u0105zaniem mo\u017ce by\u0107 zastosowanie np. wzorca Chain of Responsibility.<\/p>\n\n\n\n
Cz\u0119sto zdarza si\u0119, \u017ce firma wystawiaj\u0105ca API wprowadza nowe wersje, modyfikuj\u0105c przy tym m.in. wej\u015bciowe struktury danych. Powy\u017cszy kod da si\u0119 zast\u0105pi\u0107 przy pomocy enuma, nie u\u017cywaj\u0105c instrukcji warunkowych.<\/strong> W przysz\u0142o\u015bci pozwoli na \u0142atwiejsze ponowne wykorzystanie zaimplementowanego mechanizmu lub rozszerzenie go na nowe wersje, funkcjonalno\u015bci danego API.<\/p>\n\n\n\n![\"Zast\u0105pienie](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/05\/2-1.png\")
<\/a><\/figure><\/div>\n\n\n\nCa\u0142e wywo\u0142anie b\u0119dzie wygl\u0105da\u0107 nast\u0119puj\u0105co:<\/p>\n\n\n\n
![\"Gotowy](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/05\/3-1.png\")
<\/a><\/figure><\/div>\n\n\n\nCa\u0142y kod mo\u017cna znale\u017a\u0107 tutaj<\/a>. W tym miejscu warto zatrzyma\u0107 si\u0119 na chwil\u0119 i zastanowi\u0107, czy oczekiwany rezultat z zastosowania enuma nie jest tak naprawd\u0119 odpowiedz\u0105, dlaczego decydujemy si\u0119 po\u015bwi\u0119ci\u0107 czas na refaktoryzacj\u0119. Dlaczego to robimy? Odpowied\u017a jest prosta \u2013 tak, to w\u0142a\u015bnie g\u0142\u00f3wny cel refaktoringu.<\/p>\n\n\n\nRefaktoryzacja \u2013 wa\u017cne kwestie<\/strong><\/h2>\n\n\n\nZastanawiaj\u0105c si\u0119 dalej nad refaktoringiem, zapewne pojawi\u0105 si\u0119 kolejne w\u0105tpliwo\u015bci:<\/p>\n\n\n\n
- Kiedy dokonujemy refaktoryzacji?<\/li>
- Czy zatrzymujemy si\u0119, chc\u0105c dokona\u0107 refaktoryzacji i przez d\u0142ugie dni\/tygodnie nie robimy nic nowego, aby m\u00f3c wykona\u0107 refaktoryzacj\u0119? Czy mo\u017ce jednak jest to co\u015b, co powinni\u015bmy wykonywa\u0107 na bie\u017c\u0105co?<\/li>
- Kto powinien robi\u0107 refaktoryzacj\u0119? Wyznaczone osoby, czy mo\u017ce wszyscy?<\/li>
- Czy jest \u201clepszy\u201d moment, aby refaktoryzowa\u0107?<\/li>
- Czy wzorce projektowe to wszystko, czego potrzebujemy do refaktoryzacji?<\/li><\/ul>\n\n\n\n
Odpowiedzi na te pytania mog\u0105 nie by\u0107 zawsze jasne, jednak w dzisiejszych czasach si\u0119 ustabilizowa\u0142y. W wi\u0119kszo\u015bci przypadk\u00f3w jako dobr\u0105 praktyk\u0119 refaktoryzacji, powinni\u015bmy j\u0105 przeprowadza\u0107 w spos\u00f3b ci\u0105g\u0142y. Powinien j\u0105 robi\u0107 ka\u017cdy w zespole, ka\u017cdego dnia.<\/p>\n\n\n\n
Kiedy jest najlepszy czas na refaktoryzacj\u0119?<\/strong><\/h2>\n\n\n\nGdy planujemy doda\u0107 do naszego kodu now\u0105 funkcj\u0119<\/strong><\/p>\n\n\n\nMo\u017cemy wtedy zastanowi\u0107 si\u0119, czy nie da\u0142oby si\u0119 go wprowadzi\u0107 \u0142atwiej\/szybciej, gdyby najpierw wprowadzi\u0107 poprawki w kodzie. Lepszy kod pozwoli\u0142by napisa\u0107 \u201c\u0142atwe\u201d testy. Takie podej\u015bcie proponuj\u0105 mi\u0119dzy innymi Martin Fowler i Kent Beck w jednej ze swoich ksi\u0105\u017cek.<\/p>\n\n\n\n
Po zako\u0144czeniu implementacji danej funkcji<\/strong><\/p>\n\n\n\nTen moment wydaje si\u0119 by\u0107 zupe\u0142nie naturalny i prawdopodobnie jest to podej\u015bcie najcz\u0119\u015bciej stosowane przez osoby implementuj\u0105ce dane rozwi\u0105zanie. Jest on integralnym krokiem TDD. Mo\u017cemy si\u0119 wtedy na chwil\u0119 zatrzyma\u0107 i poprawi\u0107 napisany przed chwil\u0105 kod. Mamy wtedy gotow\u0105 i przetestowan\u0105 logik\u0119 nowej funkcjonalno\u015bci. Nieraz mo\u017cemy zauwa\u017cy\u0107, \u017ce cz\u0119\u015b\u0107 mogliby\u015bmy zrobi\u0107 lepiej\/ciekawiej pod k\u0105tem przysz\u0142ego utrzymania.<\/p>\n\n\n\n
Gdy poznajemy nowy kod<\/strong><\/p>\n\n\n\nZ czasem nawet utar\u0142y si\u0119 s\u0142owa, \u017ce osoby tworz\u0105ce oprogramowanie cz\u0119\u015bciej czytaj\u0105 kod ni\u017c go tworz\u0105 lub \u2013 dok\u0142adniej m\u00f3wi\u0105c \u2013 rozwijaj\u0105. Brak zrozumienia i utrzymania istniej\u0105cego kodu jest recept\u0105 na katastrof\u0119!<\/p>\n\n\n\n
Gdy ca\u0142y zesp\u00f3\u0142 prowadzi refaktoring przez kilka dni, a nawet d\u0142u\u017cej<\/strong><\/p>\n\n\n\nTaki moment powinien by\u0107 jednak wyj\u0105tkiem od regu\u0142y. Mo\u017ce si\u0119 zdarzy\u0107 np. gdy planujemy migracj\u0119 pomi\u0119dzy narz\u0119dziami. Kolokwialnie m\u00f3wi\u0105c, o kod powinni\u015bmy dba\u0107 tak, jak dbamy o porz\u0105dek w swoich domach, gdzie wynosimy \u015bmieci, sprz\u0105tamy co 2-3 dni.<\/p>\n\n\n\n
Dodatkowe wskaz\u00f3wki<\/strong><\/h2>\n\n\n\nCodzienne podnoszenie jako\u015bci, podejmowanie pewnych krok\u00f3w prze\u0142o\u017cy si\u0119 na to, \u017ce dodawanie nowych funkcjonalno\u015bci b\u0119dzie du\u017co szybsze, \u0142atwiejsze, sprawniejsze, co ostatecznie wp\u0142ynie na jako\u015b\u0107 kodu. Tutaj widzimy, \u017ce trudno m\u00f3wi\u0107 o refaktoryzacji, maj\u0105c du\u017ce sprz\u0119\u017cenie i nisk\u0105 sp\u00f3jno\u015b\u0107, czyli z\u0142y podzia\u0142 odpowiedzialno\u015bci.<\/p>\n\n\n\n
Id\u0105c dalej, mo\u017cemy powiedzie\u0107, \u017ce ju\u017c na tym poziomie mog\u0105 by\u0107 naruszone niekt\u00f3re z podstawowych dobrych praktyk pisania kodu \u2013 zasady SOLID[i]<\/a>, KISS[ii]<\/a>czy TDA[iii]<\/a>. Bez odpowiedniego podzia\u0142u odpowiedzialno\u015bci nie mamy czystego kodu, czyli ju\u017c na tym poziomie ci\u0119\u017cko m\u00f3wi\u0107 o refaktoryzacji.<\/p>\n\n\n\nDodatkowo, je\u015bli kod nie jest czysty, to zwykle nie mamy do niego test\u00f3w b\u0119d\u0105cych naszym zapleczem bezpiecze\u0144stwa. Tak naprawd\u0119 nie da si\u0119 pomin\u0105\u0107 \u017cadnego z tych trzech element\u00f3w \u2013<\/strong><\/p>\n\n\n\n- czystego kodu,<\/strong><\/li>
- refaktoryzacji,<\/strong><\/li>
- testowania.<\/strong><\/li><\/ul>\n\n\n\n
Nale\u017cy wykonywa\u0107 wszystko razem inaczej szybko mo\u017cna si\u0119 zniech\u0119ci\u0107, bo kt\u00f3ry\u015b z element\u00f3w mo\u017ce by\u0107 trudny do poprawnego zaimplementowania.<\/p>\n\n\n\n
Najwa\u017cniejsze jest to, aby osoba pracuj\u0105ca z kodem to wszystko wywa\u017cy\u0142a, poniewa\u017c czasami warto\u015b\u0107 korzy\u015bci b\u0119dzie niewielka, nawet niezauwa\u017calna. M\u00f3wi\u0105c inaczej, po co robi\u0107 bardziej generyczny kod teraz, skoro by\u0107 mo\u017ce w przysz\u0142o\u015bci nikt nie b\u0119dzie go potrzebowa\u0142. Nale\u017cy uwa\u017ca\u0107, aby nie popa\u015b\u0107 w pu\u0142apk\u0119 robienia zbyt elastycznego rozwi\u0105zania. Nale\u017cy robi\u0107 rzeczy iteracyjnie, gdy\u017c cz\u0119sto warto poczeka\u0107, ze zmianami, a\u017c pewne rzeczy stan\u0105 si\u0119 jasne. Dok\u0142adniej m\u00f3wi nam o tym zasada YAGNI[iv]<\/a>.<\/p>\n\n\n\nNale\u017cy jednak pami\u0119ta\u0107, \u017ce wprowadzaj\u0105c refaktoryzacj\u0119, nie wprowadzamy nowych funkcjonalno\u015bci, co od razu stawia zasad\u0119, \u017ce refactoring musi by\u0107 bezpieczny. Refaktoryzacja w oderwaniu od test\u00f3w, czystego kodu, dobrej architektury i wielu innych czynnik\u00f3w b\u0119dzie mia\u0142a bardzo ma\u0142y sens. Recept\u0105 na niez\u0142amanie wspomnianej przed chwil\u0105 zasady jest istnienie dobrych test\u00f3w. W przeciwnym wypadku refaktoryzacja mo\u017ce sta\u0107 si\u0119 bardzo trudna i niebezpieczna.<\/strong> Mo\u017ce si\u0119 te\u017c okaza\u0107, \u017ce b\u0119dzie mia\u0142a ona niewielki sens oraz b\u0119dzie du\u017co bardziej kosztowna ni\u017c gdyby\u015bmy si\u0119 jej nie podj\u0119li.<\/p>\n\n\n\nSyndromy Code Smells<\/strong><\/h2>\n\n\n\nWiemy ju\u017c, przynajmniej w teorii, jak i kiedy wykonywa\u0107 refaktoryzacj\u0119, ale z drugiej strony mamy syndromy, na kt\u00f3re musimy by\u0107 wyczuleni. Potocznie zwane code smell<\/strong>, kt\u00f3re powinny by\u0107 ostrze\u017ceniem, \u017ce co\u015b jest nie tak. Wiele z nich jest zupe\u0142nie naturalnych, stosowanych na co dzie\u0144, np. z\u0142e nazewnictwo, prze\u0142adowanie odpowiedzialno\u015bci.<\/p>\n\n\n\nZapami\u0119tanie wszystkich code smells mo\u017ce by\u0107 problematyczne. Znacz\u0105co lepiej jest najpierw si\u0119 z nimi zapozna\u0107, a gdy pojawi si\u0119 problem odszuka\u0107 dany code smell i sprawdzi\u0107, jak najlepiej sobie z nim poradzi\u0107. Wi\u0119cej szczeg\u00f3\u0142\u00f3w mo\u017cna przeczyta\u0107 na stronie sourcemaking<\/a>. Pisa\u0142 o tym nawet autor wymienionych artyku\u0142\u00f3w i ksi\u0105\u017cki.<\/p>\n\n\n\nWymienienie i opisanie wszystkich code smells to temat na osobny artyku\u0142. Dla dok\u0142adnego zapoznania si\u0119 z poni\u017cszymi polecam artyku\u0142 o technikach refaktoringu i bad code smells.<\/a><\/p>\n\n\n\nZestaw najcz\u0119stszych code smells\/przyczyn niskiej jako\u015bci kodu<\/strong><\/h3>\n\n\n\n- Brak trzymania si\u0119 zasad SOLID, KISS \u2013 przesada z abstrakcjami, YAGNI, DRY[v]<\/a>, TDA itp.<\/li>
- Obsesja na punkcie typ\u00f3w prymitywnych, co powoduje, \u017ce kod jest mniej obiektowy. Mo\u017ce przypomina\u0107 podej\u015bcie proceduralne co cz\u0119sto przek\u0142ada si\u0119 na ifowanie, switchowanie zamiast polimorfizmu. Przyk\u0142ad, jak tego unika\u0107 by\u0142 om\u00f3wiony wcze\u015bniej, np. MovieType<\/a>.<\/li>
- Z\u0142e zaprojektowanie systemu na poziomie obiekt\u00f3w. Zbyt d\u0142uga lista argument\u00f3w. Maksymalna rekomendowana ilo\u015b\u0107 to 3.<\/li>
- Mo\u017ce si\u0119 zdarzy\u0107, \u017ce mamy duplikacj\u0119 kodu w r\u00f3\u017cnych cz\u0119\u015bciach kodu, czyli mamy r\u00f3\u017cne klasy, r\u00f3\u017cne kontrakty, ale powt\u00f3rzon\u0105 logik\u0119 w metodach klas.<\/li>
- Nieodpowiednia segregacja odpowiedzialno\u015bci. Wprowadzenie jednej funkcji powoduje zmiany w wielu miejscach, klasach, typach.<\/li>
- Brak dobrych test\u00f3w, brak pokrycia kodu testami.<\/li>
- Brak wstrzykiwania zale\u017cno\u015bci.<\/li>
- Nadu\u017cywanie programowania imperatywnego, a dok\u0142adniej prze\u0142adowanie ifami, switachami.<\/li>
- Instancyjne pola tymczasowe zamiast zmiennych lokalnych w metodach.<\/li>
- Du\u017ce sprz\u0119\u017cenie i niska sp\u00f3jno\u015b\u0107:
- Sprz\u0119\u017cenie \u2013 inaczej m\u00f3wi\u0105c si\u0142a z jak\u0105 wsp\u00f3\u0142pracuj\u0105 elementy. Nie wa\u017cne czy to metoda, komponent czy mo\u017ce mikroserwis. Im wi\u0119ksze sprz\u0119\u017cenie, powi\u0105zanie tym wi\u0119ksze k\u0142opoty patrz\u0105c pod k\u0105tem refaktoryzacji, zmian, utrzymania, testowania. Nale\u017cy d\u0105\u017cy\u0107 do jak najmniejszego sprz\u0119\u017cenia.<\/li>
- Sp\u00f3jno\u015b\u0107 \u2013 kohezja, czyli d\u0105\u017cymy do tego, aby komponent, serwis skupia\u0142 si\u0119 na jednej dobrze zdefiniowanej rzeczy. Im wi\u0119ksza sp\u00f3jno\u015b\u0107 tym lepiej.<\/li><\/ul><\/li>
- B\u0142\u0119dy pope\u0142niane na poziomie analizy, projektowania oraz implementacji.<\/li>
- Nieodpowiednie zarz\u0105dzanie zasobami \u2013 presja czasu, zbyt ma\u0142o ludzi w zespole, z\u0142a estymacja.<\/li>
- Z\u0142o\u017cono\u015b\u0107 problem\u00f3w \u2013 dodawanie nowych funkcjonalno\u015bci, ka\u017cdy rozw\u00f3j bez refaktoringu b\u0119dzie wprowadza\u0107 chaos.<\/li>
- Brak dba\u0142o\u015bci o czytelno\u015b\u0107 kodu:
- Z\u0142e nazewnictwo.<\/li>
- Zbyt d\u0142ugie funkcje\/metody.<\/li><\/ul><\/li>
- Niepoprawne funkcje\/metody:
- Przyjmowanie\/zwracanie nulli z metod zamiast opakowa\u0144 zwracanych typ\u00f3w w Optionale \u2013 k\u0142amanie na poziomie kodu innych programist\u00f3w.<\/li><\/ul><\/li>
- Niepoprawne dopasowanie wyj\u0105tk\u00f3w do warstwy aplikacji, np. IOException znajduje si\u0119 w warstwie biznesowej, restowej.<\/li>
- Brak programowania przez kontrakty.<\/li>
- Stosowanie mutowanych obiekt\u00f3w, kt\u00f3re mo\u017cna zast\u0105pi\u0107 niemutowanymi.<\/li>
- Stosowanie statycznych p\u00f3l, klas, metod w nieodpowiedni spos\u00f3b.<\/li><\/ul>\n\n\n\n
Wzorce projektowe<\/strong><\/h2>\n\n\n\nNale\u017cy pami\u0119ta\u0107, \u017ce znajomo\u015b\u0107 wzorc\u00f3w projektowych do refaktoryzacji nie wystarczy. Wzorce s\u0105 jedynie otoczk\u0105, kt\u00f3r\u0105 widzimy, co r\u00f3wnie\u017c jest bardzo wa\u017cne. Mo\u017cna powiedzie\u0107, \u017ce wzorce s\u0105 realizacj\u0105 za\u0142o\u017ce\u0144 opisanych powy\u017cej<\/strong>, co mo\u017cna \u0142atwo zaobserwowa\u0107 na przyk\u0142adzie wzorca Proxy.<\/p>\n\n\n\nMo\u017cemy sobie wyobrazi\u0107, \u017ce mamy metod\u0119 o nazwie transferFunds. Obs\u0142uguje ona przelew mi\u0119dzy dwoma kontami zgodnie z logik\u0105 biznesow\u0105. Jednak w przypadku takiej metody bardzo cz\u0119sto mo\u017ce si\u0119 zdarzy\u0107, \u017ce musimy otworzy\u0107, zamkn\u0105\u0107 transakcje, sprawdzi\u0107 jakie\u015b regu\u0142y bezpiecze\u0144stwa, zalogowa\u0107, \u017ce nast\u0105pi\u0142 przelew. Nagle okazuje si\u0119, \u017ce nazwa metody nie odpowiada temu, co w \u015brodku si\u0119 dzieje. Mamy nadu\u017cycie, przedobrzenie, robimy wi\u0119cej ni\u017c powinni\u015bmy. M\u00f3wi\u0105c dosadniej, to k\u0142amiemy ju\u017c na etapie nazwy metody.<\/p>\n\n\n\n
Aby tego unikn\u0105\u0107, nale\u017cy dokona\u0107 separacji odpowiedzialno\u015bci, opakowa\u0107 kod poprzez ustanowienie po\u015brednika \u2013 Proxy.<\/p>\n\n\n\n
Przyk\u0142ady grup najcz\u0119\u015bciej spotykanych wzorc\u00f3w projektowych z kr\u00f3tkim opisem<\/strong><\/h3>\n\n\n\n- Kreacyjne \u2013 pokazuj\u0105 spos\u00f3b tworzenia metod, klas oraz typ\u00f3w danych.
- Singleton,<\/li>
- Builder,<\/li>
- Factory.<\/li><\/ul><\/li>
- Strukturalne \u2013 zale\u017cno\u015bci powi\u0105zanych ze sob\u0105 obiekt\u00f3w.
- Decorator,<\/li>
- Proxy (pe\u0142nomocnik),<\/li>
- Facade,<\/li>
- Chain of Responsibility.<\/li><\/ul><\/li>
- Behawioralne \u2013 zachowania wsp\u00f3\u0142pracuj\u0105cych obiekt\u00f3w.
- Visitor,<\/li>
- Observer,<\/li>
- Strategy,<\/li>
- Adapter.<\/li><\/ul><\/li><\/ul>\n\n\n\n
Przyk\u0142ady z dok\u0142adniejszym opisaniem wzorc\u00f3w projektowych.<\/a><\/p>\n\n\n\nNa koniec zach\u0119cam Was do zrobienia zadania b\u0119d\u0105cego samodzieln\u0105 pr\u00f3b\u0105 refaktoringu<\/a>.<\/p>\n\n\n\n\u0179r\u00f3d\u0142a<\/strong><\/h2>\n\n\n\n- Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck<\/li>
- bykowski.pl\/wzorce-projektowe<\/a><\/li>
- Sourcemaking.com<\/a><\/li>
- refactoring.guru<\/a><\/li><\/ul>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n[i]<\/a> podstawowych zasad, kt\u00f3rymi nale\u017cy si\u0119 kierowa\u0107 podczas programowania obiektowo. Skr\u00f3t pochodzi od pierwszych liter poszczeg\u00f3lnych zasad, s\u0105 to: single responsibility, open\/closed, liskov substitution, interface segregation oraz dependency inversion<\/p>\n\n\n\n[ii]<\/a> keep it simple stupid – nasz kod powinien by\u0107 tworzony i utrzymany w taki spos\u00f3b, aby by\u0142 dla wszystkich jak najbardziej zrozumia\u0142y i jasny<\/p>\n\n\n\n[iii]<\/a> tell don\u2019t ask \u2013 zasada m\u00f3wi o konkretnym podziale obowi\u0105zk\u00f3w pomi\u0119dzy naszymi klasami i obiektami, a ich zadaniami<\/p>\n\n\n\n[iv]<\/a> you ain\u2019t gonna need it \u2013 zasada m\u00f3wi, \u017ce w naszym programie powinni\u015bmy umieszcza\u0107 najistotniejsze funkcjonalno\u015bci, kt\u00f3re w danej chwili b\u0119d\u0105 nam potrzebne<\/p>\n\n\n\n[v]<\/a> don\u2019t repeat yourself \u2013 nale\u017cy unika\u0107 powtarzania tych samych cz\u0119\u015bci kodu w r\u00f3\u017cnych miejscach<\/p>\n\n\n\n***<\/p>\n\n\n\n
Je\u017celi temat refaktoryzacji jest dla Ciebie interesuj\u0105cy, polecamy r\u00f3wnie\u017c inny artyku\u0142 naszego eksperta: Podej\u015bcie do refaktoryzacji w projekcie ze starymi technologiami<\/a><\/p>\n\n\n
Z drugiej strony, z ka\u017cd\u0105 zmian\u0105 mo\u017cemy co\u015b zyska\u0107. By\u0107 mo\u017ce wi\u0119ksz\u0105 elastyczno\u015b\u0107, wi\u0119ksz\u0105 \u0142atwo\u015b\u0107 wymiany implementacji, wi\u0119ksz\u0105 generyczno\u015b\u0107, kt\u00f3ra pozwoli nam w przysz\u0142o\u015bci \u0142atwiej wprowadzi\u0107 now\u0105 funkcjonalno\u015b\u0107. Dobrym przyk\u0142adem mo\u017ce by\u0107 zamiana instrukcji warunkowych na enumy.<\/p>\n\n\n\n
Przyk\u0142ad<\/strong><\/h3>\n\n\n\nPrzeanalizujmy przyk\u0142ad, w kt\u00f3rym mamy do obs\u0142ugi nowe API. W ramach przyk\u0142adu API ma dost\u0119pne tylko metody typu CRUD, kt\u00f3re przyjmuj\u0105 odpowiedni obiekt implementuj\u0105cy InformationType w zale\u017cno\u015bci od rodzaju operacji. Za\u0142\u00f3\u017cmy, \u017ce w tym momencie jeste\u015bmy na etapie implementacji uzupe\u0142niania danych do metod API. Najprostszym rozwi\u0105zaniem by\u0142oby obs\u0142u\u017cenie go za pomoc\u0105 if\u00f3w\/switch\u00f3w.<\/p>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\nNie s\u0105 to jednak zbyt dobre rozwi\u0105zania. Dodajemy nowy kod oparty na instrukcjach warunkowych \u2013ifach, switach, co nie jest najlepszym i czytelnym podej\u015bciem, poniewa\u017c taki kod prawdopodobnie b\u0119dzie si\u0119 rozrasta\u0142 w przysz\u0142o\u015bci. Osoba pisz\u0105ca kod b\u0119dzie dodawa\u0107 kolejne instrukcje warunkowe, co pogorszy jako\u015b\u0107, czytelno\u015b\u0107 i skomplikowanie logiki, jak i test\u00f3w. Innym mo\u017cliwym rozwi\u0105zaniem mo\u017ce by\u0107 zastosowanie np. wzorca Chain of Responsibility.<\/p>\n\n\n\n
Cz\u0119sto zdarza si\u0119, \u017ce firma wystawiaj\u0105ca API wprowadza nowe wersje, modyfikuj\u0105c przy tym m.in. wej\u015bciowe struktury danych. Powy\u017cszy kod da si\u0119 zast\u0105pi\u0107 przy pomocy enuma, nie u\u017cywaj\u0105c instrukcji warunkowych.<\/strong> W przysz\u0142o\u015bci pozwoli na \u0142atwiejsze ponowne wykorzystanie zaimplementowanego mechanizmu lub rozszerzenie go na nowe wersje, funkcjonalno\u015bci danego API.<\/p>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\nCa\u0142e wywo\u0142anie b\u0119dzie wygl\u0105da\u0107 nast\u0119puj\u0105co:<\/p>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\nCa\u0142y kod mo\u017cna znale\u017a\u0107 tutaj<\/a>. W tym miejscu warto zatrzyma\u0107 si\u0119 na chwil\u0119 i zastanowi\u0107, czy oczekiwany rezultat z zastosowania enuma nie jest tak naprawd\u0119 odpowiedz\u0105, dlaczego decydujemy si\u0119 po\u015bwi\u0119ci\u0107 czas na refaktoryzacj\u0119. Dlaczego to robimy? Odpowied\u017a jest prosta \u2013 tak, to w\u0142a\u015bnie g\u0142\u00f3wny cel refaktoringu.<\/p>\n\n\n\nRefaktoryzacja \u2013 wa\u017cne kwestie<\/strong><\/h2>\n\n\n\nZastanawiaj\u0105c si\u0119 dalej nad refaktoringiem, zapewne pojawi\u0105 si\u0119 kolejne w\u0105tpliwo\u015bci:<\/p>\n\n\n\n
- Kiedy dokonujemy refaktoryzacji?<\/li>
- Czy zatrzymujemy si\u0119, chc\u0105c dokona\u0107 refaktoryzacji i przez d\u0142ugie dni\/tygodnie nie robimy nic nowego, aby m\u00f3c wykona\u0107 refaktoryzacj\u0119? Czy mo\u017ce jednak jest to co\u015b, co powinni\u015bmy wykonywa\u0107 na bie\u017c\u0105co?<\/li>
- Kto powinien robi\u0107 refaktoryzacj\u0119? Wyznaczone osoby, czy mo\u017ce wszyscy?<\/li>
- Czy jest \u201clepszy\u201d moment, aby refaktoryzowa\u0107?<\/li>
- Czy wzorce projektowe to wszystko, czego potrzebujemy do refaktoryzacji?<\/li><\/ul>\n\n\n\n
Odpowiedzi na te pytania mog\u0105 nie by\u0107 zawsze jasne, jednak w dzisiejszych czasach si\u0119 ustabilizowa\u0142y. W wi\u0119kszo\u015bci przypadk\u00f3w jako dobr\u0105 praktyk\u0119 refaktoryzacji, powinni\u015bmy j\u0105 przeprowadza\u0107 w spos\u00f3b ci\u0105g\u0142y. Powinien j\u0105 robi\u0107 ka\u017cdy w zespole, ka\u017cdego dnia.<\/p>\n\n\n\n
Kiedy jest najlepszy czas na refaktoryzacj\u0119?<\/strong><\/h2>\n\n\n\nGdy planujemy doda\u0107 do naszego kodu now\u0105 funkcj\u0119<\/strong><\/p>\n\n\n\nMo\u017cemy wtedy zastanowi\u0107 si\u0119, czy nie da\u0142oby si\u0119 go wprowadzi\u0107 \u0142atwiej\/szybciej, gdyby najpierw wprowadzi\u0107 poprawki w kodzie. Lepszy kod pozwoli\u0142by napisa\u0107 \u201c\u0142atwe\u201d testy. Takie podej\u015bcie proponuj\u0105 mi\u0119dzy innymi Martin Fowler i Kent Beck w jednej ze swoich ksi\u0105\u017cek.<\/p>\n\n\n\n
Po zako\u0144czeniu implementacji danej funkcji<\/strong><\/p>\n\n\n\nTen moment wydaje si\u0119 by\u0107 zupe\u0142nie naturalny i prawdopodobnie jest to podej\u015bcie najcz\u0119\u015bciej stosowane przez osoby implementuj\u0105ce dane rozwi\u0105zanie. Jest on integralnym krokiem TDD. Mo\u017cemy si\u0119 wtedy na chwil\u0119 zatrzyma\u0107 i poprawi\u0107 napisany przed chwil\u0105 kod. Mamy wtedy gotow\u0105 i przetestowan\u0105 logik\u0119 nowej funkcjonalno\u015bci. Nieraz mo\u017cemy zauwa\u017cy\u0107, \u017ce cz\u0119\u015b\u0107 mogliby\u015bmy zrobi\u0107 lepiej\/ciekawiej pod k\u0105tem przysz\u0142ego utrzymania.<\/p>\n\n\n\n
Gdy poznajemy nowy kod<\/strong><\/p>\n\n\n\nZ czasem nawet utar\u0142y si\u0119 s\u0142owa, \u017ce osoby tworz\u0105ce oprogramowanie cz\u0119\u015bciej czytaj\u0105 kod ni\u017c go tworz\u0105 lub \u2013 dok\u0142adniej m\u00f3wi\u0105c \u2013 rozwijaj\u0105. Brak zrozumienia i utrzymania istniej\u0105cego kodu jest recept\u0105 na katastrof\u0119!<\/p>\n\n\n\n
Gdy ca\u0142y zesp\u00f3\u0142 prowadzi refaktoring przez kilka dni, a nawet d\u0142u\u017cej<\/strong><\/p>\n\n\n\nTaki moment powinien by\u0107 jednak wyj\u0105tkiem od regu\u0142y. Mo\u017ce si\u0119 zdarzy\u0107 np. gdy planujemy migracj\u0119 pomi\u0119dzy narz\u0119dziami. Kolokwialnie m\u00f3wi\u0105c, o kod powinni\u015bmy dba\u0107 tak, jak dbamy o porz\u0105dek w swoich domach, gdzie wynosimy \u015bmieci, sprz\u0105tamy co 2-3 dni.<\/p>\n\n\n\n
Dodatkowe wskaz\u00f3wki<\/strong><\/h2>\n\n\n\nCodzienne podnoszenie jako\u015bci, podejmowanie pewnych krok\u00f3w prze\u0142o\u017cy si\u0119 na to, \u017ce dodawanie nowych funkcjonalno\u015bci b\u0119dzie du\u017co szybsze, \u0142atwiejsze, sprawniejsze, co ostatecznie wp\u0142ynie na jako\u015b\u0107 kodu. Tutaj widzimy, \u017ce trudno m\u00f3wi\u0107 o refaktoryzacji, maj\u0105c du\u017ce sprz\u0119\u017cenie i nisk\u0105 sp\u00f3jno\u015b\u0107, czyli z\u0142y podzia\u0142 odpowiedzialno\u015bci.<\/p>\n\n\n\n
Id\u0105c dalej, mo\u017cemy powiedzie\u0107, \u017ce ju\u017c na tym poziomie mog\u0105 by\u0107 naruszone niekt\u00f3re z podstawowych dobrych praktyk pisania kodu \u2013 zasady SOLID[i]<\/a>, KISS[ii]<\/a>czy TDA[iii]<\/a>. Bez odpowiedniego podzia\u0142u odpowiedzialno\u015bci nie mamy czystego kodu, czyli ju\u017c na tym poziomie ci\u0119\u017cko m\u00f3wi\u0107 o refaktoryzacji.<\/p>\n\n\n\nDodatkowo, je\u015bli kod nie jest czysty, to zwykle nie mamy do niego test\u00f3w b\u0119d\u0105cych naszym zapleczem bezpiecze\u0144stwa. Tak naprawd\u0119 nie da si\u0119 pomin\u0105\u0107 \u017cadnego z tych trzech element\u00f3w \u2013<\/strong><\/p>\n\n\n\n- czystego kodu,<\/strong><\/li>
- refaktoryzacji,<\/strong><\/li>
- testowania.<\/strong><\/li><\/ul>\n\n\n\n
Nale\u017cy wykonywa\u0107 wszystko razem inaczej szybko mo\u017cna si\u0119 zniech\u0119ci\u0107, bo kt\u00f3ry\u015b z element\u00f3w mo\u017ce by\u0107 trudny do poprawnego zaimplementowania.<\/p>\n\n\n\n
Najwa\u017cniejsze jest to, aby osoba pracuj\u0105ca z kodem to wszystko wywa\u017cy\u0142a, poniewa\u017c czasami warto\u015b\u0107 korzy\u015bci b\u0119dzie niewielka, nawet niezauwa\u017calna. M\u00f3wi\u0105c inaczej, po co robi\u0107 bardziej generyczny kod teraz, skoro by\u0107 mo\u017ce w przysz\u0142o\u015bci nikt nie b\u0119dzie go potrzebowa\u0142. Nale\u017cy uwa\u017ca\u0107, aby nie popa\u015b\u0107 w pu\u0142apk\u0119 robienia zbyt elastycznego rozwi\u0105zania. Nale\u017cy robi\u0107 rzeczy iteracyjnie, gdy\u017c cz\u0119sto warto poczeka\u0107, ze zmianami, a\u017c pewne rzeczy stan\u0105 si\u0119 jasne. Dok\u0142adniej m\u00f3wi nam o tym zasada YAGNI[iv]<\/a>.<\/p>\n\n\n\nNale\u017cy jednak pami\u0119ta\u0107, \u017ce wprowadzaj\u0105c refaktoryzacj\u0119, nie wprowadzamy nowych funkcjonalno\u015bci, co od razu stawia zasad\u0119, \u017ce refactoring musi by\u0107 bezpieczny. Refaktoryzacja w oderwaniu od test\u00f3w, czystego kodu, dobrej architektury i wielu innych czynnik\u00f3w b\u0119dzie mia\u0142a bardzo ma\u0142y sens. Recept\u0105 na niez\u0142amanie wspomnianej przed chwil\u0105 zasady jest istnienie dobrych test\u00f3w. W przeciwnym wypadku refaktoryzacja mo\u017ce sta\u0107 si\u0119 bardzo trudna i niebezpieczna.<\/strong> Mo\u017ce si\u0119 te\u017c okaza\u0107, \u017ce b\u0119dzie mia\u0142a ona niewielki sens oraz b\u0119dzie du\u017co bardziej kosztowna ni\u017c gdyby\u015bmy si\u0119 jej nie podj\u0119li.<\/p>\n\n\n\nSyndromy Code Smells<\/strong><\/h2>\n\n\n\nWiemy ju\u017c, przynajmniej w teorii, jak i kiedy wykonywa\u0107 refaktoryzacj\u0119, ale z drugiej strony mamy syndromy, na kt\u00f3re musimy by\u0107 wyczuleni. Potocznie zwane code smell<\/strong>, kt\u00f3re powinny by\u0107 ostrze\u017ceniem, \u017ce co\u015b jest nie tak. Wiele z nich jest zupe\u0142nie naturalnych, stosowanych na co dzie\u0144, np. z\u0142e nazewnictwo, prze\u0142adowanie odpowiedzialno\u015bci.<\/p>\n\n\n\nZapami\u0119tanie wszystkich code smells mo\u017ce by\u0107 problematyczne. Znacz\u0105co lepiej jest najpierw si\u0119 z nimi zapozna\u0107, a gdy pojawi si\u0119 problem odszuka\u0107 dany code smell i sprawdzi\u0107, jak najlepiej sobie z nim poradzi\u0107. Wi\u0119cej szczeg\u00f3\u0142\u00f3w mo\u017cna przeczyta\u0107 na stronie sourcemaking<\/a>. Pisa\u0142 o tym nawet autor wymienionych artyku\u0142\u00f3w i ksi\u0105\u017cki.<\/p>\n\n\n\nWymienienie i opisanie wszystkich code smells to temat na osobny artyku\u0142. Dla dok\u0142adnego zapoznania si\u0119 z poni\u017cszymi polecam artyku\u0142 o technikach refaktoringu i bad code smells.<\/a><\/p>\n\n\n\nZestaw najcz\u0119stszych code smells\/przyczyn niskiej jako\u015bci kodu<\/strong><\/h3>\n\n\n\n- Brak trzymania si\u0119 zasad SOLID, KISS \u2013 przesada z abstrakcjami, YAGNI, DRY[v]<\/a>, TDA itp.<\/li>
- Obsesja na punkcie typ\u00f3w prymitywnych, co powoduje, \u017ce kod jest mniej obiektowy. Mo\u017ce przypomina\u0107 podej\u015bcie proceduralne co cz\u0119sto przek\u0142ada si\u0119 na ifowanie, switchowanie zamiast polimorfizmu. Przyk\u0142ad, jak tego unika\u0107 by\u0142 om\u00f3wiony wcze\u015bniej, np. MovieType<\/a>.<\/li>
- Z\u0142e zaprojektowanie systemu na poziomie obiekt\u00f3w. Zbyt d\u0142uga lista argument\u00f3w. Maksymalna rekomendowana ilo\u015b\u0107 to 3.<\/li>
- Mo\u017ce si\u0119 zdarzy\u0107, \u017ce mamy duplikacj\u0119 kodu w r\u00f3\u017cnych cz\u0119\u015bciach kodu, czyli mamy r\u00f3\u017cne klasy, r\u00f3\u017cne kontrakty, ale powt\u00f3rzon\u0105 logik\u0119 w metodach klas.<\/li>
- Nieodpowiednia segregacja odpowiedzialno\u015bci. Wprowadzenie jednej funkcji powoduje zmiany w wielu miejscach, klasach, typach.<\/li>
- Brak dobrych test\u00f3w, brak pokrycia kodu testami.<\/li>
- Brak wstrzykiwania zale\u017cno\u015bci.<\/li>
- Nadu\u017cywanie programowania imperatywnego, a dok\u0142adniej prze\u0142adowanie ifami, switachami.<\/li>
- Instancyjne pola tymczasowe zamiast zmiennych lokalnych w metodach.<\/li>
- Du\u017ce sprz\u0119\u017cenie i niska sp\u00f3jno\u015b\u0107:
- Sprz\u0119\u017cenie \u2013 inaczej m\u00f3wi\u0105c si\u0142a z jak\u0105 wsp\u00f3\u0142pracuj\u0105 elementy. Nie wa\u017cne czy to metoda, komponent czy mo\u017ce mikroserwis. Im wi\u0119ksze sprz\u0119\u017cenie, powi\u0105zanie tym wi\u0119ksze k\u0142opoty patrz\u0105c pod k\u0105tem refaktoryzacji, zmian, utrzymania, testowania. Nale\u017cy d\u0105\u017cy\u0107 do jak najmniejszego sprz\u0119\u017cenia.<\/li>
- Sp\u00f3jno\u015b\u0107 \u2013 kohezja, czyli d\u0105\u017cymy do tego, aby komponent, serwis skupia\u0142 si\u0119 na jednej dobrze zdefiniowanej rzeczy. Im wi\u0119ksza sp\u00f3jno\u015b\u0107 tym lepiej.<\/li><\/ul><\/li>
- B\u0142\u0119dy pope\u0142niane na poziomie analizy, projektowania oraz implementacji.<\/li>
- Nieodpowiednie zarz\u0105dzanie zasobami \u2013 presja czasu, zbyt ma\u0142o ludzi w zespole, z\u0142a estymacja.<\/li>
- Z\u0142o\u017cono\u015b\u0107 problem\u00f3w \u2013 dodawanie nowych funkcjonalno\u015bci, ka\u017cdy rozw\u00f3j bez refaktoringu b\u0119dzie wprowadza\u0107 chaos.<\/li>
- Brak dba\u0142o\u015bci o czytelno\u015b\u0107 kodu:
- Z\u0142e nazewnictwo.<\/li>
- Zbyt d\u0142ugie funkcje\/metody.<\/li><\/ul><\/li>
- Niepoprawne funkcje\/metody:
- Przyjmowanie\/zwracanie nulli z metod zamiast opakowa\u0144 zwracanych typ\u00f3w w Optionale \u2013 k\u0142amanie na poziomie kodu innych programist\u00f3w.<\/li><\/ul><\/li>
- Niepoprawne dopasowanie wyj\u0105tk\u00f3w do warstwy aplikacji, np. IOException znajduje si\u0119 w warstwie biznesowej, restowej.<\/li>
- Brak programowania przez kontrakty.<\/li>
- Stosowanie mutowanych obiekt\u00f3w, kt\u00f3re mo\u017cna zast\u0105pi\u0107 niemutowanymi.<\/li>
- Stosowanie statycznych p\u00f3l, klas, metod w nieodpowiedni spos\u00f3b.<\/li><\/ul>\n\n\n\n
Wzorce projektowe<\/strong><\/h2>\n\n\n\nNale\u017cy pami\u0119ta\u0107, \u017ce znajomo\u015b\u0107 wzorc\u00f3w projektowych do refaktoryzacji nie wystarczy. Wzorce s\u0105 jedynie otoczk\u0105, kt\u00f3r\u0105 widzimy, co r\u00f3wnie\u017c jest bardzo wa\u017cne. Mo\u017cna powiedzie\u0107, \u017ce wzorce s\u0105 realizacj\u0105 za\u0142o\u017ce\u0144 opisanych powy\u017cej<\/strong>, co mo\u017cna \u0142atwo zaobserwowa\u0107 na przyk\u0142adzie wzorca Proxy.<\/p>\n\n\n\nMo\u017cemy sobie wyobrazi\u0107, \u017ce mamy metod\u0119 o nazwie transferFunds. Obs\u0142uguje ona przelew mi\u0119dzy dwoma kontami zgodnie z logik\u0105 biznesow\u0105. Jednak w przypadku takiej metody bardzo cz\u0119sto mo\u017ce si\u0119 zdarzy\u0107, \u017ce musimy otworzy\u0107, zamkn\u0105\u0107 transakcje, sprawdzi\u0107 jakie\u015b regu\u0142y bezpiecze\u0144stwa, zalogowa\u0107, \u017ce nast\u0105pi\u0142 przelew. Nagle okazuje si\u0119, \u017ce nazwa metody nie odpowiada temu, co w \u015brodku si\u0119 dzieje. Mamy nadu\u017cycie, przedobrzenie, robimy wi\u0119cej ni\u017c powinni\u015bmy. M\u00f3wi\u0105c dosadniej, to k\u0142amiemy ju\u017c na etapie nazwy metody.<\/p>\n\n\n\n
Aby tego unikn\u0105\u0107, nale\u017cy dokona\u0107 separacji odpowiedzialno\u015bci, opakowa\u0107 kod poprzez ustanowienie po\u015brednika \u2013 Proxy.<\/p>\n\n\n\n
Przyk\u0142ady grup najcz\u0119\u015bciej spotykanych wzorc\u00f3w projektowych z kr\u00f3tkim opisem<\/strong><\/h3>\n\n\n\n- Kreacyjne \u2013 pokazuj\u0105 spos\u00f3b tworzenia metod, klas oraz typ\u00f3w danych.
- Singleton,<\/li>
- Builder,<\/li>
- Factory.<\/li><\/ul><\/li>
- Strukturalne \u2013 zale\u017cno\u015bci powi\u0105zanych ze sob\u0105 obiekt\u00f3w.
- Decorator,<\/li>
- Proxy (pe\u0142nomocnik),<\/li>
- Facade,<\/li>
- Chain of Responsibility.<\/li><\/ul><\/li>
- Behawioralne \u2013 zachowania wsp\u00f3\u0142pracuj\u0105cych obiekt\u00f3w.
- Visitor,<\/li>
- Observer,<\/li>
- Strategy,<\/li>
- Adapter.<\/li><\/ul><\/li><\/ul>\n\n\n\n
Przyk\u0142ady z dok\u0142adniejszym opisaniem wzorc\u00f3w projektowych.<\/a><\/p>\n\n\n\nNa koniec zach\u0119cam Was do zrobienia zadania b\u0119d\u0105cego samodzieln\u0105 pr\u00f3b\u0105 refaktoringu<\/a>.<\/p>\n\n\n\n\u0179r\u00f3d\u0142a<\/strong><\/h2>\n\n\n\n- Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck<\/li>
- bykowski.pl\/wzorce-projektowe<\/a><\/li>
- Sourcemaking.com<\/a><\/li>
- refactoring.guru<\/a><\/li><\/ul>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n[i]<\/a> podstawowych zasad, kt\u00f3rymi nale\u017cy si\u0119 kierowa\u0107 podczas programowania obiektowo. Skr\u00f3t pochodzi od pierwszych liter poszczeg\u00f3lnych zasad, s\u0105 to: single responsibility, open\/closed, liskov substitution, interface segregation oraz dependency inversion<\/p>\n\n\n\n[ii]<\/a> keep it simple stupid – nasz kod powinien by\u0107 tworzony i utrzymany w taki spos\u00f3b, aby by\u0142 dla wszystkich jak najbardziej zrozumia\u0142y i jasny<\/p>\n\n\n\n[iii]<\/a> tell don\u2019t ask \u2013 zasada m\u00f3wi o konkretnym podziale obowi\u0105zk\u00f3w pomi\u0119dzy naszymi klasami i obiektami, a ich zadaniami<\/p>\n\n\n\n[iv]<\/a> you ain\u2019t gonna need it \u2013 zasada m\u00f3wi, \u017ce w naszym programie powinni\u015bmy umieszcza\u0107 najistotniejsze funkcjonalno\u015bci, kt\u00f3re w danej chwili b\u0119d\u0105 nam potrzebne<\/p>\n\n\n\n[v]<\/a> don\u2019t repeat yourself \u2013 nale\u017cy unika\u0107 powtarzania tych samych cz\u0119\u015bci kodu w r\u00f3\u017cnych miejscach<\/p>\n\n\n\n***<\/p>\n\n\n\n
Je\u017celi temat refaktoryzacji jest dla Ciebie interesuj\u0105cy, polecamy r\u00f3wnie\u017c inny artyku\u0142 naszego eksperta: Podej\u015bcie do refaktoryzacji w projekcie ze starymi technologiami<\/a><\/p>\n\n\n
<\/a><\/figure><\/div>\n\n\n\nNie s\u0105 to jednak zbyt dobre rozwi\u0105zania. Dodajemy nowy kod oparty na instrukcjach warunkowych \u2013ifach, switach, co nie jest najlepszym i czytelnym podej\u015bciem, poniewa\u017c taki kod prawdopodobnie b\u0119dzie si\u0119 rozrasta\u0142 w przysz\u0142o\u015bci. Osoba pisz\u0105ca kod b\u0119dzie dodawa\u0107 kolejne instrukcje warunkowe, co pogorszy jako\u015b\u0107, czytelno\u015b\u0107 i skomplikowanie logiki, jak i test\u00f3w. Innym mo\u017cliwym rozwi\u0105zaniem mo\u017ce by\u0107 zastosowanie np. wzorca Chain of Responsibility.<\/p>\n\n\n\n
Cz\u0119sto zdarza si\u0119, \u017ce firma wystawiaj\u0105ca API wprowadza nowe wersje, modyfikuj\u0105c przy tym m.in. wej\u015bciowe struktury danych. Powy\u017cszy kod da si\u0119 zast\u0105pi\u0107 przy pomocy enuma, nie u\u017cywaj\u0105c instrukcji warunkowych.<\/strong> W przysz\u0142o\u015bci pozwoli na \u0142atwiejsze ponowne wykorzystanie zaimplementowanego mechanizmu lub rozszerzenie go na nowe wersje, funkcjonalno\u015bci danego API.<\/p>\n\n\n\n Ca\u0142e wywo\u0142anie b\u0119dzie wygl\u0105da\u0107 nast\u0119puj\u0105co:<\/p>\n\n\n\n Ca\u0142y kod mo\u017cna znale\u017a\u0107 tutaj<\/a>. W tym miejscu warto zatrzyma\u0107 si\u0119 na chwil\u0119 i zastanowi\u0107, czy oczekiwany rezultat z zastosowania enuma nie jest tak naprawd\u0119 odpowiedz\u0105, dlaczego decydujemy si\u0119 po\u015bwi\u0119ci\u0107 czas na refaktoryzacj\u0119. Dlaczego to robimy? Odpowied\u017a jest prosta \u2013 tak, to w\u0142a\u015bnie g\u0142\u00f3wny cel refaktoringu.<\/p>\n\n\n\n Zastanawiaj\u0105c si\u0119 dalej nad refaktoringiem, zapewne pojawi\u0105 si\u0119 kolejne w\u0105tpliwo\u015bci:<\/p>\n\n\n\n Odpowiedzi na te pytania mog\u0105 nie by\u0107 zawsze jasne, jednak w dzisiejszych czasach si\u0119 ustabilizowa\u0142y. W wi\u0119kszo\u015bci przypadk\u00f3w jako dobr\u0105 praktyk\u0119 refaktoryzacji, powinni\u015bmy j\u0105 przeprowadza\u0107 w spos\u00f3b ci\u0105g\u0142y. Powinien j\u0105 robi\u0107 ka\u017cdy w zespole, ka\u017cdego dnia.<\/p>\n\n\n\n Gdy planujemy doda\u0107 do naszego kodu now\u0105 funkcj\u0119<\/strong><\/p>\n\n\n\n Mo\u017cemy wtedy zastanowi\u0107 si\u0119, czy nie da\u0142oby si\u0119 go wprowadzi\u0107 \u0142atwiej\/szybciej, gdyby najpierw wprowadzi\u0107 poprawki w kodzie. Lepszy kod pozwoli\u0142by napisa\u0107 \u201c\u0142atwe\u201d testy. Takie podej\u015bcie proponuj\u0105 mi\u0119dzy innymi Martin Fowler i Kent Beck w jednej ze swoich ksi\u0105\u017cek.<\/p>\n\n\n\n Po zako\u0144czeniu implementacji danej funkcji<\/strong><\/p>\n\n\n\n Ten moment wydaje si\u0119 by\u0107 zupe\u0142nie naturalny i prawdopodobnie jest to podej\u015bcie najcz\u0119\u015bciej stosowane przez osoby implementuj\u0105ce dane rozwi\u0105zanie. Jest on integralnym krokiem TDD. Mo\u017cemy si\u0119 wtedy na chwil\u0119 zatrzyma\u0107 i poprawi\u0107 napisany przed chwil\u0105 kod. Mamy wtedy gotow\u0105 i przetestowan\u0105 logik\u0119 nowej funkcjonalno\u015bci. Nieraz mo\u017cemy zauwa\u017cy\u0107, \u017ce cz\u0119\u015b\u0107 mogliby\u015bmy zrobi\u0107 lepiej\/ciekawiej pod k\u0105tem przysz\u0142ego utrzymania.<\/p>\n\n\n\n Gdy poznajemy nowy kod<\/strong><\/p>\n\n\n\n Z czasem nawet utar\u0142y si\u0119 s\u0142owa, \u017ce osoby tworz\u0105ce oprogramowanie cz\u0119\u015bciej czytaj\u0105 kod ni\u017c go tworz\u0105 lub \u2013 dok\u0142adniej m\u00f3wi\u0105c \u2013 rozwijaj\u0105. Brak zrozumienia i utrzymania istniej\u0105cego kodu jest recept\u0105 na katastrof\u0119!<\/p>\n\n\n\n Gdy ca\u0142y zesp\u00f3\u0142 prowadzi refaktoring przez kilka dni, a nawet d\u0142u\u017cej<\/strong><\/p>\n\n\n\n Taki moment powinien by\u0107 jednak wyj\u0105tkiem od regu\u0142y. Mo\u017ce si\u0119 zdarzy\u0107 np. gdy planujemy migracj\u0119 pomi\u0119dzy narz\u0119dziami. Kolokwialnie m\u00f3wi\u0105c, o kod powinni\u015bmy dba\u0107 tak, jak dbamy o porz\u0105dek w swoich domach, gdzie wynosimy \u015bmieci, sprz\u0105tamy co 2-3 dni.<\/p>\n\n\n\n Codzienne podnoszenie jako\u015bci, podejmowanie pewnych krok\u00f3w prze\u0142o\u017cy si\u0119 na to, \u017ce dodawanie nowych funkcjonalno\u015bci b\u0119dzie du\u017co szybsze, \u0142atwiejsze, sprawniejsze, co ostatecznie wp\u0142ynie na jako\u015b\u0107 kodu. Tutaj widzimy, \u017ce trudno m\u00f3wi\u0107 o refaktoryzacji, maj\u0105c du\u017ce sprz\u0119\u017cenie i nisk\u0105 sp\u00f3jno\u015b\u0107, czyli z\u0142y podzia\u0142 odpowiedzialno\u015bci.<\/p>\n\n\n\n Id\u0105c dalej, mo\u017cemy powiedzie\u0107, \u017ce ju\u017c na tym poziomie mog\u0105 by\u0107 naruszone niekt\u00f3re z podstawowych dobrych praktyk pisania kodu \u2013 zasady SOLID[i]<\/a>, KISS[ii]<\/a>czy TDA[iii]<\/a>. Bez odpowiedniego podzia\u0142u odpowiedzialno\u015bci nie mamy czystego kodu, czyli ju\u017c na tym poziomie ci\u0119\u017cko m\u00f3wi\u0107 o refaktoryzacji.<\/p>\n\n\n\n Dodatkowo, je\u015bli kod nie jest czysty, to zwykle nie mamy do niego test\u00f3w b\u0119d\u0105cych naszym zapleczem bezpiecze\u0144stwa. Tak naprawd\u0119 nie da si\u0119 pomin\u0105\u0107 \u017cadnego z tych trzech element\u00f3w \u2013<\/strong><\/p>\n\n\n\n Nale\u017cy wykonywa\u0107 wszystko razem inaczej szybko mo\u017cna si\u0119 zniech\u0119ci\u0107, bo kt\u00f3ry\u015b z element\u00f3w mo\u017ce by\u0107 trudny do poprawnego zaimplementowania.<\/p>\n\n\n\n Najwa\u017cniejsze jest to, aby osoba pracuj\u0105ca z kodem to wszystko wywa\u017cy\u0142a, poniewa\u017c czasami warto\u015b\u0107 korzy\u015bci b\u0119dzie niewielka, nawet niezauwa\u017calna. M\u00f3wi\u0105c inaczej, po co robi\u0107 bardziej generyczny kod teraz, skoro by\u0107 mo\u017ce w przysz\u0142o\u015bci nikt nie b\u0119dzie go potrzebowa\u0142. Nale\u017cy uwa\u017ca\u0107, aby nie popa\u015b\u0107 w pu\u0142apk\u0119 robienia zbyt elastycznego rozwi\u0105zania. Nale\u017cy robi\u0107 rzeczy iteracyjnie, gdy\u017c cz\u0119sto warto poczeka\u0107, ze zmianami, a\u017c pewne rzeczy stan\u0105 si\u0119 jasne. Dok\u0142adniej m\u00f3wi nam o tym zasada YAGNI[iv]<\/a>.<\/p>\n\n\n\n Nale\u017cy jednak pami\u0119ta\u0107, \u017ce wprowadzaj\u0105c refaktoryzacj\u0119, nie wprowadzamy nowych funkcjonalno\u015bci, co od razu stawia zasad\u0119, \u017ce refactoring musi by\u0107 bezpieczny. Refaktoryzacja w oderwaniu od test\u00f3w, czystego kodu, dobrej architektury i wielu innych czynnik\u00f3w b\u0119dzie mia\u0142a bardzo ma\u0142y sens. Recept\u0105 na niez\u0142amanie wspomnianej przed chwil\u0105 zasady jest istnienie dobrych test\u00f3w. W przeciwnym wypadku refaktoryzacja mo\u017ce sta\u0107 si\u0119 bardzo trudna i niebezpieczna.<\/strong> Mo\u017ce si\u0119 te\u017c okaza\u0107, \u017ce b\u0119dzie mia\u0142a ona niewielki sens oraz b\u0119dzie du\u017co bardziej kosztowna ni\u017c gdyby\u015bmy si\u0119 jej nie podj\u0119li.<\/p>\n\n\n\n Wiemy ju\u017c, przynajmniej w teorii, jak i kiedy wykonywa\u0107 refaktoryzacj\u0119, ale z drugiej strony mamy syndromy, na kt\u00f3re musimy by\u0107 wyczuleni. Potocznie zwane code smell<\/strong>, kt\u00f3re powinny by\u0107 ostrze\u017ceniem, \u017ce co\u015b jest nie tak. Wiele z nich jest zupe\u0142nie naturalnych, stosowanych na co dzie\u0144, np. z\u0142e nazewnictwo, prze\u0142adowanie odpowiedzialno\u015bci.<\/p>\n\n\n\n Zapami\u0119tanie wszystkich code smells mo\u017ce by\u0107 problematyczne. Znacz\u0105co lepiej jest najpierw si\u0119 z nimi zapozna\u0107, a gdy pojawi si\u0119 problem odszuka\u0107 dany code smell i sprawdzi\u0107, jak najlepiej sobie z nim poradzi\u0107. Wi\u0119cej szczeg\u00f3\u0142\u00f3w mo\u017cna przeczyta\u0107 na stronie sourcemaking<\/a>. Pisa\u0142 o tym nawet autor wymienionych artyku\u0142\u00f3w i ksi\u0105\u017cki.<\/p>\n\n\n\n Wymienienie i opisanie wszystkich code smells to temat na osobny artyku\u0142. Dla dok\u0142adnego zapoznania si\u0119 z poni\u017cszymi polecam artyku\u0142 o technikach refaktoringu i bad code smells.<\/a><\/p>\n\n\n\n Nale\u017cy pami\u0119ta\u0107, \u017ce znajomo\u015b\u0107 wzorc\u00f3w projektowych do refaktoryzacji nie wystarczy. Wzorce s\u0105 jedynie otoczk\u0105, kt\u00f3r\u0105 widzimy, co r\u00f3wnie\u017c jest bardzo wa\u017cne. Mo\u017cna powiedzie\u0107, \u017ce wzorce s\u0105 realizacj\u0105 za\u0142o\u017ce\u0144 opisanych powy\u017cej<\/strong>, co mo\u017cna \u0142atwo zaobserwowa\u0107 na przyk\u0142adzie wzorca Proxy.<\/p>\n\n\n\n Mo\u017cemy sobie wyobrazi\u0107, \u017ce mamy metod\u0119 o nazwie transferFunds. Obs\u0142uguje ona przelew mi\u0119dzy dwoma kontami zgodnie z logik\u0105 biznesow\u0105. Jednak w przypadku takiej metody bardzo cz\u0119sto mo\u017ce si\u0119 zdarzy\u0107, \u017ce musimy otworzy\u0107, zamkn\u0105\u0107 transakcje, sprawdzi\u0107 jakie\u015b regu\u0142y bezpiecze\u0144stwa, zalogowa\u0107, \u017ce nast\u0105pi\u0142 przelew. Nagle okazuje si\u0119, \u017ce nazwa metody nie odpowiada temu, co w \u015brodku si\u0119 dzieje. Mamy nadu\u017cycie, przedobrzenie, robimy wi\u0119cej ni\u017c powinni\u015bmy. M\u00f3wi\u0105c dosadniej, to k\u0142amiemy ju\u017c na etapie nazwy metody.<\/p>\n\n\n\n Aby tego unikn\u0105\u0107, nale\u017cy dokona\u0107 separacji odpowiedzialno\u015bci, opakowa\u0107 kod poprzez ustanowienie po\u015brednika \u2013 Proxy.<\/p>\n\n\n\n Przyk\u0142ady z dok\u0142adniejszym opisaniem wzorc\u00f3w projektowych.<\/a><\/p>\n\n\n\n Na koniec zach\u0119cam Was do zrobienia zadania b\u0119d\u0105cego samodzieln\u0105 pr\u00f3b\u0105 refaktoringu<\/a>.<\/p>\n\n\n\n <\/p>\n\n\n\n [i]<\/a> podstawowych zasad, kt\u00f3rymi nale\u017cy si\u0119 kierowa\u0107 podczas programowania obiektowo. Skr\u00f3t pochodzi od pierwszych liter poszczeg\u00f3lnych zasad, s\u0105 to: single responsibility, open\/closed, liskov substitution, interface segregation oraz dependency inversion<\/p>\n\n\n\n [ii]<\/a> keep it simple stupid – nasz kod powinien by\u0107 tworzony i utrzymany w taki spos\u00f3b, aby by\u0142 dla wszystkich jak najbardziej zrozumia\u0142y i jasny<\/p>\n\n\n\n [iii]<\/a> tell don\u2019t ask \u2013 zasada m\u00f3wi o konkretnym podziale obowi\u0105zk\u00f3w pomi\u0119dzy naszymi klasami i obiektami, a ich zadaniami<\/p>\n\n\n\n [iv]<\/a> you ain\u2019t gonna need it \u2013 zasada m\u00f3wi, \u017ce w naszym programie powinni\u015bmy umieszcza\u0107 najistotniejsze funkcjonalno\u015bci, kt\u00f3re w danej chwili b\u0119d\u0105 nam potrzebne<\/p>\n\n\n\n [v]<\/a> don\u2019t repeat yourself \u2013 nale\u017cy unika\u0107 powtarzania tych samych cz\u0119\u015bci kodu w r\u00f3\u017cnych miejscach<\/p>\n\n\n\n ***<\/p>\n\n\n\n Je\u017celi temat refaktoryzacji jest dla Ciebie interesuj\u0105cy, polecamy r\u00f3wnie\u017c inny artyku\u0142 naszego eksperta: Podej\u015bcie do refaktoryzacji w projekcie ze starymi technologiami<\/a><\/p>\n\n\n<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\nRefaktoryzacja \u2013 wa\u017cne kwestie<\/strong><\/h2>\n\n\n\n
Kiedy jest najlepszy czas na refaktoryzacj\u0119?<\/strong><\/h2>\n\n\n\n
Dodatkowe wskaz\u00f3wki<\/strong><\/h2>\n\n\n\n
Syndromy Code Smells<\/strong><\/h2>\n\n\n\n
Zestaw najcz\u0119stszych code smells\/przyczyn niskiej jako\u015bci kodu<\/strong><\/h3>\n\n\n\n
Wzorce projektowe<\/strong><\/h2>\n\n\n\n
Przyk\u0142ady grup najcz\u0119\u015bciej spotykanych wzorc\u00f3w projektowych z kr\u00f3tkim opisem<\/strong><\/h3>\n\n\n\n
\u0179r\u00f3d\u0142a<\/strong><\/h2>\n\n\n\n
\n\n\n\n