Twój kod może pachnieć! Jak to naprawić

ZA zapach kodu to fragment kodu lub ogólny wzorzec kodowania, który wygląda jakby mógł wskazywać na głębszy problem w ogólnej strukturze i projekcie bazy kodu.

Pomyśl o zapachu kodu jako każdym znaku, który sugeruje, że część kodu powinna zostać refaktoryzowana. Nie chodzi o to, że kod jest błędny lub nie działa - często śmierdzący kod działa dobrze - ale śmierdzący kod jest często trudny w utrzymaniu i rozszerzaniu, co może prowadzić do problemów technicznych (szczególnie w większych projektach).

W tym artykule wyróżnimy 10 najczęstszych zapachów kodu, czego szukać i jak je dezodoryzować. Jeśli jesteś nowym programistą Jak nauczyć się programowania bez stresu Jak nauczyć się programowania bez stresu Być może zdecydowałeś się kontynuować programowanie, czy to dla kariery, czy dla hobby. Świetny! Ale może zaczynasz czuć się przytłoczony. Nie za dobrze. Oto pomoc w ułatwieniu podróży. , unikaj ich, a Twój kod będzie zauważalnie lepszy!

1. Ciasne połączenie

Problem
Ścisłe sprzężenie ma miejsce, gdy dwa obiekty są tak bardzo zależne od swoich danych i / lub funkcji, że modyfikacja jednego wymaga modyfikacji drugiego. Gdy dwa obiekty są zbyt ściśle powiązane, wprowadzanie zmian w kodzie może być koszmarem, a przy każdej zmianie istnieje większe prawdopodobieństwo wprowadzenia błędów.

Na przykład:

class Worker Bike bike = new Bike (); public void commute () bike.drive (); 

W takim przypadku pracownik i rower są ściśle powiązane. Co jeśli pewnego dnia chciałbyś prowadzić samochód zamiast roweru w drodze do pracy? Musisz przejść do klasy Worker i zastąpić cały kod związany z rowerem kodem związanym z samochodem. Jest brudny i podatny na błędy.

Rozwiązanie
Możesz poluzować sprzężenie, dodając warstwę abstrakcji. W tym przypadku klasa robotnicza nie tylko chce jeździć na motocyklach, ale także samochodami, a może ciężarówkami, a może nawet skutery. To są wszystkie pojazdy, prawda? Utwórz interfejs pojazdu, który pozwala wstawiać i zamieniać różne typy pojazdów według potrzeb:

pracownik klasy Pojazd pojazdu; public void changeVehicle (Vehicle v) Vehicle = v;  public void commute () Vehicle.drive ();  interfejs Vehicle void drive ();  klasa Bike implementuje Vehicle public void drive ()  klasa Car implementuje Vehicle public void drive () 

2. Przedmioty Boga

Problem
Boski obiekt to ogromna klasa / moduł, który zawiera zbyt wiele zmiennych i funkcji. To “wie za dużo” i “robi za dużo,” co jest problematyczne z dwóch powodów. Po pierwsze, inne klasy / moduły stają się nadmiernie zależne od tych danych (ścisłe połączenie). Po drugie, ogólna struktura programu staje się mętna, gdy wszystko jest stłoczone w tym samym miejscu.

Rozwiązanie
Weź obiekt Boga, rozdziel jego dane i funkcje zgodnie z problemami, które oni rozwiązują, a następnie zamień te grupy w obiekty. Jeśli masz obiekt Boga, lepiej będzie, jeśli będzie to kompozycja wielu mniejszych obiektów.

Załóżmy na przykład, że masz potworną klasę użytkownika:

klasa Użytkownik public String nazwa użytkownika; hasło publicznego ciągu; publiczny adres ciągu; publiczny kod pocztowy String; public int age;… public String getUsername () return nazwa użytkownika;  public void setUsername (String u) nazwa użytkownika = u; 

