97 rzeczy które każdy programista powinien wiedzieć. Część trzecia (33-48)

Po wakacyjnej przerwie trzecia część serii streszczeń „97 rzeczy które każdy programista powinien wiedzieć” jest już gotowa.


33. Liczby zmiennoprzecinkowe nie są liczbami rzeczywistymi.

Liczby zmiennoprzecinkowe to tylko przybliżone wartości liczb rzeczywistych. Musisz o tym pamiętam tworząc aplikacje operujące na takich wartościach (np. aplikacje finansowe) – aby zapewnić dobre wyniki warto używać zewnętrznych bibliotek.

34. Jeśli w Twojej obecnej pracy nie tworzysz aplikacji marzeń to zacznij rozwijać projekt open source – pozwoli to zrealizować Twoje programistyczne ambicje.
35. Złota zasada projektowania API: unit testy API mogą być niewystarczające, potrzebne są również testy kodu, który korzysta z tego API.
36. Nie budujmy mitu guru wokół osób bardziej doświadczonych

Mamy tendencję aby tworzyć mit „guru” dla osób doświadczonych jakoby posiadali umiejętność odpowiedzi na każde pytanie i mogli pomóc w każdym temacie. Doświadczeni programiści to nie magicy, tylko tacy sami ludzie jak my myślący w taki sam sposób jak my, posiadają tylko odrobinę więcej ciekawości i większej wiedzy.

Należy znieść takie sztuczne bariery. Nie budujmy mitu „guru”, a ekspertów, którzy chętnie dzielą się swoją widzą i doświadczeniami, aby rozwijać kolejnych ekspertów.

37. Dłuższy czas spędzony w pracy i większy nakład energii nie musi sprawić, że będziesz lepszy.

Staraj się rozwijać i poznawać eco-system w którym pracujesz, a nie rozwiązuj tylko jak najszybciej zadań. Zamiast pracować w nadgodzinach przeczytaj książki, magazyny, poznawaj nowe narzędzia, wybierz się na konferencje branżowe.

38. Raport błędu powinien zawierać informacje jak go odtworzyć, jaki powinien być rezultat, a co się dzieje aktualnie.
39. Pisz kod aby dodawał wartość, a nie dlatego, że Cię to bawi.

Jeśli coś nie jest teraz potrzebne, to teraz tego nie twórz (YAGNI). Programiści nie są od tworzenia wymagań – nie dodawaj ekstra rzeczy bez uzgodnienia tego z klientem.

40. Zadbaj o to aby pierwsze kroki, które musi wykonać użytkownik w Twojej aplikacji były proste i intuicyjne, dobrze opisane i jasne.
41. Jeśli w Twojej aplikacji spada szybkość działania to najpierw sprawdź czas komunikacji między procesami zanim zaczniesz optymalizować Twoje algorytmy.

Rozwiązaniami może być lazy loading, optymalizacja interfejsów pomiędzy procesami, wielowątkowość, stosowanie cache.

42. Staraj się aby Twój proces budowania aplikacji był czysty.

Jeśli pojawia się warning podczas budowania od razu staraj się go poprawić i usunąć. Ignorowanie ich sprawi, że po czasie będzie ich coraz więcej i może dojść do sytuacji, że pominiesz bardzo ważną informację.

43. Poznanie opcji linii poleceń może być dla Ciebie bardzo pomocne.

Dzięki zrozumieniu linii poleceń poznasz co Twoje IDE wykonuje „pod spodem” i nie będzie to dla Ciebie żadna „czarna magia”. Po czasie będziesz gotowy do pisania własnych skryptów, które pozwolą Ci na automatyzację.

44. Dobry programista powinien być ciekawy nowych języków programowania w różnych paradygmatach.

Spróbuj nauczyć się języków z różnych paradygmatów (programowanie obiektowe, funkcyjne, proceduralne). Dla przykładu przejście z Fortrana do C nie jest dużym wyzwaniem, jednak z C++ na Haskell to już jest wyczyn.

45. Poświęć trochę czasu aby lepiej poznać swoje IDE. Poznaj skróty klawiszowe i inne możliwości. Twoja praca po czasie stanie się jeszcze bardziej wydajna.
46. Zasoby są ograniczone, powinieneś znać złożoność Twoich algorytmów aby stworzyć optymalny system.
47. Dekomponuj zadania na mniejsze.

Z dużych tasków staraj się tworzyć zadania, które wykonasz w ciągu dwóch godzin. Pozwoli Ci to szybko reagować jeśli nie dajesz rady czegoś wykonać to możesz porzucić tę drogę i zacząć od nowa ten etap od zdefiniowania tego zadania od nowa. Nie commituj do repozytorium domysłów.

48. Używanie RDBMS pozwala na optymalizację zapytań i koncentrowaniu się na logice aplikacji zamiast na optymalizacji algorytmów.
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Ę