97 rzeczy które każdy programista powinien wiedzieć. Część pierwsza (1-16)

1073
views

Jakiś czas temu wspominałem na blogu, że chciałbym przerobić cały zbiór 97 rzeczy które każdy programista powinien wiedzieć. Pomyślałem, że mógłbym każdy z tych punktów krótko streścić aby podzielić się z innymi tylko najważniejszymi informacjami z każdej części. Oczywiście zachęcam również do przeczytania pełnych wersji, szczególnie dla tych punktów, które mogą powodować jakieś wątpliwości.

Aby nie tworzyć za dużego szumu na jeden raz postanowiłem podzielić te informacje na 6 postów w których będzie można znaleźć 16 punktów (w ostatniej 17 ;-)).


1. Spłacaj dług techniczny tak szybko jak to możliwe
2. Zaadaptowanie zasad programowania funkcyjnego pozwoli zwiększyć jakość kodu
  • funkcja zwracają zawsze ten sam wynik dla tego samego wejścia, bez względu na to gdzie i kiedy jest użyta
  • powstaje wiele małych funkcji, które są łatwe w utrzymaniu i debugowaniu
3. Użytkownik, który używa Twojej aplikacji nie myśli tak jak Ty

Użytkownicy oprogramowania nie są zwykle tak samo bieli w obsłudze systemów i aplikacji jak ich Twórcy, należy obserwować i monitorować ich zachowania aby lepiej dostosować użyteczność produktu

4. Zadbaj o to aby cały zespół stosował ten sam „Code Style”

Używaj narzędzi do statycznej analizy kodu aby upewnić się, że wszystkie osoby, które uczestniczą w tworzeniu aplikacji posługiwały się tymi samymi zasadami kodowania.

5. Piękno drzemie w prostocie

Jeśli system jest poukładany z małych i prostych części to nie ważne jak bardzo jest duża i skomplikowana całość projektu. Małe obiekty z pojedynczą odpowiedzialnością to klucz do utrzymywalnego i ponadczasowego projektu, który będzie czysty, testowalny i prosty w rozwoju.

6. Dobrze się zastanów zanim zabierzesz się za refactor
  • przed rozpoczęciem refaktoryzacji przyjrzyj się dobrze stanowi kodu i testów
  • unikaj pokusy przepisania wszystkiego od nowa
  • wiele mniejszych zmian jest lepsze od jednej masowej zmiany
  • osobiste preferencje i ego nie powinny być powodem do refaktoryzacji (jeśli coś dobrze działa to po co to poprawiać?)
  • nowa technologia nie jest powodem do refaktoryzacji
  • ludzie zawsze popełniają błędy i nie ma żadnej gwarancji, że poprawki nie wprowadzą dodatkowych błędów
7. Strzeż się współdzielenia kodu

Zanim zdecydujesz się przepisać podobne części kodu z dwóch różnych warstw aplikacji do jednego miejsca zastanów się czy mieszanie kontekstów jest dobrym pomysłem.

8. Zawsze pozostaw moduł w lepszym stanie niż go zastałeś

Jeśli coś dodajesz do kodu to sprawdź czy nie można w nim przy okazji czegoś poprawić. Może warto zmienić nazwę zmiennej, która nie do końca jest jasna, albo podzielić funkcję na dwie mniejsze?

9. Musisz uwierzyć, że mogłeś popełnić błąd

Biblioteki, kompilatory i narzędzia do wytwarzania oprogramowania używane są przez sporą liczbę ludzi i prawdopodobieństwo, że coś w nich nie działa jest dużo mniejsze niż to, że Ty właśnie popełniłeś błąd. Zanim zaczniesz doszukiwać się problemów w zewnętrznych narzędziach najpierw dobrze się upewnij, że zrobiłeś wszystko jak należy.

10. Dobieraj narzędzia rozważnie
  • projekt rozpoczynaj tylko z niezbędnym zestawem dodatkowych bibliotek
  • izoluj zewnętrzne narzędzia od domeny biznesowej
  • zadbaj o odpowiednią abstrakcję
11. Programuj w języku zrozumiałym dla Twojej domeny
  • Nazywaj funkcje i zmienne tak aby były zrozumiałe dla wszystkich (nawet dla osób nietechnicznych)
  • Ukrywaj szczegóły implementacyjne pod zrozumiałym kodem
12. Traktuj kod jako konstrukcję, która wymaga wysokiej jakości

Wielkie konstrukcje wykonane są przez wspaniałych konstruktorów, którzy są mistrzami swojego rzemiosła. Ciągle rozwijaj swoje umiejętności i doskonal projekty nad którymi pracujesz.

13. Styl i wygląd kodu ma znaczenie. Kod powinien wyglądać jak poezja
14. Proces Code Review pozwala utrzymać wysoką jakość kodu
  • zapobiega błędom poprzez szybkie ich wykrycie
  • wszyscy uczestnicy wiedzą co zmienia się w kodzie
  • komentarze powinny być konstruktywne, a nie uszczypliwe
  • pozwala na wymianę wiedzy
15. Kod powinien być samo dokumentujący się – rób małe funkcje skupione na jednym zadaniu
16. Jeśli dodajesz komentarze to muszą być zrozumiałe, proste, krótkie i klarowne