Lubię refaktoryzację. Nie, nie w ten sposób. Uwielbiam refaktoryzację. Nie, nawet nie to. I Cholera Uwielbiam refaktoryzację.
Nie znoszę złego kodu i złej architektury. Wzdrygam się, kiedy piszę nową funkcję, a na kolejnych zajęciach panuje kompletny bałagan. Po prostu nie mogę patrzeć na niestety nazwane zmienne. Czasami przed pójściem spać zamykam oczy i wyobrażam sobie, co można by ulepszyć w projekcie. Czasami budzę się o trzeciej w nocy i idę do laptopa, żeby coś naprawić. Chcę, żeby kod nie był tylko kodem na dowolnym etapie rozwoju, ale dziełem sztuki, na które przyjemnie się patrzy i przyjemnie się z nim pracuje.

Jeśli choć trochę podzielasz moje uczucia, to mamy o czym rozmawiać. Fakt jest taki, że z biegiem czasu coś we mnie zaczęło mi podpowiadać, że refaktoryzacja wszystkiego, wszędzie i o każdej porze nie była najlepszym pomysłem. Nie zrozumcie mnie źle, kod powinien być dobry (a byłoby lepiej, gdyby był idealny), jednak w trudnych realiach nie zawsze mądrze jest stale ulepszać kod. Wymyśliłem dla siebie kilka zasad dotyczących terminowości refaktoryzacji. Jeśli zaczynam chcieć coś ulepszyć, patrzę wstecz na te zasady i zaczynam myśleć: „Czy to naprawdę jest moment, w którym musimy dokonać refaktoryzacji?” Zastanówmy się, w jakich przypadkach refaktoryzacja jest właściwa, a w jakich nie.

Zastrzeżenie. Najprawdopodobniej po przeczytaniu postu wielu będzie chciało od razu powiedzieć: „Tak, omawiano to już 600 razy!” lub „To takie oczywiste, po co o tym pisać?” Być może masz rację, ale rzecz w tym, że w otaczającym nas świecie wciąż panuje chaos. Wydaje się, że dla wszystkich wszystko jest jasne, jednak w rzeczywistości okazuje się, że nie jest to takie oczywiste. Dlatego myślę, że ponowne przyjrzenie się temu tematowi nie będzie zbyt szkodliwe. Ale jeśli nie masz żadnych problemów z refaktoryzacją, możesz po prostu pominąć ten post, już wszystko w porządku.

Refaktoryzacja za wcześnie

Czy pamiętasz, kiedy ostatni raz miałeś stałe zestawienie pracy, które nie zmieniało się przez miesiące? Nie jestem zbyt dobry w zapamiętywaniu tego. Żyjemy w realnym świecie, wymagania cały czas się zmieniają. Co więcej, niekoniecznie są to wymagania zewnętrzne - mogą to być Twoje własne wymagania dotyczące projektu. Wyjaśnię ten pomysł na przykładzie: powiedzmy, że podjąłeś się średniej wielkości problemu przez jeden lub dwa dni. Kilka pierwszych zajęć zostało już napisanych, ale nie ma jeszcze czego odpalać – trwa proces pisania surowej części architektonicznej. I wtedy zauważasz, że jedna z części projektu nie jest napisana w szczególnie uniwersalny sposób: „Ale jeśli za sześć miesięcy trzeba będzie zrobić X, to wszyscy będą cierpieć”. To ma sens, że nie chcesz przesyłać bzdurnego kodu do repozytorium i sprawić, że inni programiści pomyślą o tobie jako o złej reputacji. I zaczynasz refaktoryzację jeszcze nie gotowa funkcja. Czasami jest to uzasadnione, ale na takiej ścieżce powinien znajdować się znak „NIEBEZPIECZEŃSTWO”. Więc naprawiasz jedną rzecz, potem drugą, potem trzecią. Minął tydzień, funkcja nadal się nie uruchamia, a ty mówisz: „Jakoś wszystko zostało zrobione źle. Ale teraz ja Zrozumiałem dokładnie jak to zrobić. Teraz szybko napiszę wszystko od nowa.” Głównym problemem jest to, że nie otrzymano jeszcze opinii na temat tej funkcji, a już rozpoczęliście prace nad udoskonaleniem bazy kodu. Takie podejście rzadko prowadzi do sukcesu. Nie wiem jak u Was, ale u mnie często zdarza się, że po wdrożeniu jakiejś funkcjonalności zaczynam rozumieć, że wszystko powinno działać trochę inaczej. I nie dlatego, że jestem taki głupi i nie mogłem tego wcześniej dobrze przemyśleć. Wystarczy „dotknąć” jakiejś funkcjonalności, aby zrozumieć, jak wszystko powinno wyglądać w wydaniu. Czasami potrzebujesz małego prototypu (nawet z gównianym kodem i błędami), aby omówić daną funkcję ze współpracownikami. Czasami trzeba coś pokazać klientowi, żeby mógł powiedzieć: „Nie, cóż, nie o to mi chodziło, wszystko powinno być odwrotnie”. Czasami użytkownicy nie lubią innowacji, chcą, żeby wszystko było tak, jak było. Problem z nowymi funkcjami polega na tym, że trudno przewidzieć ich los. Często zdarza się, że wszystkie opracowania lądują w koszu, bo po omówieniu pierwszej wersji zespół postanowił zrobić wszystko inaczej. Ogólny wniosek: nie należy refaktoryzować kodu zbyt wcześnie, szczególnie jeśli nie mamy pewności, że kod ten na 100% pozostanie w projekcie.

