Jak napisać czysty kod i uniknąć bólu głowy

Abstrakcja jest zła. Kod jest przeciwny złu, a czysty kod może być boski. Robert Martin dobrze podsumował:

„Jedyną prawidłową metryką jakości kodu jest What-the-F**k / min.”

Pozwól, że wyjaśnię.

Zawsze, gdy robię code review, mój umysł przywołuje trzy różne emocje:

What-the-F**k (z degustacją) — Ten kod jest zbędny.
What-the-F**k (z podziwem)- Ten gość jest naprawdę sprytny.
What-the-F**k (z irytacją) — Nie mogę zrozumieć tego bełkotu.

W takim razie, co jest pierwszą rzeczą, która wpływa na nas, gdy widzimy jakiś kod? To czystość kodu.

Mówiąc to, często myślimy o „pisaniu kodu”, ale traktujemy to inaczej niż pisanie artykułu lub historii. W rzeczywistości tworzenie kodu przypomina pisanie historii, która jest zgodna z zasadą Ernesta Hemingwaya.

“Pierwszy szkic czegokolwiek to g*wno”.

Pierwszy projekt jakiegokolwiek artykułu nie powinien zostać opublikowany. Na 99% będzie tandetny, niezrozumiały dla czytelników, a autor będzie później zawstydzony. Podobnie pierwsze myśli jakiegokolwiek dewelopera nie są jasne. Kod będzie prawdopodobnie plątaniną pomysłów i różnych składni. Będzie to po prostu pierwszy projekt.

Programistom uchodzi to na sucho, ponieważ kod źródłowy jest w dużej mierze ukryty i nikt nie czyta go przez miesiące, dopóki takie ustrojstwo nie trafi na produkcję. W końcu ktoś przeszuka bzdurny kod, aby znaleźć tam jakiś sens. Gdy zdarza się coraz więcej takich przypadków, kod staje się w końcu niemożliwym do utrzymania koszmarem.

Właśnie tutaj pojawia się istota inwestowania w czysty kod.

Pisanie czystego kodu jest jak inwestowanie czasu, pieniędzy i wysiłku w fundament budynku, aby uczynić go solidnym. Kiedy nadejdzie burza, budynek przetrwa, a inne budynki ze słabymi fundamentami, rozpadną się.

Pisanie czystego kodu prawie zawsze zwraca się w ciągu kilku miesięcy (w zależności od wielkości i skali firmy lub rozwiązania). Kod, który jasno wyraża swój cel bez niespodzianek, jest łatwiejszy do zrozumienia i rzadziej zawiera błędy.

Pisanie przejrzystego i uporządkowanego kodu jest niezbędnym mindsetem programisty. Wymaga praktyki, ale z czasem nauczysz się tak kodować. Musisz jednak zacząć już od myślenia w ten sposób. Przyzwyczaisz się do sprawdzania i korygowania kodu, aby był jak najczystszy.

Oto jak opanować sztukę pisania czystego kodu.

Co mówi nazwa?

Kendrick Lamar powiedział:

„Jeśli mam opowiedzieć prawdziwą historię, zacznę od mojego imienia.”

Nazwy w oprogramowaniu są wszędzie. Nazywamy nasze funkcje, klasy, argumenty, pakiety itd.. Nazywamy pliki źródłowe, katalogi i wszystko z tym związane. Ciągle coś nazywamy, dlatego może stać się to sporym zatorem naszego czystego kodu.

Nazwa powinna ujawniać intencję. Wybór dobrej nazwy wymaga czasu, ale oszczędza dużo więcej innych trudów w przyszłości. Przyłóż się więc do tego, zmieniaj je, gdy znajdziesz lepsze nazwy. Wszyscy czytający później Twój kod będą Ci za to niezmiernie wdzięczni.

Pamiętaj, że nazwa dowolnej zmiennej, funkcji lub klasy, powinna odpowiadać na trzy pytania: dlaczego istnieje, co robi i do czego jest używana.

Funkcja powinny robić tylko jedną rzecz

Louis Sullivan powiedział, że:

“Forma podąża za funkcją.”

Każdy system jest zbudowany z języka specyficznego dla domeny, który został zaprojektowany przez programistów w celu trafnego opisania go. Funkcje są czasownikami tego języka, a klasy rzeczownikami. Funkcje są zwykle pierwszą linią organizacyjną w dowolnym języku programowania, a ich prawidłowe pisanie jest istotą tworzenia dobrego kodu.

Istnieją tylko dwie złote zasady pisania czystych funkcji:

• Powinny być małe
• Powinny robić tylko jedną rzecz i robić ją dobrze

Oznacza to, że Twoja funkcja nie powinna być tak duża, aby pomieścić zagnieżdżone struktury. Dlatego wewnątrz funkcji nie powinno być więcej wcięć niż jedno-dwa. Ta technika ułatwia czytanie, rozumienie i przyswajanie. Oprócz tego musimy również upewnić się, że instrukcje w ramach naszej funkcji są na tym samym poziomie abstrakcji.

Mieszanie poziomów abstrakcji w funkcji jest zawsze bardzo mylące i prowadzi do niemożliwego do zarządzania kodu w odpowiednim czasie. Dobrzy programiści myślą o funkcjach jako o opowieściach, a nie o kodzie do napisania.

Korzystają z udogodnień wybranego języka programowania, aby skonstruować bogatszy, ekspresyjny i czystszy blok kodu, który z łatwością przekaże historię, którą chcą odpowiedzieć.

Komentarze nie rekompensują złego kodu

Venus Williams wymyślił coś prostego i naprawdę prawdziwego:

“Każdy dodaje własne komentarze. Tak zaczynają się plotki.”

