To już przedostatni post z cyklu streszczeń artykułów pt. 97 rzeczy które każdy programista powinien wiedzieć, jak zawsze zachęcam do przejrzenia oryginału.
65. Zamiast używać typów prostych lepiej używać typów domenowych (zdefiniowanych przy pomocy klas), które określają zachowanie danego bytu. Dobrym przykładem może być stosowanie Value Object.
66. Staraj się zrozumieć użytkowników i przewidzieć jakie mogą popełnić błędy aby uodpornić system na zwracanie błędów – nie zawsze jest to potrzebne.
Łatwo jest zwrócić użytkownikowi error kiedy wprowadzi złe dane, jednak czasem użytkownik może źle zinterpretować działanie systemu. Wartość w polu formularza wcale nie musi od razu zwracać informacji o błędzie, ponieważ można przygotować aplikację w taki sposób aby usunęła tę spację.
Z pomocą może przyjść system logowania zachowań użytkowników aby sprawdzić gdzie najczęściej popełniają błędy, dzięki temu lepiej zrozumiemy użytkowników.
67. Profesjonalny programista to osoba odpowiedzialna!
- odpowiedzialny za swój rozwój, o którego dba po godzinach swojej pracy
- bierze odpowiedzialność za swój kod, nie odda czegoś za co nie ma pewności i nie wie czy to zadziała
- profesjonaliści są graczami drużynowymi – nie dbają tylko o swoją część pracy, ale również o jakość pracy całego zespołu
- nie toleruje narastającej liczby tasków i bugów w „backlogu”
- nie lubi bałaganu, stosuje dobre praktyki i nigdy nie działa w pośpiechu („zrobię teraz na szybko gorzej, a później poprawię„)
68. Trzymaj wszystko w systemach kontroli wersji (git, svn).
- kazdą zmianę logiki traktuj jako osobną operację i zacommituj ją
- każdy commit powinien posiadać krótki i wyjaśniający komentarz czego dotyczą zmiany
- Nie commituj kodu, który nie działa
69. Jeśli nie potrafisz rozwiązać problemu i siedzisz nad nim od dłuższego czasu zrób sobie przerwę.
Oderwanie się od kontekstu tego zadania pozwala ci sporzeć na nie z innej perspektywy po powrocie. Jest duże prawdopodobieństwo, że zrobisz to od razu. Pewnie przeżyłeś to już nie raz 😉
70. Programiści uwielbiają pisać kod, ale nie lubią go czytać.
Czytanie kodu bywa trudne, szczególnie cudzego. Następnym razem gdy będziesz czytać czyjś kod postaraj się z tego coś wyciągnąć i czegoś się nauczyć. Jeśli jest nieczytelny lub źle skonstruowany zadaj sobie pytanie dlaczego, odpowiedz na nie i nie popełniaj cudzych błędów.
71. Aplikacje tworzone są przez ludzi wraz z innymi ludźmi dla ludzi. Skupmy się na „dialogu” z innymi współtwórcami i odbiorcami aplikacji.
72. Odkrywanie koła na nowo pozwala rozwinąć umiejętności programistyczne.
Tworząc własne narzędzie od podstaw mimo, że istnieje już gotowe pozwoli to poznać jak zostało to zrobione i zdobyć dodatkowe doświadczenie. Dodatkowo można zobaczyć jak to jest zrobione „pod spodem” i przekonać się z czym mierzyli się inni programiści.
73. Unikaj stosowania wzorca Singleton
- jeśli stosowany jest Singleton i wymagania odnośnie aplikacji się zmieniają trzeba wiele rzeczy zmieniać – dobry design jest odporny na zmiany
- Singleton sprawia, że pojawiają się problemy zależnościami i tworzy niepotrzebne połączenia między elementami systemu co utrudnia np. tworzenie unit testów
- Singleton często przechowuje ukryty stan co utrudnia testowanie
- wywołuje problemy w programowaniu wielowątkowym
74. Używaj narzędzi do analizy wydajności
Metryki oprogramowania pozwolą znaleźć zły kod, którego można wyeliminować zanim stanie się realnym problemem.
75. Kod musi być prosty!
W kodzie powinna występować minimalna liczba zmiennych, funkcji, deklaracji it… Wszystko co jest dodatkowe powinno zostać natychmiast usunięte.
76. Zasada jednej odpowiedzialności
Na temat zasady SRP napisano już tak wiele, że lepiej jak pojawią się tutaj po prostu odnośniki do innych artykułów:
- SOLID – część 1. Zasada Jednej Odpowiedzialności
- SOLID z easyGALib: Zasada pojedynczej odpowiedzialności
- Zasada pojedynczej odpowiedzialności
77. Zawsze staraj się mówić „TAK” do swojego rozmówcy
Zaczynając odpowiedź od „tak” pracujesz z twoimi kolegami, a nie przeciwko nim. Jeśli ktoś będzie chciał wprowadzić jakieś „dziwne” zmiany z twojej perspektywy w systemie, nad którym pracujecie to zamiast od razu go odrzucać zadaj pytanie „dlaczego” i postaraj się zrozumieć potrzeby.
78. Zatrzymaj się, confnij się i zautomatyzuj pracę, którą wciąż wykonujesz cyklicznie
- automatyzacja nie jest przeznaczona tylko do testów
- IDE nie zwalnia z automatyzowania zadań
- aby automatyzować nie jest potrzebna znajomość egzotycznego języka i narzędzi
- nie poddawaj się jeśli na pierwszy rzut oka wydaje ci się, że nie da się tego zautomatyzować
- nie zasłaniaj się brakiem czasu, przecież masz czas na to żeby wciąż robić to samo
79. Stosowanie statycznej analizy kodu pozwoli ci znaleźć potencjalne problemy w kodzie
80. Testy powinny sprawdzać wymagania, a nie implementację
Lepiej stosować zasadę czarnej skrzynki gdzie na podane wejście oczekujemy jakiegoś wyjścia, a nie zasadę białej skrzynki gdzie testujemy kolejno kroki wykonywane przez funkcję.