Refaktoryzacja inna niż docelowa

Najprawdopodobniej masz plan rozwoju na najbliższą przyszłość. Prawdopodobnie masz określone terminy (nawet jeśli sam je ustalisz). Wersje muszą być realizowane na czas, a rozwój nie powinien być opóźniany. Musisz się kontrolować, musisz robić te rzeczy, które są częścią twoich bezpośrednich celów. Załóżmy, że masz fragment kodu, który wygląda na kompletny... Cóż, wygląda źle. Ale kontynuujmy nasze założenie, że teraz z nim nie pracujesz. Ten zły fragment kodu jest stabilny, pomyślnie wykonuje swoją pracę i nie ma nic wspólnego z bieżącym zadaniem. Cóż, nie dotykaj go! Tak, możesz być bardzo zasmucony faktem, że jesteś na drugim końcu projektu wszystko jest bardzo złe. Ale zauważ, że w tej chwili w żaden sposób Ci to nie przeszkadza. Masz aktualne zadania, zajmij się nimi. Oczywiście zdarzają się zadania mające na celu ulepszenie bazy kodu, ale nie często - często ważniejsze jest dodanie nowej funkcjonalności lub naprawienie błędów. Skoncentruj się na bieżących zadaniach i nie rezygnuj z nich tylko dlatego, że gdzieś coś jest nie tak.

Refaktoryzacja dla samej refaktoryzacji

OK, doszedłeś do wniosku, że zdecydowanie musisz dokonać refaktoryzacji części projektu. OK, dokonajmy refaktoryzacji. Wydaje się, że zaplanowane usprawnienia zostały zrealizowane, ale wtedy pojawia się myśl: „Co jeszcze mogę poprawić? Tak, to coś tam. A po tej rzeczy pojawi się ta rzecz, potem kolejna, i kolejna, itd. Musisz zrozumieć, że jest zły kod, jest dobry kod, jest idealny kod. Nigdy nie będziesz mieć tego drugiego w dużym projekcie. Nie oznacza to, że nie należy do tego dążyć, ale trzeba zrozumieć, że jest to nieosiągalne. Zwykle celem jest napisanie dobrego kodu, a nie doskonałego kodu. Załóżmy, że po refaktoryzacji masz w pełni czytelny kod, który działa w mniej lub bardziej oczywisty sposób, w którym nie ma kul i który nie jest taki trudny w obsłudze. Zadaj sobie pytanie: „Może czas przestać?” Tak, kod można ulepszyć. Co więcej, w wystarczająco dużym projekcie można to udoskonalać w nieskończoność. Ale teraz radzi sobie ze swoimi funkcjami, jest wygodny w użyciu i praktycznie nie powoduje żadnego dyskomfortu. Bardzo ważne jest, aby określić to samodzielnie do przyjęcia jakość kodu, po której przestajesz go ulepszać (aż do utraty właściwości akceptowalności). Pamiętaj, że wciąż jest wiele różnych fajnych rzeczy, które możesz dodać. Nie ma potrzeby refaktoryzacji dla samej refaktoryzacji, dla uzyskania doskonałego kodu. Musisz dokonać refaktoryzacji, kiedy już to zrobisz zniewalający przyczyny tego: kod jest trudny do odczytania, kod jest trudny w utrzymaniu, kod jest trudny w opracowywaniu, kod jest trudny w użyciu itp. Jeśli nie pojawiają się „trudności”, to zniewalający Nie ma powodu tracić czasu na refaktoryzację.

Refaktoryzacja dzień przed wydaniem

Zdarza się, że emisja następuje pojutrze/jutro/dzisiaj/powinno być wczoraj (odpowiednie podkreśl). To ważny moment w życiu projektu. Należy zwrócić szczególną uwagę na testowanie, naprawianie krytycznych błędów i końcowe ulepszenia. Uwierz mi, naprawdę złym pomysłem jest przerabianie bazy kodu (a co gorsza, przerabianie go dobrze) w momencie, gdy trzeba wysłać projekt na produkcję. Doświadczona praktyka podpowiada, że ​​trzeba to wypuścić, a potem spokojnie i z czystym sumieniem poprawiać kod. Niektórzy zapytają: „Dlaczego?” Jeśli pojawiło się to pytanie, prawdopodobnie nie musiałeś jeszcze przeprowadzać skomplikowanej refaktoryzacji. Podpowiem: kiedy przepisujesz kod, nie zawsze musi on się poprawiać – czasem może się zepsuć. Cóż to za skomplikowana refaktoryzacja - czasami poprawiasz jedną metodę w pięciu liniach, nie śledzisz jakiejś zależności, a na drugim końcu projektu wypełza błąd, z którym natychmiast spotkają się Twoi ulubieni użytkownicy. Wydaje się, że nie robisz nic złego, a potem nagle bestia „To nie było oczywiste” atakuje Cię i topi w stawie fałszywej wstępnej oceny. Chociaż może to po prostu taki kiepski ze mnie programista – lubię wszystko psuć. Jest całkiem możliwe, że zawsze refaktoryzujesz wszystko absolutnie poprawnie i przy pełnej kontroli nad całym projektem. W tym przypadku mogę pogratulować, ale i tak nie odmówię rady o zakazie refaktoryzacji przed wydaniem. Uwierz mi, refaktoryzacja nie zniknie w ciągu kilku dni, a cały zespół będzie spał trochę spokojniej.

