Pułapki, w które wpadają nawet doświadczeni programiści

Już kilka dekad buduję strony internetowe, oprogramowanie i usługi. Zarządzałem i mentorowałem tuzinowi fullstackowych deweloperów.  W trakcie mojej kariery pracowałem z wieloma osobami, które zmagały się z bardzo podobnymi problemami. Ja również nieraz padłem ofiarą pewnych deweloperskich pułapek. Dziś postaram się opisać sposoby na unikanie paru z nich.

Nie buduj farmy, jeśli po prostu chcesz zjeść jajka na śniadanie

Widzę to cały czas - wielu programistów postanawia przeorganizować prosty projekt ze względu na możliwość, że pewnego dnia będą musieli dodać do niego dodatkowe funkcje, których nie ma obecnie w planie. Oznacza to, że kod będzie bardziej skomplikowany, jego pisanie zajmie więcej czasu, opóźni terminy i będzie wymagać znacznej ilości testów. Zamiast tego spróbuj skupić się na danym zadaniu, a nie na tym, jak może ono wyglądać w przyszłości. Gdy użytkownicy zaczną korzystać z twojego produktu, prawdopodobnie będziesz musiał przepisać te dodatkowe funkcje. Użytkownicy i tak zawsze znajdą nieprzewidziany przez Ciebie sposób korzystania z produktu.

Wybierz narzędzia, których faktycznie potrzebujesz i trzymaj się ich

Kiedy zaczynasz od zera, ważne jest, aby używać wyłącznie narzędzi kompletnych, sprawdzonych i dopasowanych do potrzeb Twojego projektu w jego aktualnym stanie. Twój projekt powinno się dać ukończyć w sposób, który przewidziałeś z wykorzystaniem tych narzędzi w obecnej wersji.

Jeżeli przechodzi Ci przez głowę „och, do czasu jak skończę, to ten framework już wyjdzie z bety” lub „ta funkcja będzie prawdopodobnie i tak dostępna za dwa miesiące”, to są to oznaki, że narzędzie nie spełnia Twoich potrzeb. Co więcej, patrząc na projekty open source, sprawdź, jak często są aktualizowane, ile otwartych zgłoszeń/issues istnieje i ilu posiada aktywnych współtwórców. Nieaktualny projekt lub taki, w którym oryginalny twórca jest jedynym kontrybutorem, to znaki, że powinieneś szukać czegoś innego.

Większość języków programowania daje Ci jakąś możliwość określenia i zablokowania potrzebnej wersji narzędzi. Najlepiej, jeżeli określisz główne wydanie i będziesz się go trzymał. Na przykład, mógłbyś powiedzieć: „W tym konkretnym narzędziu chcę tylko wersję 2. *” lub nawet lepiej „2.4. *”. Po co marnować czas na aktualizację samych narzędzi zamiast spędzać go na rozwijaniu produktu.

Naucz się korzystać z narzędzi

Jeśli korzystasz z platformy, prawdopodobnie istnieje mnóstwo wbudowanych rozwiązań problemów, które próbujesz przezwyciężyć. Być może istnieją specjalne helpery do zapytań do bazy danych lub manipulacji tablicą/obiektem. Bardzo często widzę tony niestandardowego kodu, który można łatwo zastąpić prostszym rozwiązaniem dostępnym we frameworku.

Przeczytaj dokumentację przed rozpoczęciem nowego zadania. Nie bój się zagłębić w kod frameworka - to pomoże Ci nie tylko zrozumieć, jak działa dana funkcja. Obcowanie z profesjonalnie napisanym kodem będzie plusem dla Twoich umiejętności.

Upewnij się, że używasz dobrego edytora lub środowiska IDE. Poznaj jego skróty klawiszowe i wbudowane wstawki kodu. Twórz własne wstawki, aby przyspieszyć powszednie zadania. Przede wszystkim, naucz się debugować. Wydrukowanie zawartości zmiennych lub po prostu słowo „tutaj”, aby sprawdzić, czy wpisuje się w if statement, nie jest właściwym debugowaniem.

Jeśli robisz tylko szybciutki debug, to wypisanie zawartości zmiennej jest w porządku. Jeśli jednak rozwiązanie problemu zajmuje ponad minutę, użyj debugera. Pokaże Ci wszystkie wartości wszystkich aktywnych zmiennych i poprowadzi Cię przez ścieżki kodu. Bardzo cenne informacje i ogromna oszczędność czasu.

Złe komentarze są nieskończenie gorsze niż brak komentarzy