Możesz przekonwertować go na następujący skład:

klasa Użytkownik poświadczenia; Profil profilu;… poświadczenia klasy public String user name; public String password;… public String getUsername () return nazwa użytkownika;  public void setUsername (String u) nazwa użytkownika = u; 

Następnym razem, gdy będziesz musiał zmodyfikować procedury logowania, nie będziesz musiał czołgać się przez ogromną klasę użytkownika, ponieważ klasa poświadczeń jest łatwiejsza do zarządzania!

3. Długie funkcje

Problem
Długa funkcja jest dokładnie taka, jak się wydaje: funkcja, która urosła za długo. Chociaż nie ma określonej liczby dla liczby wierszy kodu “za długo” dla funkcji jest to jedna z tych rzeczy, w których znasz ją, kiedy ją widzisz. Jest to węższa wersja problemu z obiektami Boga - długa funkcja ma zbyt wiele obowiązków.

Rozwiązanie
Długie funkcje powinny być podzielone na wiele podfunkcji, gdzie każda podfunkcja jest zaprojektowana do obsługi pojedynczego zadania lub problemu. Idealnie oryginalna długa funkcja zmieni się w listę wywołań podfunkcji, dzięki czemu kod będzie czystszy i łatwiejszy do odczytania.

4. Nadmierne parametry

Problem
Funkcja (lub konstruktor klasy), która wymaga zbyt wielu parametrów, jest problematyczna z dwóch powodów. Po pierwsze, sprawia, że ​​kod jest mniej czytelny i utrudnia testowanie. Ale po drugie, a co ważniejsze, może to wskazywać, że cel funkcji jest zbyt niejednoznaczny i próbuje obsłużyć zbyt wiele obowiązków.

Rozwiązanie
Podczas “za dużo” jest subiektywny dla listy parametrów, zalecamy uważanie na każdą funkcję, która ma więcej niż 3 parametry. Jasne, czasami sensowne jest posiadanie jednej funkcji z 5 lub nawet 6 parametrami, ale tylko wtedy, gdy jest to naprawdę dobry powód.

Przez większość czasu nie ma jednego i kod lepiej byłoby podzielić tę funkcję na dwie lub więcej różnych funkcji. w przeciwieństwie do “Długie funkcje” zapach kodu, tego nie da się rozwiązać tylko poprzez zastąpienie kodu podfunkcjami - sama funkcja musi zostać podzielona i podzielona na osobne funkcje obejmujące oddzielne obowiązki.

5. Źle nazwane identyfikatory

Problem
Jedno- lub dwuliterowe nazwy zmiennych. Nazwy funkcji nieokreślonych. Nadmiernie zdobione nazwy klas. Oznaczanie nazw zmiennych ich typem (np. B_isCounted dla zmiennej boolowskiej). A co najgorsze, mieszanie różnych schematów nazewnictwa w ramach jednej bazy kodu. Wszystko to skutkuje trudnym do odczytania, trudnym do zrozumienia i trudnym w utrzymaniu kodem.

Rozwiązanie
Wybieranie dobrych nazw dla zmiennych, funkcji i klas to trudna umiejętność. Jeśli dołączasz do istniejącego projektu, przeczesz go i sprawdź, jak nazywane są istniejące identyfikatory. Jeśli jest przewodnik po stylu, zapamiętaj go i zastosuj się do niego. W przypadku nowych projektów rozważ utworzenie własnego przewodnika po stylu i trzymaj się go.

Ogólnie nazwy zmiennych powinny być krótkie, ale opisowe. Nazwy funkcji powinny zazwyczaj zawierać co najmniej jeden czasownik i od razu powinno być oczywiste, co funkcja robi tylko na podstawie swojej nazwy, ale należy unikać wrzucania zbyt wielu słów. To samo dotyczy nazw klas.

6. Liczby magiczne