Refaktoryzacja bardzo starego kodu

Pytanie jest trudne, bardzo trudne. Sytuacja: istnieje ogromna liczba okropnych linii kodu, które odziedziczyłeś od starych programistów (być może tymi starymi programistami byłeś kilka lat temu, jeszcze zanim nauczyłeś się pisać wszystko poprawnie i na raz). Kod należy zachować. Tu i ówdzie powstają kule i powielania, rośnie entropia. Z każdym dniem coraz bardziej mam ochotę wszystko wyrzucić i napisać od nowa. W takim momencie jest to konieczne Bardzo dobry pomyśl o ryzyku. Tak, jest prawdopodobne, że tego typu działania przydadzą się w przyszłości. Ale w jakiej dokładnie perspektywie i jak przydatne? Najprawdopodobniej w procesie dużej refaktoryzacji lub przepisania poszczególnych części zastąpisz stary działający kod nowym, doskonale napisanym kodem, ale z błędami. I wcale nie dlatego, że jesteś złym programistą i słabo piszesz. Być może po prostu nie znasz tego kodu dostatecznie. Być może nie wiesz, dlaczego autor napisał wszystko w ten sposób, ale mogą istnieć powody. Czasami trzeba napisać bardzo dziwny i krzywy kod. Mogę podać wiele przykładów: pomijanie skomplikowanych optymalizacji procesora, dostosowywanie błędów w bibliotece strony trzeciej, pomijanie niektórych wielowątkowych ościeży itp. Nie twierdzę, że wszystkich tych problemów nie da się normalnie rozwiązać. Po prostu czasami podczas przepisywania pozornie absurdalnego kodu na normalny kod pojawiają się błędy. Tak, wszystko dało się zrobić normalnie, ale można po prostu nie zdawać sobie sprawy z wielkości chaty zbudowanej z kul, a nie z kijów, jeśli nie dowiemy się od autora kodu, dlaczego tak to napisał (i taka możliwość nie zawsze jest zapewniony). Zachowaj ostrożność podczas przepisywania starego kodu, którego nie do końca rozumiesz (a zwłaszcza jeśli uważasz, że nie ma nic do zrozumienia).

Kiedy warto dokonać refaktoryzacji?

Przepraszam, jeśli ten artykuł sprawia wrażenie, że refaktoryzacja to same problemy. Nadal upieram się, że kod powinien być czytelny i piękny, powinien być łatwy w użyciu i łatwy w rozwijaniu. Pozytywne podejście jest lepsze niż negatywne, dlatego traktuj refaktoryzację nie jako źródło problemów, ale jako bardzo dobrego przyjaciela, który pomoże Ci w trudnych chwilach. Co więcej, ten przyjaciel może sprawić, że w Twojej świetlanej przyszłości będzie mniej trudnych momentów. Podsumowując, chciałbym podkreślić kilka punktów, kiedy refaktoryzacja jest naprawdę właściwa.

• Nic do roboty. Są spokojne chwile przestojów, kiedy wszystkie ważne zadania są zamknięte, a nowe nie zostały jeszcze przydzielone. No cóż, nie jest tak, że nie ma zupełnie nic do roboty, ale jest pewna ilość wolnego czasu. Wydaj je na ulepszenie swojego kodu. Nadaj podmiotom jasne nazwy, pozbądź się powielania, przepisz zły fragment architektury. Chociaż nie dodano żadnych nowych funkcji, przyczyniasz się do spokoju ducha programistów, którzy będą kontynuować projekt. Uwierz mi, to jest ważne.
• Codzienne cierpienie. I zdarza się, że jest taki fragment projektu, który każdego dnia sprawia, że ​​ciężko wzdychasz. A z sąsiednich stolików słychać ciężkie westchnienia Twoich kolegów. Oczywiście, mimo że premiera nie nastąpi jutro, nadal jest wystarczająco dużo ważnych zadań. Jednak tydzień za tygodniem mija, a patrzenie na ten fragment projektu staje się coraz bardziej smutne. Powiedz sobie: „Przestań to znosić!” Jeśli biznesplan jest napisany przez Twojego szefa, wyjaśnij mu, że ten kod po prostu trzeba przepisać. Jeśli pracujesz dla klienta, przekonaj go, że tydzień spędzony na refaktoryzacji pozwoli zaoszczędzić dużo czasu na programowanie w przyszłości. Jeśli pracujesz dla użytkowników, zdecyduj, że byłoby lepiej, gdyby ci użytkownicy poczekali tym razem jeszcze tydzień na wydanie, a potem cieszyli się stabilnym oprogramowaniem i regularnymi aktualizacjami. Tak, nie zawsze łatwo jest dojść do porozumienia ze wszystkimi i ze sobą, ale próbuj.
• Problem późnej refaktoryzacji. Zasada dotycząca zbyt wczesnej refaktoryzacji nie powinna być absolutna. Niektórzy myślą w ten sposób: „Teraz coś poprawiam, ale nie będzie to przydatne – szkoda”. Musisz zrozumieć, że w rdzeniu programu mogą znajdować się ważne części, które lepiej byłoby dobrze napisać. Pamiętaj, że im później dokonasz refaktoryzacji, tym wyższy koszt, ponieważ poświęcisz więcej czasu i wysiłku na przepisanie. Najważniejsze elementy podstawowe (te używane w całym projekcie) muszą być przez cały czas w możliwie najlepszym stanie. Będzie po prostu wspaniale, jeśli praca dyplomowa sprawdzi się w Twoim zespole „Refaktoryzacja nie jest spóźniona. Przychodzi ściśle wtedy, gdy uzna to za stosowne..
• Spotkanie z potworem. Zaczynasz wycinać nową funkcjonalność, która powinna wykorzystywać stary fragment projektu, który wygląda jak prawdziwy potwór: boisz się już na sam widok zewnętrznego interfejsu. Jeśli czas na to pozwala, napraw najpierw podstawową część kodu, abyś mógł następnie skupić się na nowej funkcjonalności i nie rozpraszać się wbijaniem kul w celu ponownego użycia kodu.
• Inteligentny perfekcjonizm. Zauważyłeś zły fragment kodu? Czy chcesz to naprawić? Czy naprawdę chcesz to naprawić? Cóż, jeśli naprawdę chcesz, to możesz. Zwróć jednak uwagę na słowo „rozsądny”. Zrównoważ czas spędzony na refaktoryzacji z korzyściami płynącymi z ulepszania kodu. Nie przegap terminów i nie daj się wciągnąć w niekończące się ulepszenia. Jeśli jednak dokonasz refaktoryzacji w odpowiednim czasie i w sposób umiarkowany, projekt będzie tylko lepszy.

