Upewnij się, że twój kod „może być dobry”
Pierwszym i prawdopodobnie najważniejszym krokiem do napisania dobrego kawałka kodu jest to, aby w ogóle nie kodować.
- Czy zweryfikowałeś swoje założenia?
- Jaki jest zakres kodu?
- Jak wpłynie on na istniejący kod?
- Czy ktoś już napisał ten kod?
Umiejętność odpowiedzi na takie pytania jest podstawą dobrego kodu.
Omawiaj z innymi
Najlepszym sposobem na potwierdzenie swoich wyborów jest uzyskanie opinii innych. Staraj się przebywać w środowisku, w którym ludzie nie boją się kwestionować Twoich decyzji i ideałów.
Nawet najsilniejszy mur może wydawać się słaby, gdy spojrzy się na niego z odpowiedniej perspektywy.
Rozbij na czynniki pierwsze
Teraz, gdy jesteś pewien, że twój kod „może być dobry”, nadszedł czas, aby dowiedzieć się, jak faktycznie uczynić go dobrym. Zacznij od myślenia w kategoriach API i spróbuj rozbić swój proponowany kod na jak najmniejsze kawałki.
Zrozumienie, jak podzielić zadania na mniejsze kawałki, jest numerem jeden, z którym zmagają się młodsze programy. Pamiętaj, że kawałek kodu, który rozbiłeś, to taki, z którym inni są w stanie ci pomóc. Pozostawiony jako monolit, służy tylko do odizolowania cię od zespołu.
Pierwsza część fazy projektowania kodu powinna bardzo rzadko dotykać implementacji. Zamiast tego powinieneś zajmować się potrzebami i ograniczeniami. Czas spędzony na implementacji jest często zmarnowanym czasem, ponieważ zmiany API wysokiego poziomu mogą unieważnić założenia implementacyjne. Z mojego osobistego doświadczenia, rozpoczęcie dyskusji o implementacji z już uzgodnionym API, zwykle sprawia, że dyskusja idzie o wiele płynniej.
Pisz testy, które definiują je przed napisaniem (pikantne i opiniotwórcze)
Teraz, gdy wiesz, jak rozbić kod. Napisz test dla każdej dyskretnej jednostki, którą zidentyfikowałeś. Pisanie testów dla każdej funkcjonalności, którą Twój kod będzie eksponował, zanim go zakodujesz, jest cechą definiującą TDD (Test Driven Development). Przeprowadzono wiele badań na temat skuteczności TDD. Podczas gdy niektóre z nich są kontrowersyjne, prawie wszystkie zgłaszają pozytywną poprawę liczby błędów po użyciu TDD.
Wierzę, że test driven development zmusza Cię do postawienia się w punkcie widzenia użytkowników jako pierwszy, a to zaowocuje bardziej praktycznym i naturalnym zestawem API.
Oprzyj się pokusie, aby zająć się wieloma zadaniami naraz. Powinieneś pisać nieudane testy dla pojedynczej jednostki kodu, a następnie pisać implementację dla tego testu. Pozwoli to na efektywną walidację projektu i utrzymanie pokrycia testowego, nawet jeśli dodajesz kod do bazy danych.
Zachowaj spójność
Osobisty styl i preferencje będą się różnić między deweloperami. To, co nie powinno się różnić, to spójność kodu. Powinieneś mieć spójne i przewidywalne konwencje nazewnictwa dla zmiennych i deklaracji. Jeśli używasz tabulatorów, powinieneś używać ich wszędzie. Jeśli używasz spacji, powinieneś używać spacji wszędzie.
Wielu młodszych programistów łapie się na niuansach każdego wyboru. W rzeczywistości o wiele ważniejsze jest to, jak bardzo jesteś niezawodny w swoim wyborze. Na początku może się to wydawać stosunkowo małym zadaniem, ale spójność rozciąga się daleko poza tabulatory i spacje.
Logika Twojego kodu również musi być spójna. Dlaczego użyłeś mapy tutaj, a for each tam? Dlaczego używasz var w niektórych miejscach, a let i const w innych? Przewidywalność jest jedną z najtrudniejszych cech do znalezienia u programisty (lub człowieka w ogóle), jest też jedną z najcenniejszych.
Twoja wartość jako programisty jest określona przez twoją „maksymalną potencjalną wartość” pomnożoną przez twoje „przewidywane ryzyko”. Jakość jest bez znaczenia bez niezawodności.
Przeglądaj
Jeśli kod trafia do masteru, powinien zostać zrecenzowany. Aby recenzja była korzystna, autor musi naprawdę docenić wartość procesu recenzji.
Nigdy w tym życiu nie będziesz wiedział wszystkiego.
Dobry programista pisze świetny kod i nie poddaje go recenzji. Świetny programista pisze przyzwoity kod, ale poddaje go szczegółowemu procesowi recenzji.
Dobry programista pisze świetny kod i nie poddaje go recenzji.
Świetny programista pisze przyzwoity kod, ale poddaje go szczegółowemu procesowi recenzji.
Powinieneś liczyć się z porażką w każdym aspekcie swojego życia, w tym w kodowaniu. Błędy będą popełniane i najczęściej wszystko, co jest potrzebne, aby je powstrzymać, to inny zestaw oczu.
Zobacz też: 10 sygnałów, że ogłoszenie o pracę może być fałszywe
Wyślij na produkcję!
Gratulacje, napisałeś teraz dobry kawałek kodu! Możliwe jest napisanie dobrego kawałka kodu bez tego procesu, ale nie jest możliwe, aby „zawsze pisać dobry kawałek kodu” bez niego.
Po wysyłce pamiętaj, aby komunikować się ze swoim zespołem o tym, co osiągnąłeś, może to odblokować kogoś.
Nie zastanawiaj się długo
Każda zasada powinna być traktowana z przymrużeniem oka. Czy 2-liniowy commit do wewnętrznego README naprawdę powinien być przeglądany?
Staraj się stosować najlepsze praktyki, ale pozostań praktyczny i racjonalny, nie projektuj rzeczy, które nie muszą być projektowane w pierwszej kolejności. Najważniejszym narzędziem, które masz w swoim arsenale, jest twoje jelito (intuicja). Reguły nie istnieją po to, aby wchodzić Ci w drogę, istnieją po to, aby być konsekwentnym i niezawodnym, kiedy Ty nie jesteś (i nie będziesz).
Wpis na podstawie artykułu: https://dev.to/taillogs/how-to-write-a-good-piece-of-code-2gmj