Co to jest zły komentarz? To taki, który stwierdza oczywistość. Jest to komentarz, który nie wyjaśnia, co faktycznie robi blok kodu. Na przykład funkcja o nazwie FetchExtractProcessData z komentarzem, który pisze „Ta funkcja jest odpowiedzialna za pobieranie, wyodrębnianie i przetwarzanie danych.” Ten komentarz nie daje żadnego wyjaśnienia.

Inne przykłady złych komentarzy to takie, które zawierają nieaktualne informacje, kod, który nie jest już obsługiwany, lub słaba i wprowadzająca w błąd gramatyka. Nie potrzebujesz też komentarzy, które nie mówią nic nowego lub po prostu wyjaśniają, jak działa struktura.

Czy osoba, która nie czyta komentarzy, jest w stanie przeczytać Twój kod?

Mam dla Ciebie zabawne zadanie. Znajdź wszystkie komentarze w bazie kodu i całkowicie je usuń. Czy ktoś może bez trudu przeczytać Twój kod? Wspomniany wyżej FetchExtractProcessData to przykład okropnego nazewnictwa. Nie wyjaśnia, co właściwie robi ta funkcja, a duża ilość czasowników sugeruje, że robi o wiele za dużo.

Znacznie ważniejsze jest posiadanie funkcji, klas i zmiennych, które są odpowiednio nazwane i jawne. Nie skracaj żadnej z nich. Używaj języka naturalnego, ale staraj się, aby nazwy zmiennych i funkcji były krótkie, maksymalnie trzy do pięciu słów. Użyj kodu Linter i formatera, aby zachować porządek i czytelność. Upewnij się, że przestrzegasz standardu, który już istnieje dla Twojego języka programowania, zamiast tworzyć własny.

Frontend skierowany do użytkownika jest ważniejszy niż backend

Oto coś, co może wydawać się kontrowersyjne, ale Twój frontend jest bez wątpienia ważniejszy niż backend. Z wyjątkiem sytuacji, gdy Twój projekt nie jest skierowany na ludzi lub będzie przeznaczony do wykorzystania w innych projektach lub przez inne aplikacje, frontend powinien być głównym celem.

Możesz martwić się skalowaniem, buforowaniem i optymalizacją później - ostatecznie przecież nie rozpoczniesz działalności od razu z milionem użytkowników. Jeśli tak zaczniesz, to będziesz posiadał bardzo przyjemny problem i powinieneś się cieszyć z takiego szczęścia. Pomyśl o wszystkich stronach internetowych i aplikacjach, których używasz. Czy używasz ich, ponieważ używają najnowszego i najlepszego stosu technologii? Nie, używasz ich, ponieważ prezentują swoje treści w sposób, który łatwo konsumować, a korzystanie z nich nie jest frustrujące.

To nie jest prztyczek w stronę programistów kodu backendowego. Bez odpowiedniego fundamentu cały projekt upadnie. Nie należy jednak poświęcać ogromnej ilości czasu na pracę nad rzeczami, które tylko Ty lub bardzo mała liczba osób zobaczycie, lub wykorzystacie, a które nie są kluczowe dla powodzenia projektu. Zawsze myśl o całokształcie.

Tworzysz coś dla użytkownika, a nie inżyniera

Ważne jest, aby znać odbiorców i projektować doświadczenie z produktem pod nich. Nie chcesz języka, który zrozumiałby tylko inżynier. „Abort”, „system failure”, „critical issue” odstraszy użytkowników. Używaj prostego, naturalnego języka, który będzie dla nich wygodny i zrozumiały. Nie czytaj z bazy danych, by bez zmiany wypisać komunikat użytkownikowi. Jeśli sam używasz słowa „zniszcz”, aby oznaczyć usuwanie zapisu z bazy, to świetnie, ale zachowaj to dla siebie. „Twój komentarz został pomyślnie usunięty” jest o wiele bardziej przyjazny niż „Sukces: wpis został zniszczony”.

Słowo na koniec

Bardzo łatwo jest dać się złapać codzienności, w trakcie dążenia do perfekcji. Raz na jakiś czas cofnij się trochę i rzuć okiem na całość z daleka. Czy to, nad czym pracujesz, powoduje postęp, czy też spędzasz zbyt wiele czasu na aspekcie, który tak naprawdę nie ma znaczenia? Utrzymuj ład i prostotę i pamiętaj o swoich odbiorcach. Co najważniejsze, baw się dobrze. Kodowanie nigdy nie powinno być uciążliwe.