Zamiast wniosków

Wszystko to jest czysto subiektywnym uogólnieniem doświadczeń z pracy nad wieloma projektami. Oczywiście nie opisałem wszystkich sytuacji życiowych. Każdy zespół ma swoje własne wymagania dotyczące kodu, własny biznesplan i własne zasady. Jestem pewien, że wiele osób ma pięć historii z serii „Ale miałem przypadek, gdy wszystkie te wskazówki nie zadziałały”. Jest to całkowicie normalne i tak powinno być. Nie ma uniwersalnego złotego środka na określenie nakładu pracy na ulepszenie kodu („Będziemy refaktoryzowali codziennie przez 47 minut 23 sekundy i wszystko będzie dobrze”). Musisz, opierając się na własnym doświadczeniu w konkretnym projekcie, w swoim konkretnym zespole, spróbować znaleźć złoty środek pomiędzy pisaniem nowego kodu a ulepszaniem starego. Ja tylko opowiadam się za racjonalnym podejściem do wszystkiego, bez fanatyzmu („Po co ulepszać kod, bo nowej funkcjonalności z tego nie będzie” / „Musimy pilnie doprowadzić cały kod do perfekcji, abyśmy później mogli z nim normalnie pracować”). Bądź mądry, przeznaczając swój czas na pracę nad istniejącym kodem, a wszystko będzie dobrze.

Wszelkie dodatkowe przemyślenia na temat tego, kiedy należy dokonać refaktoryzacji, a kiedy nie, są mile widziane. Jedną z najcenniejszych rzeczy w tej dziedzinie jest doświadczenie prawdziwych programistów przy prawdziwych projektach.

Refaktoryzacja Kodowanie to proces zmiany kodu źródłowego programu bez wpływu na jego zachowanie i mający na celu ułatwienie zrozumienia i/lub uproszczenie jego dalszej obsługi. Zazwyczaj refaktoryzacja dowolnego programu polega na wprowadzeniu niewielkich zmian w jego kodzie, z których każda nie zmienia zachowania samego programu, ale w jakiś sposób upraszcza i/lub ulepsza kod. Jednocześnie bardzo ważne jest, aby refaktoryzacja była przeprowadzana w małych częściach, ponieważ gdy programista zmienia niewielką część kodu, znacznie łatwiej jest mu monitorować poprawność zmian i nie popełniać błędów. Jeśli refaktoryzujesz duże fragmenty kodu na raz, istnieje bardzo duże prawdopodobieństwo popełnienia błędów, w wyniku których program może całkowicie przestać działać. Co prawda to, że edycje powinny być niewielkie, nie oznacza, że ​​refaktoryzacja polega jedynie na podmianie nazw zmiennych lub przenoszeniu małych fragmentów kodu z jednego miejsca programu do drugiego - refaktoryzacja pozwala na całkowite przerobienie całego programu, łącznie z logiką jego działania zachowanie, najważniejsze jest to - wprowadzaj zmiany w małych częściach, a wtedy wszystko będzie dobrze.

Cele refaktoryzacji

Pewnie zapytacie mnie, po co w ogóle to piszę? I do tego, że jeśli dokładnie przyjrzysz się kodowi źródłowemu, na przykład tekstom źródłowym każdej lekcji, prawdopodobnie zauważyłeś, że często zmieniam coś w kodzie, czasem w drobnych szczegółach, a czasem dość zauważalnie. To dlatego, że Sam korzystam z refaktoryzacji i chcę, aby stało się to nawykiem również dla Ciebie.

