To już ostatni post z serii streszczeń opartych o zbiór zasad 97 rzeczy które każdy programista powinien wiedzieć. Zapraszam do lektury!
81. Testy powinny być precyzyjne i dokładne
Powinny być testowane konkretne rezultaty, np. jeśli testujemy funkcję sortującą to test powinien sprawdzić dokładny wynik, a nie liczbę zwracanych elementów. Podobnie jak w przypadku dodawania elementu do tablicy nie powinniśmy sprawdzać czy zwiększył się rozmiar tablicy lecz zweryfikować czy element faktycznie istnieje w tablicy.
82. Testuj podczas snu i weekendów
Marnujemy dużo mocy obliczeniowej nie wykorzystując naszych serwerów testujących w nocy i weekendy, a to świetna okazja aby sprawdzić chociażby wydajność naszych aplikacji i znaleźć potencjalne wycieki pamięci.
Podczas normalnej pracy nie mamy czasu odpalać długich testów przed każdym commitem, nie mówiąc już o sytuacji kiedy zbliża się termin oddania projektu. Dlatego uruchamiane są tylko unit testy, które są szybkie, a noc wydaje się idealnym momentem do dłuższych testów.
Poddawanie aplikacji długotrwałym testom może przynieść wiele korzyści, dlaczego by nie odpalać serwerów testujących w piątki o 18:00 tak aby działały do poniedziałku 6:00? To idealny moment na wykrycie błędów, które ukrywają się podczas pobieżnego testowania.
83. Testowanie jest inżynierskim rygorem wytwarzania oprogramowania
Programiści próbując wytłumaczyć czym jest ich praca często porównują się do innych zawodów inżynierskich takich jak budowniczych mostów. Jest to jednak nieprecyzyjne bo trudno porównać programowanie do innych zawodów.
Można jednak porównywać jeden istotny aspekt chociażby do budowania mostów – testowanie. Mamy zwyczaj pomijać testy aby szybciej wykonać zadanie. Podczas projektowania mostu menedżer nie ponagla inżynierów aby zrezygnowali z analizy strukturalnej bo są wąskie terminy.
84. Naucz się myśleć „stanowo”
Wyodrębnienie wyrażeń do znaczących metod to dobry początek, ale najważniejsze jest zrozumienie stanu maszyny. Stosuj Design by Contract Testuj twój kod aby zapewnić poprawny stan, bo jego błędy mogą spowodować utratę danych.
85. Co dwie głowy to nie jedna
Pracując w zespole nie ograniczaj się do wymiany wiedzy na poziomie zadawania pytań lub na ich odpowiadanie. Spróbuj kilkukrotnie programowania w parach aby wyrobić sobie zdanie na temat tej techniki. Jeśli jesteś nową osobą w zespole znajdź do współpracy kogoś kto posiada dużą wiedzę domenową.
86. Kod nigdy nie kłamie, ale może przeczyć sam sobie
Zdarza się, że istnieje błąd w aplikacji, który „przykrywany” jest przez inny błąd. Kiedy ktoś naprawi jeden z nich drugi może okazać się problemem. Nie ma prostych technik na unikanie takich sytuacji, ale warto zawsze podchodzić do programowania z „czystą głową” i próbować przewidzieć wszystkie możliwości, które wynikają z pisania kodu.
87. Programista rozwija się dzięki innym programistom
Jesteś częścią zespołu, ale pracujesz w izolacji rozwiązując problemy poprzez Twoją interpretację. Zacznij rozwijać swoje umiejętności dzięki wymianie wiedzy z innymi członkami zespołu.
88. Zaprzyjaźnij się z Unixowymi narzędziami
Nauka narzędzi unixowych spłaci się bardzo szybko, gdyż są uniwersalne, a do działania potrzebują one tylko linii komend. Większość tych narzędzi zostało opracowanych w czasach gdy zasoby komputerowe były małe, przez co przy dzisiejszej mocy obliczeniowej nadają się do przetwarzania dużych zbiorów danych.
89. Dobieraj odpowiednie algorytmy i struktury danych pod zadanie, które jest do zrealizowania.
90. Zbyt obszerne logowanie może być równie bezużyteczne jak jego brak
91. Stosowanie zasady DRY pozwala na szybsze znalezienie i wyeliminowanie wąskiego gardła w aplikacji
92. Programiści i testerzy powinni ze sobą ściśle współpracować
Kiedy testerzy i programiści pracują ze sobą nad rozbudową aplikacji jakość oprogramowania jest dużo wyższa. Testerzy posiadają wiedzę gdzie mogą występować potencjalne błędy, a programiści posiadają wiedzę jak pisać dobry kod – dzięki temu można tworzyć automaty, które będą testować aplikację. Testerzy powinni przestać myśleć, że ich jedyną pracą jest znalezienie błędów w tworzonym kodzie przez programistów, wtedy programiści przestaną traktować testerów jako osoby, które tylko czekają na ich potknięcia.
93. Pisz kod w taki sposób jakbyś miał go rozwijać i utrzymywać przez resztę życia
94. Zamiast natywnych typów, używaj typów, które są bardziej związane z domeną
95. Pisz testy dla ludzi
Testy powinny nie tylko sprawdzać poprawność działania aplikacji, ale powinny stanowić też swego rodzaju dokumentację projektu. Jeśli nie wiesz czy Twoje testy są wystarczające czytelne – poproś osobę z zewnątrz aby na nie spojrzała i zweryfikuj czy jest w stanie dowiedzieć się co te testy sprawdzają.
96. Dobre programowanie polega na profesjonalnym podejściu i chęci napisania go najlepiej jak się da
- Unikaj „hackowania”, które daje szybkie wyniki i pozwala myśleć, że to działa. Zadbaj o elegancki kod.
- Pisz kod, który jest łatwy do zrozumienia przez innych programistów, utrzymywalny (aby w przyszłości Ty albo ktoś inny mógł go szybko zmodyfikować), poprawny (upewnij się, że na pewno wszystko działa).
- Współpracuj z innymi programistami
- Staraj się pozostawić fragment kodu lepszym niż był początkowo
- Dbając o rozwój wciąż poznawaj nowe języki programowania, narzędzia i techniki. Ale stosuj je tylko gdy jest to potrzebne.
97. Twoi klienci na początku mogą nie widzieć czego rzeczywiście potrzebują
Za każdym razem gdy ustalasz z klientem zakres Twojej pracy upewniaj się co właściwie jest do zrobienia i czy dobrze rozumiesz czego chce klient. Często on sam początkowo nie wie czego potrzebuje – posiada szerszy obraz, ale to Ty powinieneś pomóc mu określić szczegóły.
