Brian Curtis
0 
4152
1037
Każdy może napisać kod. Ale dobry kod? To tam staje się trudne.
Wszyscy słyszeliśmy horrory o kodzie spaghetti, ogromnych łańcuchach if-else, całych programach, które mogą się zepsuć, zmieniając tylko jedną zmienną, funkcjach, które wyglądają, jakby były zaciemnione i tak dalej. Tak się dzieje, gdy próbujesz stworzyć produkt nadający się do wysyłki, mając tylko semestr doświadczenia w programowaniu.
Nie zadowalaj się pisaniem tego kodu Prace. Cel, aby napisać kod, który może być utrzymywanym - nie tylko przez ciebie, ale także przez kogokolwiek innego, kto może w przyszłości pracować nad oprogramowaniem. W tym celu, oto kilka zasad, które pomogą ci oczyścić swój czyn.
1. KISS
The “niech to będzie możliwie proste” zasada dotyczy praktycznie całego życia, ale jest to szczególnie konieczne w średnich i dużych projektach programistycznych.
Zaczyna się od samego początku, kiedy definiujesz zakres tego, co chcesz stworzyć. To, że pasjonujesz się tworzeniem gier, nie oznacza, że możesz stworzyć następne World of Warcraft lub GTA. Jeśli uważasz, że masz wystarczająco uproszczone, uprość je o jeden poziom dalej - pełzanie funkcji jest nieuniknione, więc zacznij od małych.
Ale nawet po rozpoczęciu kodowania zachowaj prostotę. Złożony kod zajmuje więcej czasu na projektowanie i pisanie, jest bardziej podatny na błędy i błędy oraz trudniej jest go później zmodyfikować. W mądrych słowach Antoine de Saint-Exupery, “Perfekcję osiąga się nie wtedy, gdy nie ma już nic do dodania, ale kiedy nie ma już nic do zabrania.”
2. SUSZENIE
The “nie powtarzaj się” zasada ma kluczowe znaczenie dla czystego i łatwego do modyfikacji kodu. Pisząc kod, chcesz uniknąć powielania danych i powielania logiki. Jeśli zauważysz, że ten sam fragment kodu jest zapisywany w kółko, łamiesz tę zasadę.
Przeciwieństwem kodu DRY jest kod WET: “napisz wszystko dwa razy” (lub “marnować czas każdego”). Jednym z najlepszych sposobów zdiagnozowania kodu WET jest postawienie sobie pytania: aby w jakiś sposób zmienić zachowanie programu, ile obszarów kodu należy zmodyfikować?
Załóżmy, że piszesz aplikację katalogu podcastów. Na stronie wyszukiwania znajduje się kod do pobierania szczegółów podcastu. Na stronie podcastu masz kod do pobrania szczegółów tego podcastu. Na stronie ulubionych ten sam kod pobierania. Zastanów się nad wyodrębnieniem tego wszystkiego w funkcję, aby później móc edytować go w jednym miejscu.
3. Otwarte / zamknięte
Czy piszesz obiekty Czym jest programowanie obiektowe? Podstawy wyjaśnione w terminach laika Czym jest programowanie obiektowe? Podstawy wyjaśnione w terminach laika Większość współczesnych języków programowania obsługuje paradygmat „programowania obiektowego” (OOP). Ale czym dokładnie jest OOP i dlaczego jest tak przydatny? w Javie lub modułach w Pythonie powinieneś dążyć do stworzenia swojego kodu otwarte na rozszerzenie, ale zamknięte na modyfikacje. Dotyczy to wszystkich rodzajów projektów, ale jest to szczególnie ważne, gdy zwalniasz bibliotekę lub platformę przeznaczoną dla innych.
Załóżmy na przykład, że utrzymujesz środowisko GUI. Możesz go wypuścić w obecnej postaci, oczekując, że użytkownicy końcowi bezpośrednio zmodyfikują i zintegrują zwolniony kod. Ale co się stanie, gdy wydasz ważną aktualizację cztery miesiące później? W jaki sposób wdrażają wszystkie twoje dodatki bez wyrzucania całej pracy, którą wykonali?
Zamiast tego zwolnij kod zapobiega bezpośrednia modyfikacja i zachęca rozbudowa. Oddziela to zachowanie podstawowe od zachowania zmodyfikowanego. Korzyści? Większa stabilność (użytkownicy nie mogą przypadkowo złamać podstawowego zachowania) i większa łatwość konserwacji (użytkownicy martwią się tylko o rozszerzony kod). Zasada otwarta / zamknięta jest kluczem do stworzenia dobrego interfejsu API Czym są interfejsy API i jak są otwarte interfejsy API zmieniające Internet Czym są interfejsy API i jakie są otwarte interfejsy API zmieniające Internet Czy zastanawiałeś się kiedyś, jak programy na komputerze i odwiedzane strony internetowe "rozmawiać ze sobą? .
4. Skład> Dziedziczenie
The “skład nad spadkiem” zasada stwierdza, że obiekty ze złożonymi zachowaniami powinny to robić poprzez zawieranie instancji obiektów z indywidualnymi zachowaniami zamiast dziedziczenia klasy i dodawania nowych zachowań.
Nadmierna zależność od dziedziczenia może prowadzić do dwóch głównych problemów. Po pierwsze, hierarchia dziedziczenia może stać się nieporządna w mgnieniu oka. Po drugie, masz mniejszą elastyczność w definiowaniu zachowań w przypadkach specjalnych, szczególnie gdy chcesz zaimplementować zachowanie z jednej gałęzi dziedziczenia w innej gałęzi dziedziczenia:
Kompozycja jest znacznie prostsza w pisaniu, łatwiejsza w utrzymaniu i pozwala na niemal nieograniczoną elastyczność w zakresie tego, jakie rodzaje zachowań możesz zdefiniować. Każde indywidualne zachowanie jest własną klasą, a Ty tworzysz złożone zachowania poprzez łączenie indywidualnych zachowań.
5. Jedna odpowiedzialność
The zasada pojedynczej odpowiedzialności mówi, że każda klasa lub moduł w programie powinien zajmować się tylko zapewnianiem jednego kawałka określonej funkcjonalności. Jak to ujął Robert C. Martin, “Klasa powinna mieć tylko jeden powód do zmiany.”
Klasy i moduły często zaczynają się w ten sposób, ale w miarę dodawania funkcji i nowych zachowań łatwo jest im ewoluować w klasy Boga i moduły Boga, które zajmują setki, a nawet tysiące linii kodu. W tym momencie powinieneś podzielić je na mniejsze klasy i moduły.
6. Rozdzielenie obaw
The zasada separacji obaw jest jak zasada pojedynczej odpowiedzialności, ale na bardziej abstrakcyjnym poziomie. Zasadniczo program powinien być zaprojektowany tak, aby zawierał wiele różnych nie nakładających się enkapsulacji, a enkapsulacje te nie powinny się o sobie wiedzieć.
Dobrze znanym przykładem tego jest paradygmat model-view-controller (MVC), który dzieli program na trzy odrębne obszary: dane (“Model”), logika (“kontroler”) i to, co widzi użytkownik końcowy (“widok”). Odmiany MVC są powszechne w dzisiejszych najpopularniejszych platformach internetowych.
Źródło zdjęcia: Wikimedia
Na przykład kod, który obsługuje ładowanie i zapisywanie danych w bazie danych, nie musi wiedzieć, jak renderować te dane w Internecie. Kod renderujący może pobierać dane wejściowe od użytkownika końcowego, ale następnie przekazuje te dane wejściowe do kodu logicznego w celu przetworzenia. Każda część obsługuje się sama.
W rezultacie powstaje modułowy kod, który znacznie ułatwia konserwację. A w przyszłości, jeśli kiedykolwiek będziesz musiał przepisać cały kod renderowania, możesz to zrobić bez obawy o to, jak dane zostaną zapisane lub logika zostanie przetworzona.
7. YAGNI
The “nie będziesz tego potrzebować” zasada to pomysł, że nigdy nie należy kodować pod kątem funkcjonalnej funkcjonalności może potrzeba w przyszłości. Możliwe, że ty przyzwyczajenie potrzebujesz go, a to będzie strata czasu - i nie tylko, ale niepotrzebnie zwiększy złożoność twojego kodu.
Można to postrzegać jako konkretne zastosowanie zasady KISS i odpowiedź dla tych, którzy zbyt poważnie podchodzą do zasady DRY. Często niedoświadczeni programiści próbują napisać najbardziej abstrakcyjny i ogólny kod, aby uniknąć kodu WET, ale zbyt wiele abstrakcji kończy się rozdętym, niemożliwym do utrzymania kodem.
Sztuką jest stosowanie zasady OSUSZANIA tylko wtedy, gdy jest to konieczne. Jeśli zauważysz, że fragmenty kodu są pisane w kółko, to je streszczaj - ale nigdy, kiedy ty myśleć fragment kodu będzie zapisywany w kółko. Więcej razy, nie będzie.
8. Unikaj przedwczesnej optymalizacji
The brak przedwczesnej zasady optymalizacji jest podobny do zasady YAGNI. Różnica polega na tym, że YAGNI odnosi się do tej tendencji wdrażać zachowania zanim będą konieczne, podczas gdy ta zasada dotyczy tendencji do algorytmy przyspieszenia zanim będzie to konieczne.
Problem z przedwczesną optymalizacją polega na tym, że tak naprawdę nigdy nie wiadomo, gdzie będą wąskie gardła programu. Oczywiście możesz zgadywać, a czasem możesz nawet mieć rację. Ale częściej tracisz cenny czas, próbując przyspieszyć funkcję, która nie jest tak wolna, jak myślisz lub nie jest wywoływana tak często, jak się spodziewałeś.
W takim razie osiągaj kamienie milowe tak prosto, jak to możliwe profiluj swój kod zidentyfikować prawdziwe wąskie gardła.
9. Refaktor, Refaktor, Refaktor
Jedną z najtrudniejszych prawd, które należy zaakceptować jako niedoświadczony programista, jest to kod rzadko pojawia się za pierwszym razem. Może czuć zaraz po wdrożeniu tej nowej, błyszczącej funkcji, ale gdy program staje się coraz bardziej złożony, przyszłe funkcje mogą być utrudnione przez sposób, w jaki napisałeś tę wczesną.
Podstawy kodowe stale się rozwijają. Ponowne odwiedzanie, przepisywanie, a nawet przeprojektowywanie całych fragmentów kodu jest całkowicie normalne - i to nie tylko normalne, ale i zdrowe. Wiesz więcej o potrzebach swojego projektu teraz niż kiedy zrobiłeś w początek, i powinieneś regularnie wykorzystywać tę nowo zdobytą wiedzę do refaktoryzacji starego kodu.
Pamiętaj, że nie zawsze musi to być duży proces. Weź stronę od skautów Ameryki, żyjących według tych słów: “Zostaw kemping czystszy, niż go znalazłeś.” Jeśli kiedykolwiek chcesz sprawdzić lub zmodyfikować stary kod, zawsze go wyczyść i pozostaw w lepszym stanie.
10. Wyczyść kod> Sprytny kod
Mówiąc o czystym kodzie, zostaw swoje ego u drzwi i zapomnij o pisaniu sprytnego kodu. Wiesz o czym mówię: rodzaj kodu, który bardziej przypomina zagadkę niż rozwiązanie i istnieje wyłącznie po to, by pokazać, jak jesteś inteligentny. Prawda jest taka, że tak naprawdę nikogo to nie obchodzi.
Jednym z przykładów sprytnego kodu jest umieszczenie jak największej logiki w jednym wierszu. Innym przykładem jest wykorzystanie zawiłości języka do pisania dziwnych, ale funkcjonalnych instrukcji. Wszystko, co może spowodować, że ktoś powie “Czekaj, co?” kiedy przeglądasz swój kod.
Dobrzy programiści i czytelny kod idą w parze. Zostaw komentarz, jeśli to konieczne. Przestrzegaj przewodników po stylach, niezależnie od tego, czy jest to podyktowane przez język (jak Python), czy przez firmę (jak Google). Obserwuj idiomy dla poszczególnych języków i przestań pisać kod Java w Pythonie lub odwrotnie. Zobacz nasz artykuł na temat pisania czystszego kodu 10 porad na temat pisania czystszego i lepszego kodu 10 porad na temat pisania czystszego i lepszego kodu Pisanie czystego kodu wygląda łatwiej niż jest w rzeczywistości, ale korzyści są tego warte. Oto jak zacząć pisać czystszy kod już dziś. .
Co czyni dobrego programistę?
Zapytaj pięć osób, a otrzymasz 10 różnych odpowiedzi. Dla mnie dobry programista to taki, który rozumie, że kodowanie powinno ostatecznie służyć użytkownikowi końcowemu, z którym łatwo współpracować w zespole i który kończy swoje projekty zgodnie ze specyfikacją i na czas.
Jeśli czujesz, że utkniesz, zobacz nasz artykuł na temat pokonywania bloku programisty. A jeśli po prostu nie jesteś zadowolony z pisania kodu, przeczytaj nasz artykuł o znakach, że nie jesteś programistą.
Jeśli dopiero zaczynasz, skoncentruj się na nauce programowania bez stresu. Nie wiesz, w którym języku programowania nurkować jako pierwszy? C # jest dobrym miejscem do rozpoczęcia ze względów praktycznych 7 Praktycznych powodów do nauki Programowanie w C # 7 Praktycznych powodów do nauki Programowanie w C # Istnieje wiele języków programowania, więc którego wybrać? Oto kilka powodów, dla których warto nauczyć się języka C #. . A jeśli wybierzesz, weź także pod uwagę te wskazówki programowania C 5 porad programowania C musisz nauczyć się zacząć 5 porad programowania C musisz nauczyć się języka programowania C ma trudną reputację. Ale jeśli poradzisz sobie z tym, możesz zaprogramować wszystko, jak pokazują te wskazówki. .