Jak już mówiłem - główny cel refaktoryzacji Ma to na celu uproszczenie i przejrzystość kodu. Jeśli po przeróbce kod nie stanie się lepszy i wyraźniejszy, to albo nie dokonałeś refaktoryzacji, albo się nie udało. Nie należy jednak mylić pojęcia refaktoryzacji z optymalizacją. W wyniku optymalizacji kod staje się szybszy, ale niekoniecznie prostszy i bardziej przejrzysty, refaktoryzacja służy właśnie uproszczeniu i poprawie czytelności kodu.

Jaki kod wymaga refaktoryzacji

Możesz i często musisz refaktoryzować dowolny kod - najczęściej wystarczy zdać się na swój instynkt, jeśli jakiś kod wydaje ci się niezbyt udany lub wydaje ci się, że za tydzień już zapomnisz, co ta czy tamta sekcja kodu - najprawdopodobniej ten kod wymaga refaktoryzacji. Spróbuję sformułować podstawowe zasady, na podstawie których zrozumiesz, że Twój kod wymaga przeróbki:

Jeśli Twój program ma zduplikowany kod, prawie na pewno wymagana jest refaktoryzacja. Duplikat kodu w programie jest głównym źródłem błędów. Jeśli w Twoim programie jakaś akcja jest wykonywana w kilku różnych miejscach, ale przy użyciu tego samego kodu, po prostu umieść ten kod w osobnej funkcji i wywołaj ją. W przeciwnym razie istnieje duże prawdopodobieństwo, że pewnego dnia będziesz edytować kod źródłowy w jednym miejscu, ale zapomnisz poprawić podobny kod w innym i pojawią się błędy.

Twój program ma bardzo długie metody/funkcje. Z reguły osoba nie jest w stanie w pełni dostrzec i ocenić poprawności kodu, jeśli kod ten zajmuje więcej niż 2-3 tuziny linii. Takie metody i funkcje należy podzielić na kilka mniejszych i stworzyć jedną wspólną funkcję, która będzie wywoływała te metody po kolei. Nigdy nie próbuj zmniejszać długości kodu, pisząc kilka instrukcji w jednej linii!!! To jedna z najgorszych opcji organizacji programu i daję Ci 100% gwarancję, że taki kod ostatecznie doprowadzi do błędów!

Długa lista parametrów funkcji/metody/konstruktora. Duża liczba parametrów zwykle nie tylko utrudnia zrozumienie działania metody lub funkcji, ale także utrudnia zrozumienie kodu korzystającego z tych funkcji. Jeśli naprawdę potrzebujesz funkcji przyjmującej wiele parametrów, po prostu umieść te parametry w osobnej strukturze (lub klasie), nadając tej strukturze rozsądną i zrozumiałą nazwę oraz przekaż funkcji łącze (lub wskaźnik) do obiektu tej strukturę lub klasę.

Duże klasy również wymagają refaktoryzacji. Jeśli masz w swoim programie jedną lub kilka dużych (kilkadziesiąt linii kodu) klas, powinieneś od razu podzielić je na mniejsze i włączyć obiekty tych klas do jednej wspólnej klasy. Powód jest taki sam jak w poprzednim akapicie.

Zbyt wiele zmiennych tymczasowych jest również oznaką złego kodu wymagającego refaktoryzacji. Z reguły wiele zmiennych tymczasowych znajduje się w nadmiernie „rozdętych” funkcjach - gdy refaktoryzujesz takie funkcje, najprawdopodobniej liczba zmiennych tymczasowych w każdej z nich zmniejszy się, a kod stanie się znacznie jaśniejszy i wygodniejszy

Istnieje wiele „nieporządnych” przechowywanych danych, które są logicznie połączone i można je połączyć w strukturę lub klasę. Logicznie powiązane dane powinny być zawsze przechowywane w strukturach/klasach, nawet jeśli są to tylko 2-3 zmienne - nie pogorszy to nikogo, ale kod stanie się znacznie jaśniejszy.

Jeżeli obiekty jednej klasy zbyt często/odwołują się do danych innego obiektu, należy ponownie rozważyć funkcjonalność tych obiektów. Być może podjąłeś złą decyzję dotyczącą architektury i musisz ją jak najszybciej zmienić, zanim błąd rozprzestrzeni się na cały kod.

Staraj się nie przechowywać zbyt wielu zmiennych globalnych. Jeśli naprawdę potrzebujesz dokładnie tylu i nie mniej globalnych obiektów - spróbuj przynajmniej pogrupować je w struktury/klasy, lub przynajmniej po prostu umieścić je w osobnej przestrzeni nazw - wtedy istnieje ryzyko, że przypadkowo użyjesz jakiejś zmiennej przez błąd, stać się znacznie niższe.

Refaktoryzacja kodu

Cel pracy: naucz się reorganizować kod programu w oparciu o wzorce refaktoryzacji.

Postęp prac

1. Zapoznaj się z informacjami teoretycznymi.
2. Przeprowadź analizę kodu tworzonego oprogramowania i testy jednostkowe, aby zidentyfikować źle zorganizowany kod.
3. Korzystając z szablonów refaktoryzacji, zreorganizuj kod programu tworzonego oprogramowania i testy jednostkowe.
4. Sprawdź, czy wszystkie testy jednostkowe przebiegły pomyślnie.
5. Uzupełnij opis wykonanych operacji refaktoryzacji (wzorzec was-was-refactoring).
6. W razie potrzeby dostosuj dokumentację projektową (diagramy klas, diagramy sekwencji).
7. Wyciągaj wnioski na podstawie wyników pracy.