Komentarze są jak obosieczny miecz. Nic nie może być bardziej pomocne niż dobrze umieszczony komentarz. Z drugiej strony nic nie zagraca bardziej niż frywolne, bezużyteczne komentarze, zajmujące miejsce. Nic nie może być bardziej szkodliwe niż komentarze szerzące dezinformację i kłamstwa.

Krótko mówiąc, komentarze są w najlepszym razie złem koniecznym. Nie zawsze, ale przez większość czasu.

Im starszy komentarz, tym trudniej go utrzymywać, a większość programistów słynie z tego, że nie utrzymuje komentarzy tak jak kodu. Ten się starzeje, zmienia i ewoluuje, fragmenty kodu przenoszą się tu i tam, a komentarze nie. I to staje się problemem!

Zawsze pamiętaj, że przejrzysty i wyrazisty kod z kilkoma komentarzami jest o wiele lepszy niż zagracony i złożony kod z dużą ilością komentarzy. Nie trać czasu na wyjaśnianie bałaganu, który stworzyłeś, ale na jego usunięcie owszem.

Formatowanie kodu jest priorytetem

Robert C. Martin słusznie powiedział:

“Formatowanie kodu dotyczy komunikacji, a komunikacja jest najważniejsza dla profesjonalnego programisty.”

Powyższego stwierdzenia nie można lekceważyć i być może jest to jedna z najważniejszych cech doskonałego programisty.

Sformatowany kod jest oknem dla jasnego myślenia. Chcemy, aby ludzie byli pod wrażeniem naszego uporządkowania, dbałości o szczegóły i przejrzystości myśli. Ale kiedy patrzą na kod, jeśli widzą zagmatwaną masę kodu, która nie ma wyraźnego początku ani końca, to na pewno szkodzi naszej reputacji.

Jeśli myślisz, że sprawienie, by coś zadziałało, jest dla profesjonalnego programisty priorytetem, to się mylisz. Dzisiejsza funkcjonalność ma duże szanse na zmianę w następnej wersji, ale czytelność tego kodu nigdy się nie zmieni.

Styl i czytelność kodowania wpływają na łatwość utrzymania kodu jeszcze długo, nawet po całkowitym przekształceniu oryginalnego kodu.

Zawsze pamiętaj, że zostaniesz zapamiętany ze względu na swój styl i dyscyplinę, a rzadziej przez pryzmat kodu. Musisz więc zadbać o to, aby Twój kod był ładnie sformatowany i spełniał proste reguły zrozumiałe dla wszystkich członków zespołu.

Napisz “try-catch-finally” w pierwszej kolejności

Georges Canguilhem powiedział:

“Błądzić jest rzeczą ludzką. To pozostawanie w uświadomionym błędzie jest diaboliczne.”

Obsługa błędów to normalka dla każdego programisty. Inputy mogą być nieprawidłowe i urządzenia mogą ulec awarii. Jako programiści powinniśmy się upewnić, że kod działa zgodnie z oczekiwaniami. Problemem nie jest jednak obsługa błędu, ale obsługa go w czytelny sposób.

Wiele kodów jest zdominowanych przez obsługę błędów. Elementy stają się tak rozproszone, że całkowicie niszczą cel i logikę głównego kodu. Jest to całkowicie błędne. Kod powinien być czysty i niezawodny oraz obsługiwać błędy w sposób spójny. To znak rozpoznawczy każdego wielkiego programisty.

Jednym ze sposobów na to jest odpowiednie obudowanie i przechwycenie wszystkich błędów w blokach try-catch. Określają one w pewien sposób zakres Twojego kodu. Kiedy wykonasz kod w try-catch-finally, zauważysz, że wykonanie może zostać przerwane w dowolnym momencie, a następnie wznowione catch.

Z tego powodu dobrą praktyką jest rozpoczynanie pisania kodu od instrukcji try-catch-finally. Pomaga to zdefiniować, czego może oczekiwać użytkownik kodu, bez względu na to, co pójdzie nie tak z kodem wykonanym podczas próby.

Zawsze pamiętaj, że każdy zgłaszany wyjątek powinien zawierać wystarczający kontekst, aby określić źródło i lokalizację błędu.

Kreatywne komunikaty o błędach są zapamiętywane długo po napisaniu kodu i opuszczeniu organizacji przez programistów.

Podsumowanie

Jakie dwa słowa mogłyby podsumować to wszystko? Odpowiedzią jest rozsądny kod, czyli software’owa analogia zdrowego rozsądku.

Według Roberta Martina:

„Pisanie czystego kodu wymaga zdyscyplinowanego użycia niezliczonych małych technik stosowanych przez nabyte boleśnie poczucie „czystości”. Te małe techniki są wspólnie nazywane rozsądnym kodem.”

Niektórzy z nas rodzą się z tym, a niektórzy muszą to boleśnie nabyć poprzez praktykę i wytrwałość. To wyczucie kodu nie tylko pomaga nam odróżnić dobry kod od złego, ale także pomaga nam tworzyć strategie przekształcania złego kodu w dobry.

To wyczucie kodu pomaga programiście wybrać najlepszą wariację i dostępne narzędzie, które poprowadzi go w jego dążeniu do stworzenia czystego kodu o wartości dodanej.

Krótko mówiąc, programista z wyczuciem kodu jest malarzem, który potrafi przekształcić pusty ekran w elegancko wykonane dzieło sztuki, które zostanie zapamiętane na lata.

Zakończmy ten artykuł myślą Harolda Abelsona:

“Programy muszą być napisane tak, aby ludzie mogli je czytać, a tylko przypadkowo, aby maszyny mogły je uruchomić.”


Oryginał tekstu w języku angielskim przeczytasz tutaj.