97 rzeczy które każdy programista powinien wiedzieć. Część czwarta (49-64)

732
views

Pora na kolejną część dobrych praktyk tworzenia oprogramowania spisanych przez najlepszych ekspertów zawartych w spisie 97 rzeczy które każdy programista powinien wiedzieć. Warto zapoznać się przynajmniej ze streszczeniami, które pojawiają się na tej stronie, ale osobiście zachęcam do przeczytania oryginalnego zbioru.


49. Ucz się „języków obcych”, czyli języków z innych dziedzin. Powinieneś znać język domeny rozmawiając z osobą, która ją reprezentuje.
50. Musisz nauczyć się estymować projekty. Cele i zobowiązania powinny być oparte na estymacjach.
  • Estymata – przybliżony czas realizacji zadania na podstawie doświadczenia programisty.
  • Cel – biznesowe postanowienie, np. jak obsłużyć 400 użytkowników w jednym momencie.
  • Zobowiązanie – obietnica dostarczenia funkcjonalności na pewnym poziomie jakości w konkretnym czasie.
51. Nie bój się kopiować jakiegoś fragmentu kodu do nowego projektu tylko po to aby go zrozumieć.

Pracując nad istniejącym projektem czasem ciężko zweryfikować jak działa dany fragment kodu, a jego przetestowanie jest bardzo trudne. Warto wtedy skopiować ten fragment do nowego projektu w celu szybszej i łatwiejszej weryfikacji działania funkcji.

52. Postaraj się aby informacja o tym, że nie przechodzą testy docierała do Ciebie możliwie jak najszybciej.

Bardzo często na CI ustawiany jest limit na minimalne pokrycie testami i uruchamiane są zestawy testowe, aby przyspieszyć informację o tym, że jakieś kryteria nie są spełnione możesz zastosować technikę XFD (extreme feedback device) – zainstalowanie w biurze urządzenia (np. czerwona lampka), które będzie informowało zespół o tym, że testy nie przeszły.

53. Linker nie jest magicznym narzędziem.

Wielu programistów uważa, że etap podczas procesu kompilacji nazwany Linkerem to jakaś czarna magia. Tak naprawdę nie robi on nic skomplikowanego i jego jedynym zadaniem jest połączyć ze sobą cały kod z wszystkich plików, złączyć referencje symboli z ich definicjami i zapisać plik wykonywalny.

54. Większość rozwiązań tymczasowych zostaje w kodzie na zawsze.

Często te rozwiązania są użyteczne, ale odbiegają od przyjętych standardów. Z czasem kiedy w projekcie przybywa takich „tymczasowych” rozwiązań staje się on coraz trudniejszy w utrzymaniu. Unikaj takich implementacji.

55. Dobre interfejsy są łatwe dla poprawnego ich użycia i trudne do złego użycia. Warto najpierw tworzyć oczekiwania, a dopiero później implementację.
56. Stan Twojego kodu i postęp prac nie jest widoczny bez odpowiednich mechanizmów. Zadbaj o to aby aspekty niewidoczne zostały ujawnione.
  • pisanie unit testów pozwala na ujawnienie jakości Twojego kodu i sposobu działania aplikacji
  • korzystanie z narzędzi do zarządzania zadaniami ujawnia postęp prac nad projektem
  • inkrementacyjny rozwój projektu ujawnia postęp rozwoju
57. Podczas programowania współbieżnego wystrzegaj się współdzielenia pamięci.

Programiści często obawiają się problemów związanych z programowaniem współbieżnym, jednak większość z nich wynika ze współdzielenia pamięci, dlatego warto tego unikać. Zamiast wątków używaj procesów i interfejsu transmisji wiadomości (MPI).

58. O każdej linii twojego kodu, który tworzysz myśl jak o wiadomości do kogoś w przyszłości. Spróbuj napisać kod tak czytelny aby w przyszłości ktoś się nim zachwycił.
59. Polimorfizm jest jednym z ważniejszych mechanizmów w programowaniu obiektowym, poprawne jego stosowanie pozwala zachować czystszy kod i ograniczyć ilość warunków.
60. Testerzy, którzy są zdeterminowani do tego aby odnaleźć błąd w twoim kodzie to twoi najlepsi przyjaciele. Nie oburzaj się kiedy raportują „każdą błahostkę”.
61. Projekt powinien być budowany tylko raz.

Wdrożenia na różne środowiska (developerskie, stage, produkcyjne itp.) powinny korzystać z raz zbudowanej paczki, a zmieniać powinny się jedynie ustawienia środowiskowe. Detale środowiska powinny zawierać się wewnątrz niego, a wszystkie informacje nt. środowiska powinny być wersjonowane osobno od kodu aby szybko zweryfikować zmiany.

62. Tylko kod mówi prawdę!

Dokumentacja często bywa nieaktualna lub różni się od implementacji. Komentarze też bywają błędne lub nieaktualne. Jeśli kod potrzebuje komentarzy to prawdopodobnie potrzebuje refactoru. To kod odpowiada za działanie programu i to on powinien mówić sam za siebie.

Zadbaj o to żeby Twój kod był czytelny. Używaj dobrych nazw, a struktura powinna być spójna z funkcjonalnością. Pisz testy, które tłumaczą zachowanie kodu.

63. Poświęć swój czas na naukę procesu budowania.

Zainwestowany czas w dobre zaprojektowanie procesu budowania w przyszłości zaprocentuje. Proces budowania powinien być traktowanie na równi z powstającym kodem, a dzięki temu zyskasz lepszą jakość i mniejszą ilość błędów.

Programowanie nie jest skończone dopóki nie dostarczymy działającego programu

64. Wypróbuj w zespole programowanie w parach.

Praca w parach [i ich ciągła rotacja] może przynieść Twojemu zespołowi dużo pozytywnych rezultatów.

  • Wymieniaj zadania między parami w celu dzielenia się wiedzą z wszystkimi członkami zespołu.
  • Kiedy jedna para rozwiązuje problem, druga para może zweryfikować to rozwiązanie.
  • Nowe osoby w zespole mogą się znacznie szybciej wdrożyć.
  • Kiedy jedna osoba z pary musi wykonać jakieś zadanie niezwiązane z projektem to druga w tym czasie może utrzymać skupienie na konkretnym zadaniu.