Wymagania dotyczące treści pracy

1. Stanowisko.
2. Cel pracy.
3. Krótkie sformułowanie indywidualnego zadania.
4. Tabela zmian w projekcie oprogramowania.
5. W razie potrzeby skorygowane diagramy klas i sekwencji.
6. Wnioski.

Informacje teoretyczne

Oznaki źle zorganizowanego kodu

To nie jest zbiór jasnych zasad, ale opis miejsc, na które należy zwrócić uwagę podczas refaktoryzacji.

Zduplikowany kod

Jeśli w kilku miejscach widzisz te same struktury kodu, możesz być pewien, że ten program będzie lepszy, jeśli uda Ci się je ujednolicić.

W najprostszych przypadkach pomoże Ci Metoda Ekstrakcji. Podczas pracy z dziedziczeniem należy używać pola podciągającego. Jeśli kod jest podobny, ale nie dokładnie, musisz użyć metody wyodrębniania, a następnie metody szablonu formularza. Jeśli metody robią to samo na różne sposoby, wybierz jedną z nich i użyj algorytmu zastępczego. Jeśli masz zduplikowany kod w niepowiązanych klasach, rozważ funkcję wyodrębnienia klasy.

Długa metoda

Wśród programów obiektowych najdłużej żyją programy z krótkimi metodami. Im dłuższa procedura, tym trudniej ją zrozumieć. Jeśli masz dobrą nazwę dla metody, nie musisz patrzeć na jej treść.

Kierujemy się heurystyką: ilekroć czujemy, że powinniśmy napisać komentarz, zamiast tego piszemy metodę. W 99% przypadków, aby skrócić metodę, wystarczy zastosować Metodę Ekstrakcji. Lokalne zmienne i parametry mogą Ci przeszkadzać, dlatego możesz potrzebować opcji Zamień Temp na zapytanie, Przedstaw obiekt parametru i Zachowaj cały obiekt.

Oprócz komentarzy dobrymi znakami są także pętle i warunki. W przypadku warunków użyj opcji Decompose Conditional, a w przypadku pętli umieść treść pętli w osobnej metodzie.

Wielka klasa

Kiedy klasa robi zbyt wiele rzeczy, zwykle ma zbyt wiele pól.

Aby wyodrębnić niektóre zmienne, możesz użyć metody wyodrębnienia klasy lub wyodrębnienia podklasy. Określając, co usunąć, poszukaj podobieństwa w nazwach zmiennych, a także tego, czy klasa używa ich wszystkich w tym samym czasie.

Ponadto sala lekcyjna ze zbyt dużą ilością kodu jest również wylęgarnią powielania i chaosu. Tutaj również użyj klasy wyodrębnienia lub podklasy wyodrębnienia.

Jeśli Twoja duża klasa jest klasą GUI, spróbuj oddzielić zachowanie od danych. Możesz potrzebować zduplikowanych zaobserwowanych danych.

Długa lista opcji

Jest to relikt programowania proceduralnego. W świecie obiektów zawsze istnieje przedmiot, któremu można zadać pytanie i uzyskać wszystkie potrzebne odpowiedzi.

Użyj opcji Zamień parametr na metodę, Zachowaj cały obiekt i Wprowadź obiekt parametru.

Rozbieżna zmiana

Zmiana rozbieżna ma miejsce wtedy, gdy jedna klasa podlega różnym zmianom.

Strukturyzujemy nasze oprogramowanie tak, aby ułatwić jego zmianę. Jeśli chcemy coś zmienić, szukamy jedynego miejsca, w którym możemy dokonać zmiany. Jeśli nie możemy tego zrobić, będziemy brzydko pachnieć. Możesz spojrzeć na zajęcia i pomyśleć: „Te trzy metody zmieniam za każdym razem, gdy podłączam nową bazę danych, a te cztery – gdy dodaję instrument finansowy”. Aby to uporządkować, znajdź wszystko, co zmienia się w tym konkretnym przypadku i użyj klasy Extract.

Operacja strzelecka

To jak rozbieżna zmiana, ale na odwrót. Za każdym razem, gdy musisz dokonać takiej zmiany, wprowadzasz kilka małych zmian w różnych klasach. Często prowadzi to do błędów.

Użyj Move Method i Move Field, aby umieścić wszystkie zmiany w jednej klasie. Jeśli żadna klasa nie wygląda na dobrego kandydata, utwórz nową klasę.

Jeśli to konieczne, użyj klasy Inline. Zmiana rozbieżna ma miejsce, gdy na jedną klasę wpływają różne zmiany, podczas gdy chirurgia strzelbowa ma miejsce, gdy jedna zmiana wpływa na wiele klas.

Zazdrość według funkcji

Celem posiadania obiektów w programie jest połączenie danych i metod, które ich używają. Typowy nieprzyjemny zapach ma miejsce, gdy metoda wydaje się bardziej zainteresowana danymi innego obiektu niż swoimi własnymi.

Po prostu użyj metody przenoszenia, aby przenieść go tam, gdzie powinien. Jeśli tylko część metody cierpi z powodu zazdrości, najpierw użyj metody ekstrakcji.

W przypadku, gdy metoda wykorzystuje dane z wielu obiektów, umieść ją na obiekcie, którym jest najbardziej zainteresowana. Użyj metody wyodrębniania, aby wyizolować zależności.

