97 rzeczy które każdy programista powinien wiedzieć. Część druga (17-32)

Nadszedł czas na drugi post cyklu „97 rzeczy które każdy programista powinien wiedzieć” dotyczącego dobrych praktyk programowania.


17. Komentuj tylko to czego kod nie może powiedzieć

Bardzo często kod się zmienia, ale komentarze pozostają te same i nie są aktualne. Z tego powodu programiści zaczynają je ignorować co prowadzi do tego, że można pominąć istotne informacje. Komentarz powinien zawierać jakąś wartość dla czytającego.

18. Aby zapewnić dobry rozwój swojej kariery musisz poświęcić na to trochę wolnego czasu
  • czytaj książki i magazyny techniczne
  • aby poznać lepiej technologię napisz trochę kodu
  • staraj się mieć mentora, który będzie Cię uczyć
  • subskrybuj blogi
  • staraj się uczyć innych
  • odwiedzaj konferencje
19. Staraj się jasno nazywać Twoje funkcje aby wyjaśniały to co mają robić
20. Nie zostawiaj sprawy związanej z procesem instalacji i deploymentu na koniec projektu. To równie ważna rzecz jak kod źródłowy.
21. W aplikacjach można wydzielić dwa typy wyjątków: techniczne i wynikające z niezgodności logiki domenowej, które muszą być traktowane inaczej.

[Więcej na ten temat można przeczytać w poście Obsługa wyjątków]

22. Rozmyślna praktyka to umiejętność wychodzenia z własnej strefy komfortu

Ciągłe robienie czegoś w czym jest się dobrym nie pozwala na rozwój, warto czasem stawiać sobie cele aby wykonać zadania na mniej znanych płaszczyznach. Ciągle się ucz i obserwuj jak rozwój zmienia Ciebie i Twoje zachowania.

23. Specyficzna domena posiada wyspecjalizowany język do opisu szczegółów (DSL). Ukrywaj detale techniczne pod językiem domenowym.
24. Jeśli traktujesz swój projekt jak wieżę Jenga i boisz się wprowadzać zmiany to gdzieś jest błąd

Zawsze musisz dbać o „stan zdrowia” kodu aplikacji. Nie możesz się bać wprowadzać zmian w swoim kodzie, a jeśli uważasz, że najmniejsza zmiana może powodować problemy to powinieneś zainwestować czas w refaktoryzację.

25. Za każdym razem kiedy dokonujesz zmian w kodzie (komentarz, kod, logi) – zawsze zastanów się czy byłbyś gotów pokazać to światu bez obawy na krytykę
26. Jeśli ignorujesz błędy czy ostrzeżenie i wierzysz, że nic złego się nie wydarzy to podejmujesz ogromne ryzyko
27. Nie ucz się tylko języka, poznaj jego kulturę

Przykładowo, jeśli programujesz w języku funkcyjnym – poznaj co to lambda, kiedy programujesz w języku obiektowym zapoznaj się z zasadami OOP.

28. Nigdy nie pokazuj użytkownikowi raportu z wyjątku
29. Nie musisz rozumieć całej „magii”, która odbywa się w Twoim projekcie, jednak powinieneś ciągle poszerzać swoją wiedzę na temat środowiska w którym pracujesz

Kiedy wszytko działa dobrze, to jesteś zadowolony, jednak w sytuacji krytycznej możesz mieć duże problemy jeśli nie posiadasz wiedzy na temat szerszego kontekstu.

30. Nie powtarzaj się! (DRY)
  • developer, który widzi powtórzenia i wie jak je usunąc tworzy czystszy kod
  • każdy kawałek wiedzy musi mieć pojedyńczą jednoznaczą reprezentację w systemie
  • każdy proces wykonywany manualnie musi być automatyzowany
31. Developerzy nie powinni mieć dostępu do kodu na środowisku produkcyjnym i stage
  • wszystkie zmiany muszą być dokonywane na maszynie lokalnej
  • nigdy nie dokonuj zmian na żywym kodzie w środowisku prodykcyjnym
32. Hermetyzuj zachowania, a nie tylko stan

Często w projektach spotyka się bardzo złą praktykę i zdarza się zauważyć klasy z samymi metodami get/set, które zarządzane są przez nadrzędne serwisy, gdzie znajduje się jedna funkcja, która „robi wszystko”.

Programista skupiony głównie wokół technologii webowych, ale nie przywiązujący się do konkretnych języków i narzędzi. Skoncentrowany na ciągłym rozwoju, zwolennik ruchu Software Crafmanship. Na codzień pracując w DAZN ma okazję rozwijać interesujący projekt do streamingu wydarzeń sportowych. Prywatnie fan sportu, a szczególnie piłki nożnej. Po godzinach próbuje również swoich sił w piwowarstwie domowym.
PODZIEL SIĘ