Problem
Przeglądasz kod, który (miejmy nadzieję) napisał ktoś inny, i widzisz numery zakodowane na stałe. Może są częścią instrukcji if, a może częścią tajemnych obliczeń, które wydają się nie mieć sensu. Musisz zmodyfikować funkcję, ale po prostu nie możesz zrozumieć, co oznaczają liczby. Drapanie głowy.

Rozwiązanie
Podczas pisania kodu są to tzw “magiczne liczby” należy unikać za wszelką cenę. Numery zakodowane mają sens w momencie ich zapisywania, ale mogą szybko utracić wszelkie znaczenie - szczególnie, gdy ktoś inny próbuje zachować kod.

Jednym rozwiązaniem jest pozostawienie komentarzy wyjaśniających liczbę, ale lepszym rozwiązaniem jest konwersja liczb magicznych na zmienne stałe (do obliczeń) lub wyliczenia (do instrukcji warunkowych i instrukcji przełączających). Nadając magicznym liczbom nazwę, kod staje się nieskończenie bardziej czytelny na pierwszy rzut oka i mniej podatny na błędne zmiany.

7. Głębokie zagnieżdżanie

Problem
Istnieją dwa główne sposoby na uzyskanie głęboko zagnieżdżonego kodu: pętle i instrukcje warunkowe. Głęboko zagnieżdżony kod nie zawsze jest zły, ale może być problematyczny, ponieważ może być trudny do przeanalizowania (szczególnie jeśli zmienne nie są dobrze nazwane), a nawet trudniejszy do zmodyfikowania.

Rozwiązanie
Jeśli zauważysz, że piszesz podwójną, potrójną, a nawet poczwórną pętlę for, twój kod może próbować sięgać zbyt daleko poza siebie, aby znaleźć dane. Zamiast tego należy podać sposób żądania danych za pomocą wywołania funkcji dowolnego obiektu lub modułu zawierającego dane.

Z drugiej strony głęboko zagnieżdżone instrukcje warunkowe są często znakiem, że próbujesz obsłużyć zbyt dużo logiki w jednej funkcji lub klasie. W rzeczywistości głębokie zagnieżdżanie i długie funkcje zwykle idą w parze. Jeśli kod zawiera masowe instrukcje przełączników lub zagnieżdżone instrukcje „jeśli-to-inaczej”, możesz zamiast tego wdrożyć wzorzec automatu stanów lub strategii.

Głębokie zagnieżdżanie jest szczególnie rozpowszechnione wśród niedoświadczonych programistów gier. 5 bezpłatnych narzędzi do tworzenia gier do tworzenia własnych gier 5 bezpłatnych narzędzi do tworzenia gier do tworzenia własnych gier Bezpłatne oprogramowanie do tworzenia gier to świetny sposób na rozpoczęcie tworzenia gier wideo. Zebraliśmy najlepsze oprogramowanie do gier na rynku. !

8. Nieobsługiwane wyjątki

Problem
Wyjątki są potężne, ale łatwo nadużywane. Leniwi programiści, którzy niepoprawnie używają instrukcji catch-catch, mogą utrudnić wykładniczo utrudnienie, jeśli nie niemożliwe. Na przykład ignorowanie lub zakopywanie złapanych wyjątków.

Rozwiązanie
Zamiast ignorować lub zakopywać wychwycone wyjątki, przynajmniej wydrukuj ślad stosu wyjątku, aby debuggery miały z czym pracować. Umożliwienie bezproblemowego działania programu to przepis na przyszłe bóle głowy, gwarantowane! Ponadto wolą wyłapywać określone wyjątki niż wyjątki ogólne. Dowiedz się więcej w naszym artykule o tym, jak prawidłowo obsługiwać wyjątki Jak prawidłowo obsługiwać wyjątki Java Jak prawidłowo obsługiwać wyjątki Java W tym artykule dowiesz się, jakie są wyjątki Java, dlaczego są ważne, jak używaj ich i typowych błędów, których należy unikać. .