Stosowanie niektórych złożonych wzorców, takich jak Strategia i Odwiedzający, narusza te zasady. Ogólnym zaleceniem jest zawsze znalezienie równowagi między złożonością a niezbędną elastycznością.

Grupy danych

Jeśli zauważysz, że elementy danych zawsze podróżują razem, połącz je w jeden obiekt. Użyj klasy wyodrębniającej dla pól, zachowaj cały obiekt i wprowadź obiekt parametrów dla parametrów metody.

Dobrą metodą testową jest: jeśli usuniesz jeden z elementów danych, czy pozostałe nadal będą miały sens? Jeśli tak, to tutaj powinien narodzić się obiekt.

Obsesja na punkcie prymitywów

Początkujący programiści obiektowi zwykle unikają używania małych obiektów do małych zadań, takich jak waluty, zakresy, specjalne ciągi znaków dla numerów telefonów i tym podobne. Możesz wydostać się z jaskiń do cywilizowanego świata obiektów za pomocą Zamień wartość danych na obiekt, Zamień tablicę na obiekt, jeśli jest to kod typu, użyj Zamień kod typu na klasę, Zamień kod typu na podklasy i Zamień kod typu na strategię .

Oświadczenie o przełączniku (przypadku).

Dobry kod obiektowy bardzo rzadko używa instrukcji Switch. Często zobaczysz ten sam Switch w różnych miejscach. Jeśli chcesz dodać kolejny wybór, będziesz musiał wyszukać wszystkie instrukcje Switch.

W większości tych przypadków lekarstwem jest polimorfizm. Jeśli Switch przełącza według kodu typu, użyj opcji Zamień kod typu na podklasy lub Zamień kod typu na strategię. Możesz potrzebować metody wyodrębniania i metody przenoszenia, aby wyizolować przełącznik i umieścić go w żądanej klasie. Po skonfigurowaniu struktury dziedziczenia użyj funkcji Zamień warunkowe na polimorfizm.

Hierarchie dziedziczenia równoległego

Hierarchie równoległe są szczególnym przypadkiem chirurgii shotgun. Za każdym razem, gdy dodajesz dziecko klasy, musisz dodać dziecko innej klasy. Najpierw spraw, aby instancje jednej hierarchii odnosiły się do odpowiednich instancji innej. Następnie użyj Move Method i Move Field, a druga hierarchia stopniowo zniknie.

Leniwa klasa

Zrozumienie i utrzymanie każdej klasy, którą utworzysz, kosztuje Cię pieniądze. Klasa, która nie robi wystarczająco dużo, aby na siebie zarobić, musi zostać zniszczona. Często jest to klasa, która wcześniej była opłacalna, ale została wycięta podczas refaktoryzacji. Jeśli jest to element podrzędny innej klasy, użyj opcji Zwiń hierarchię. Prawie bezużyteczne zajęcia powinny zostać poddane klasie Inline.

Spekulatywne uogólnienie

Dzieje się tak w przypadku, gdy ktoś mówi: „Och, spójrz, pewnego dnia będziemy potrzebować tej funkcji”, i chce wstawić wszelkiego rodzaju haczyki i specjalne skrzynki, aby poradzić sobie z rzeczami, które nie są potrzebne. W rezultacie jest trudniejszy w użyciu i utrzymaniu.

Jeśli masz klasy abstrakcyjne, które nic nie robią, użyj Zwiń hierarchię. Niepotrzebne delegowanie można usunąć za pomocą klasy Inline. Metody z nieużywanymi parametrami muszą podlegać usunięciu parametru.

Pole tymczasowe

Czasami zobaczysz kod, który używa zmiennych instancji tylko w niektórych przypadkach. To bardzo utrudnia zrozumienie.

Użyj klasy ekstraktu, aby stworzyć dom dla biednych sierot. Umieść tam cały kod związany z tymi polami. Możesz także pozbyć się kodu warunkowego, używając opcji Introduce Null Object, aby utworzyć alternatywny obiekt, gdy te pola nie mają sensu.

Wątek wiadomości

Jeśli widzisz kod, w którym klient prosi o obiekt z innego obiektu, oznacza to, że obiekt ten ma następny obiekt itd. Może to być długi ciąg metod getThis lub sekwencja zmiennych tymczasowych. W każdym razie przy takich wywołaniach jawnie zakładamy wiedzę o strukturze obiektów w łańcuchu. Jakakolwiek zmiana w powiązaniach spowoduje zmianę tego kodu. Tutaj musisz użyć opcji Ukryj delegata. Zobacz, dlaczego używany jest wynik połączenia. Użyj metody wyodrębnienia, a następnie metody przenoszenia, aby przenieść ją dalej w górę łańcucha. Niektórzy są przeciwni jakiemukolwiek łańcuchowi metod. Jesteśmy zwolennikami umiaru.

Mediator

Jedną z głównych właściwości obiektów jest enkapsulacja. Pytasz dyrektora, czy ma czas na spotkanie. Przekazuje wiadomość swojemu planiście i odpowiada. Nie musisz wiedzieć, czy korzysta z terminarza, elektronicznego gadżetu czy sekretarki.

