Sprawienie, że Twój kod będzie czysty i piękny, to świetny sposób na dotrzymanie terminów. Robert Martin trafił w sedno jednym ze swoich zwięzłych stwierdzeń: „Jedyną prawdziwą miarą jakości kodu jest jednostka „Co do cholery/minuta” .”” w oryginale). Pozwólcie mi wyjaśnić, co to oznacza. Za każdym razem, gdy przeglądam kod, mój mózg przechodzi przez jedną z trzech emocji:
„WTF?! Co za cholera?!" (z obrzydzeniem) - to nie to... wszystko jest bardzo źle....
„WTF?! Co za cholera?!" (z podziwem) - hmm, mądry facet to zrobił!
„WTF?! Co za cholera?!" (z irytacją) - jakieś zamieszanie, o czym my w ogóle mówimy?!
Co więc jest najważniejsze i co dokładnie oceniamy, gdy widzimy jakiś kod? O to właśnie chodzi: czystość i piękno. Umiejętność pisania czystego i pięknego kodu jest wskaźnikiem wysoce profesjonalnego programisty. Trening tej umiejętności opiera się na dwóch elementach – wiedzy i pracy. Wiedza uczy wzorców, zasad, praktyk, heurystyk. Potrzebujesz ich, aby rozwijać się zawodowo. Tylko Ty musisz chłonąć tę wiedzę jak gąbka poprzez ciągłą praktykę i ciężką pracę. Krótko mówiąc, pisanie czystego kodu nie jest łatwe. To ciężka, żmudna praca i będziesz musiał ciężko nad nią pracować. Metodą prób i błędów będziesz się udoskonalać, powtarzając w kółko te same kroki, aż znajdziesz rozwiązanie, którego szukasz. Prostszego sposobu po prostu nie ma. Poniżej znajduje się kilka wskazówek, które pomogą Ci nauczyć się pisać czysty kod.
Co jest w imieniu
Kendrick Lamar (amerykański artysta hiphopowy – przyp. red.) trafnie zauważył kiedyś: „Jeśli mam opowiedzieć prawdziwą historię, muszę zacząć od mojego imienia”. Nazwiska związane z tworzeniem oprogramowania są wszędzie. Nazywamy funkcje, klasy, argumenty, pakiety, programy – wszystko. Nazywamy pliki źródłowe i podręczniki oraz wszystko, co jest z tym związane. Nazywamy rzeczy bez końca, a to staje się kluczową częścią pracy nad stworzeniem czystego kodu. Nazwa, którą czemuś nadajesz, powinna odzwierciedlać intencję. Znalezienie dobrej nazwy nie jest łatwe, wymaga czasu, ale pozwala też zaoszczędzić sporo czasu, gdy trzeba uporać się z kodem i sytuacja się komplikuje. Zachowaj więc ostrożność podczas tego procesu i nie bój się później zmienić nazwy, jeśli znajdziesz coś bardziej odpowiedniego. Każdy, kto zajmie się Twoim kodem, będzie Ci bardzo wdzięczny.
Pamiętaj, że nazwa dowolnej zmiennej, klasy, funkcji musi odpowiadać na trzy główne pytania: dlaczego ona (zmienna, funkcja itp.) istnieje, do czego służy i do czego służy.
Wymaga to nie tylko dobrych umiejętności opisowych, ale także ogólnej erudycji i szerokiego spojrzenia. I nikt nie nauczy Cię tego lepiej niż Ty sam.
„Jedna funkcja” – jedna rzecz
Louis Henry Sullivan (amerykański racjonalista i modernistyczny architekt) powiedział kiedyś: „funkcja determinuje formę ” . Mówił to o architekturze domów, ale to nie zmienia istoty rzeczy. Każdy system jest zbudowany w oparciu o język specyficzny dla domeny, który programiści tworzą w celu dokładnego opisu. Funkcje pełnią rolę czasowników języka, a klasy są rzeczownikami. Najczęściej w organizacji języka programowania najważniejsze są funkcje, a ich poprawne napisanie jest istotą tworzenia dobrego kodu. Istnieją tylko dwie złote zasady pisania funkcji jakości:
Powinny być małe
Muszą zrobić jedną rzecz, jedno zadanie i zrobić to dobrze
Oznacza to, że Twoja funkcja powinna być mała i nie powinna zawierać zagnieżdżonych struktur. Zatem poziomy wcięcia funkcji nie powinny być większe niż jeden lub dwa. Dzięki takiemu podejściu kod jest znacznie łatwiejszy do odczytania, zrozumienia i zrozumienia. Ponadto musimy mieć pewność, że wyrażenia w ramach funkcji są na tym samym poziomie abstrakcji. Mieszanie poziomów abstrakcji w ramach funkcji zawsze powoduje wiele zamieszania i ostatecznie prowadzi do kodu, którego nie da się zarządzać. Najlepsi programiści traktują funkcje jak historie, które należy opowiedzieć, a nie tylko kod do napisania. Używają narzędzi wybranego języka programowania, aby stworzyć bogaty, wyrazisty i czystszy blok kodu, który zasadniczo może pełnić rolę świetnego gawędziarza.
„Komentarze nie rekompensują złego kodu”
Venus Williams, amerykańska tenisistka i pięciokrotna mistrzyni Wimbledonu, trafiła w sedno, mówiąc: „Każdy zostawia swoje komentarze. Tak właśnie powstają plotki . ” Komentarze są jak miecz obosieczny, dobrze umiejscowiony komentarz jest bardzo przydatny. Z drugiej strony nic nie zaśmieca przestrzeni bardziej niż niepoważne, bezużyteczne komentarze. Jednak najbardziej szkodliwe komentarze to te, które szerzą dezinformację i kłamstwa. Krótko mówiąc, komentarze są rodzajem zła koniecznego. Nie zawsze, ale w większości. Dlaczego? To proste, im starszy komentarz, tym trudniej go utrzymać, a większość programistów, jak wiadomo, nie zawsze zmienia komentarze wraz ze zmianami w kodzie. Kod się zmienia i ewoluuje. Części kodu są przenoszone tam i z powrotem, ale nie ma żadnych komentarzy. I to staje się problemem!
Pamiętaj: czysty, przejrzysty kod z niewielką liczbą komentarzy jest znacznie lepszy niż skomplikowany, zaśmiecony kod. Nie marnuj energii na wyjaśnianie chaosu, który wywołałeś w komentarzach. Lepiej spędzić ten czas na sprzątaniu tego bałaganu.
„Formatowanie kodu jest zawsze priorytetem”
Mówił to nie kto inny jak Robert C. Martin (Robert Cecil Martin), czyli Wujek Bob, programista, autor wielu książek o tworzeniu oprogramowania, konsultant, współautor manifestu Agile i tak dalej. I dodał: „Formatowanie kodu jest rodzajem komunikacji. A komunikacja jest najwyższym priorytetem dla każdego profesjonalnego programisty.” Powyższe stwierdzenie nie powinno być lekceważone, gdyż mówi ono o jednej z najważniejszych cech doskonałego dewelopera. Sformatowany kod pozwala zajrzeć głęboko w umysł. Chcemy imponować schludnością, dbałością o szczegóły, umiejętnością organizowania i jasnego wyrażania myśli. Ale jeśli ludzie, patrząc na kod, zobaczą jakieś zamieszanie przypominające winegret, bez początku i końca, to zniweczy Twoje wysiłki i obniży reputację programisty. Nawet w to nie wątp! Jesteś bardzo daleki od prawdy, jeśli myślisz, że w tym biznesie najważniejsze jest to, że „kod po prostu działa”. Funkcjonalność, którą dzisiaj utworzysz, najprawdopodobniej zostanie zmieniona w kolejnej wersji, ale czytelność kodu nie ulegnie zmianie. Styl kodu i jego dobra czytelność ułatwiają utrzymanie kodu przez długi czas, nawet po zmianie oryginalnego kodu nie do poznania.
Nigdy nie zapominaj, że w przyszłości najprawdopodobniej zapamiętany zostanie nie sam kod, ale Twój styl i spójność. Dlatego zadbaj o to, aby kod był dobrze sformatowany i przestrzegał prostych zasad zrozumiałych dla wszystkich członków zespołu.
Najpierw utwórz blok „try-catch-final”.
Georges Canguilhem (historyk nauki, filozof) słusznie zauważył: „Popełnianie błędów jest dla człowieka czymś naturalnym, ale upieranie się przy błędach pochodzi od diabła ” . Rozwiązywanie problemów to czynność, którą zajmują się wszyscy programiści. Nieprawidłowe dane mogą wejść na wejście i urządzenia mogą ulec awarii. Jako programiści musimy się upewnić, że kod działa tak, jak powinien. Problemem nie jest tylko obsługa błędów, ale „czysta i łatwa do odczytania” obsługa błędów. Wiele programów dostosowuje się do obsługi błędów. Jeśli to zrobisz, wszystko pogrąży się w takim chaosie, że cel i logika głównego kodu zostaną zniszczone. To jest niewłaściwe, nie powinno tak być. Kod powinien być czysty i niezawodny, a obsługa błędów powinna być płynnie i naturalnie wpleciona w kod. To wyznacznik wysokiej klasy programisty. Jednym ze sposobów osiągnięcia tego jest odpowiednie zagnieżdżanie i pokrycie wszystkich błędów w blokach try-catch. Bloki te definiują zakres kodu. Kiedy wykonujesz kod w części try bloku try-catch-finally, stwierdzasz, że wykonanie może zostać przerwane w dowolnym momencie, a następnie wznowione w catch. Dlatego zalecamy rozpoczęcie od try-catch-final podczas pisania kodu. Pomoże to określić, czego użytkownik może oczekiwać od kodu, niezależnie od tego, co pójdzie nie tak z kodem podczas próby.
Zawsze pamiętaj, że każdy zgłoszony wyjątek musi zawierać wystarczający kontekst, aby określić lokalizację i źródło błędu. Kreatywne i informacyjne komunikaty o błędach zapamiętywane są długo po napisaniu kodu, nawet gdy programista jest już zajęty zupełnie innymi zadaniami.
Podsumujmy to
Jedno niezwykłe zdanie pomoże nam podsumować wszystkie powyższe. Jest to poczucie kodu lub „poczucie wspólnego kodu”, rodzaj programistycznego odpowiednika zdrowego rozsądku. Jak mówi Robert Martin: „Pisanie czystego kodu wymaga systematycznego stosowania wielu drobnych technik, stosowanych w wyniku skrupulatnego i nieco bolesnego poczucia „czystości”. Te małe techniki nazywane są łącznie zmysłem kodu . ” Niektórzy z nas mają to „poczucie zdrowego kodu” od samego początku, podczas gdy inni muszą je rozwijać poprzez wytrwałą praktykę. Instynkt ten pomaga nie tylko rozpoznać różnicę między złym a dobrym kodem, ale także pomaga w tworzeniu strategii mających na celu przekształcenie złego kodu w dobry. Zły kod wszystko psuje. Mówiąc w przenośni, jeśli najsmaczniejsze ciasto posmarujesz psim gównem, to… hm… mało kto będzie to lubił. Zmysł kodu pomaga programiście używać odpowiednich narzędzi, aby osiągnąć swój cel, jakim jest stworzenie czystego kodu. Programista, który rozumie, czym jest zmysł kodu, to artysta, który potrafi na pustym ekranie stworzyć dzieło sztuki, które zapadnie w pamięć na długie lata. Jak podsumował to Harold „Hal” Abelson, profesor informatyki na Mit i dyrektor-założyciel Creative Commons i Free Software Foundation: „Programy muszą być najpierw napisane, aby ludzie mogli je przeczytać, a następnie, aby można je było stracony.” samochód” . Co możesz przeczytać na ten temat: „Podręcznik Agile Software Craftsmanship” – Robert Martin. „Podręcznik estymacji Agile” – Mike Cohn O autorze: Ravi Shankar Rajan jest Globalnym Menedżerem Programu IT z Bombaju (Indie). Znany bloger, poeta haiku, zapalony miłośnik archeologii i historii. Możesz połączyć się z nim na Twitterze , Medium , LinkedIn
GO TO FULL VERSION