9. Duplikat kodu

Problem
Wykonujesz tę samą dokładną logikę w wielu niepowiązanych obszarach swojego programu. Później zdajesz sobie sprawę, że musisz zmodyfikować tę logikę, ale nie pamiętasz wszystkich miejsc, w których ją wprowadziłeś. Ostatecznie zmieniasz go tylko w 5 na 8 miejsc, co powoduje błędne i niespójne zachowania.

Rozwiązanie
Duplikat kodu jest głównym kandydatem do przekształcenia w funkcję. Załóżmy na przykład, że tworzysz aplikację do czatowania i piszesz to:

Ciąg queryUsername = getSomeUsername (); boolean isUserOnline = false; for (String username: onlineUsers) if (username.equals (queryUsername)) isUserOnline = true;  if (isUserOnline) …

Gdzie indziej w kodzie zdajesz sobie sprawę, że musisz wykonać to samo “jest ten użytkownik online?” czek. Zamiast kopiować i wklejać pętlę, możesz wyciągnąć ją do funkcji:

public boolean isUserOnline (String queryUsername) for (String username: onlineUsers) if (username.equals (queryUsername)) return true;  return false; 

Teraz w dowolnym miejscu w kodzie możesz użyć testu isUserOnline (). Jeśli kiedykolwiek będziesz musiał zmodyfikować tę logikę, możesz ulepszyć metodę, która będzie stosowana wszędzie tam, gdzie jest wywoływana.

10. Brak komentarzy

Problem
Kod nie ma nigdzie żadnych komentarzy. Brak bloków dokumentacji dla funkcji, brak przeglądów użycia dla klas, brak wyjaśnień algorytmów itp. Można argumentować, że dobrze napisany kod nie wymaga komentarzy, ale prawda jest taka, że ​​nawet najlepiej napisany kod nadal wymaga więcej energii mentalnej do rozumiem niż angielski.

Rozwiązanie
Podstawą łatwej w utrzymaniu bazy kodu powinien być kod napisany na tyle dobrze, że nie potrzeba komentarze, ale nadal je mają. A podczas pisania komentarzy staraj się komentować czemu fragment kodu istnieje zamiast wyjaśnienia co robi. Komentarze są dobre dla duszy i zdrowia psychicznego. Nie zaniedbuj ich.

Jak pisać kod, który nie pachnie

Jakkolwiek może się to wydawać oczywiste, większość zapachów kodu wynika z nieporozumienia lub zaniedbania dobrych zasad i wzorców programowych. 10 Podstawowych zasad programowania Każdy programista musi przestrzegać 10 podstawowych zasad programowania Każdy programista musi przestrzegać Zawsze pisz kod, który może być utrzymywany przez każdego, kto może zakończyć do pracy nad oprogramowaniem. W tym celu podajemy kilka zasad programowania, które pomogą ci oczyścić swoje działania. . Na przykład solidne przestrzeganie zasady DRY eliminuje większość powielania kodu, a opanowanie zasady Pojedynczej Odpowiedzialności prawie uniemożliwia tworzenie potwornych obiektów Boga.

Zalecamy również przeczytanie naszego artykułu na temat pisania czystszego kodu. 10 porad dotyczących pisania Cleaner & Better Code 10 porad dotyczących pisania Cleaner & Better Code Pisanie czystego kodu wygląda łatwiej niż jest w rzeczywistości, ale korzyści są tego warte. Oto, jak możesz zacząć pisać czystszy kod już dziś. , która dotyczy bardziej praktycznej strony programowania. Jeśli nie możesz odczytać własnego kodu i zrozumieć go na pierwszy rzut oka, jak ktokolwiek inny? Czysty kod to bezwonny kod.

Z czym najbardziej zmagasz się, jeśli chodzi o programowanie? Podziel się z nami w komentarzach poniżej!

Źródło obrazu: SIphotography / Depositphotos