Może to jednak zajść za daleko. Patrzysz na interfejs klasy i widzisz, że połowa jej metod po prostu deleguje wywołania innym klasom. Czas skorzystać z opcji Usuń pośrednika i porozmawiać bezpośrednio z obiektami, które wiedzą, co się dzieje. Jeśli delegujesz tylko niektóre metody, uruchom na nich metodę Inline. Jeśli oprócz delegowania dodajesz zachowanie, użyj opcji Zamień delegowanie na dziedziczenie.

Nieuzasadniona intymność

Czasami zajęcia zbliżają się zbyt blisko siebie i spędzają zbyt dużo czasu w swoich intymnych częściach.

Użyj metody przesuwania i przesuwania pola, aby oddzielić części i zmniejszyć odległość. Sprawdź, czy możesz zorganizować zmianę powiązania dwukierunkowego na jednokierunkowe. Jeśli klasy naprawdę mają wspólne zainteresowania, użyj klasy wyodrębniającej, aby umieścić wspólne części w jednym miejscu.

Dziedziczenie często prowadzi do nadmiernej intymności. Potomkowie zawsze wiedzą o swoich przodkach więcej, niżby chcieli. Użyj Zamień dziedziczenie na delegowanie, gdy nadejdzie czas opuszczenia domu.

Niekompletna klasa biblioteczna

Często nie jesteśmy do końca zadowoleni z zajęć z biblioteki, ale nie możemy zastosować do nich czegoś takiego jak Metoda przenoszenia. Jeśli chcesz dodać kilka metod, użyj opcji Przedstaw metodę obcą. Jeśli chcesz dużo dodać, będziesz potrzebować wprowadzenia rozszerzenia lokalnego.

Klasa danych

Istnieją klasy, które zawierają tylko pola i metody dostępu do nich. To po prostu głupie pojemniki na dane i najprawdopodobniej inne klasy manipulują nimi zbyt szczegółowo. Najpierw zastosuj Encapsulate Field i Encapsulate Collection, gdy nikt nie patrzy. Zobacz, gdzie używane są dane klas. Spróbuj użyć metody Move, aby przenieść ten kod do samej klasy danych. Klasy danych są jak dzieci. Są potrzebne na początkowych etapach. Ale aby zachowywać się jak dorosły obiekt, muszą wziąć na siebie odpowiedzialność.

Odrzucony spadek

Podklasy dziedziczą metody i dane od swoich przodków. Czasem jednak nie korzystają z tego, co im daje.

Tradycyjna odpowiedź jest taka, że ​​hierarchia jest zła. Musisz utworzyć nową klasę pochodną i zastosować metodę Push Down i pole Push Down. Ale z naszego sarkastycznego użycia słowa „tradycyjny” można się domyślić, że nie zawsze będziemy to polecać. Używamy dziedziczenia do ponownego wykorzystania. Towarzyszy mu nieprzyjemny zapach, ale zwykle nie jest on bardzo silny. Jeśli problemem jest odrzucony spadek, skorzystaj z tradycyjnych porad.

Mozilla FireFox, aby wyjaśnić wersję tego oprogramowania, należy rozwinąć sekcję „Pomoc” w menu i kliknąć najniższy element („Informacje o Mozilla Firefox”). Otworzy się osobne pionowe okno, w którym pod dużym napisem Firefox znajduje się wskazanie dokładnej wersji trzech liczb oddzielonych kropką.

W menu Opery należy także otworzyć sekcję „Pomoc” i kliknąć dolną pozycję („Informacje o programie”). Ale tutaj, w przeciwieństwie do wszystkich innych przeglądarek, nie pojawia się osobne okno - otwiera się zwykłe okno, którego większość zajmują listy różnych typów pamięci utworzonych przez przeglądarkę w Twojej przeglądarce. Na samym początku tej listy znajduje się osobna sekcja zwana „Informacjami o wersji”. Numery wersji Opery to dwie liczby oddzielone kropką.

W przeglądarce Internet Explorer, otwierając tę ​​samą sekcję menu o nazwie „Pomoc” i klikając ostatnią pozycję na liście „O programie”, wyświetli się okno z surowym przypomnieniem o przestrzeganiu praw autorskich. Oprócz tego tekstu nie ma mniej poważnego kodu wskazującego wersję przeglądarki. W nim aż cztery liczby oddzielone są kropką, z czego jedna przekroczyła już czterocyfrowy znak.

W przeglądarce Google Chrome oprócz równie poważnego kodu zastosowanej wersji (cztery cyfry oddzielone kropkami) znajduje się także wskazanie najnowszej modyfikacji dostępnej do instalacji. Aby wyświetlić osobne okno ze wszystkimi tymi informacjami, należy otworzyć menu, klikając ikonę klucza w prawym górnym rogu okna przeglądarka i wybierz „Informacje o Google Chrome”.

Na wszelki wypadek w przeglądarce Apple Safari istnieją dwa sposoby otwarcia okna z informacją o wersji. Jedna z nich jest podobna do metody przeglądarki Chrome - należy kliknąć ikonę znajdującą się w tym samym miejscu (tutaj jest na niej narysowany bieg) i wybrać „O Safari”. Drugi jest bardzo podobny do Mozilli i IE - musisz otworzyć sekcję „Pomoc” w menu i kliknąć dolną pozycję („O Safari”). Apple wymyśliło najdłuższe oznaczenie wersji: oprócz trzech liczb oddzielonych kropką istnieje także uzupełnienie trzech liczb w nawiasach.