Najczęstsze błędy młodszych programistów i jak sobie z nimi radzić

Większość młodych programistów powtarza te same błędy, które negatywnie wpływają na wizerunek danej osoby oraz wyniki pracy całego zespołu. Wynikają one zapewne z braku doświadczenia jak również z chęci wykazania się osoby, która rozpoczęła pracę w projekcie. W tym artykule przedstawiam moją subiektywną listę błędów, które popełniają w pracy młodzi programiści oraz postaram się przedstawić sposoby radzenia sobie z takimi problemami. Ja również zaliczyłem podobne potknięcia. Zapraszam do lektury.

Najczęstsze błędy młodszych programistów i jak sobie z nimi radzić

1. Błąd: Przywiązywanie się do własnego kodu.
   • Rozwiązanie: Nie przywiązujemy się do kodu, ale bierzemy za niego odpowiedzialność.
2. Błąd: Nie napisanie nawet linijki kodu.
   • Rozwiązanie: Robimy to, co możemy, to więcej niż nic nie zrobione.
3. Błąd: Popadanie w nieskończoną pętlę problemu.
   • Rozwiązanie: Nie boksujemy się z problemem, szukamy pomocy i/lub przełączamy się na inne zadanie.
4. Błąd: Nadmierne używanie framework’ów.
   • Rozwiązanie: Czysty kod, Spring nie jest remedium na wszystko.

1. Przywiązywanie się do własnego kodu

Chyba największym problemem młodych programistów jest przywiązywanie się do napisanego przez siebie kodu. Należy pamiętać, że jedyną stałą rzeczą w kodzie jest jego ciągła zmiana. Nad kodem aplikacji pracuje cały zespół, niejednokrotnie rozproszony, międzynarodowy zespół. Do zarządzania zmianami w kodzie wykorzystuje się rozproszony system kontroli wersji taki jak git.

Zmiana, którą wprowadziliśmy w kodzie wieczorem przed wyjściem z pracy rano może zostać nadpisana przez osobę z zespołu, która pracuje w innej strefie czasowej. To samo może być w dowolnym momencie pracy nad kodem. Korzystając z git’a nie ma mowy, żeby nie przyznać się do swojej zmiany, git śledzi każdą edycję w kodzie oraz zapisuje informacje o autorze, który dokonał tej zmiany – nazywa się to git blame.

Dla wspólnego dobra projektu, zamiast wypierać się kodu, bo działa niepoprawnie lub zbytnio przywiązywać się do niego, bo jest idealnym rozwiązaniem,, poddajmy nasz kod zmianie. Należy pamiętać, że kod, który nie jest odporny na zmianę, staje się trudny w utrzymaniu (poprawianiu błędów) i/lub w rozwoju (dodawanie nowych funkcjonalności). Pamiętajmy, nie przywiązujemy się do naszego kodu, ale bierzemy za niego odpowiedzialność!

Wiem, jak samemu było mi ciężko modyfikować kod, który kosztował mnie tak wiele pracy i czasu, żeby go stworzyć. Na początku mojej pracy jako programista Java miałem za zadanie odwzorować model bazy danych w kodzie Java. Stworzyłem wiele klas i relacji między nimi, zajęło mi to sporo czasu. Później dowiedziałem się, że model bazy danych nie jest najlepszy i należy go zmienić( mój kod również), więc przepisałem wszystko od nowa. Innym przykładem może być kod, który realizował funkcjonalność Anti-Money Laundering (AML) w systemie bankowym. Po napisaniu kodu zmieniły się przepisy i regulacje, oczywiście kod musiał się zmienić.

Zobacz też

Poradnik 3 usprawnienia organizacji kodu

2. Nie napisanie nawet linijki kodu

Młodszy programista może nie zdawać sobie sprawy z tego, że jego nawet niewielki udział w kodzie jest bardzo pomocny dla całego zespołu, a nie napisanie nawet najmniejszego fragmentu kodu może generować opóźnienia w projekcie. Zadanie polegające na np. zapisaniu danych z zewnętrznego serwisu pogodowego, na początku może wydawać się bardzo trudne.

Dlatego zadanie rozbijamy na mniejsze elementy np. stworzenie klas zawierających dane pogodowe, łączenie się z zewnętrznym API za pomocą protokołu HTTP, utrwalenie danych w bazie danych. Nadal zadanie może wydawać się skomplikowane, ale młodszy programista widzi, że może stworzyć klasy, które przechowują dane pogodowe tzw. klasy POJO oraz dodatkowo serwis CRUD służący do zapisywania tych danych.

Jeśli junior wykona te dwa mniejsze zadania, to bardziej doświadczony programista z zespołu będzie miał już gotową bazę do dalszego rozwoju – nie będzie musiał wykonywać żmudnej pracy, a od razu zabrać się za implementację. Nawet tak niewielka pomoc jest bardzo przydatna w projekcie! Robimy to, co możemy, to więcej niż nic.

Taką pozornie niewielką pomocą w mojej pracy jako programista Java okazało się napisanie kodu pobierającego dane od użytkownika. Stworzyłem formularze html bez użycia żadnego framework’a, proste <form> oraz <input>, następnie napisałem klasy Java, które odpowiadały polom z formularzy html.

Niby proste zadanie, ale formularzy było kilka, przez co zajęło mi to kilka dni. Nie mniej jednak przyspieszyło to pracę doświadczonego programisty. Taką „niewielką pomoc” porównuję często do pracy przy budowie domu – to mało doświadczony pomocnik (młodszy programista) znosi materiały (klasy Java) na plac budowy, a następnie fachowiec (starszy programista) pod okiem kierownika zakłada instalację elektryczną i/lub wodną (implementuje algorytmy, logikę aplikacji).

3. Popadanie w nieskończoną pętlę problemu

Na początku swojej „kariery zawodowej” młodszy programista, często wpada w jak ja, to nazywam nieskończoną pętlę, w której próbuje wykonać powierzone mu zadanie lub rozwiązać napotkany problem. Jeśli programista poświęcił dużo czasu na próbę implementacji zadania lub rozwiązania problemu, to musi jak najszybciej opuścić nieskończoną pętlę, w której się znalazł.

W języku Java w kodzie należałoby użyć instrukcji break, która przerwała by nieskończoną pętlę. W realnym świecie można, to zrobić na kilka sposobów, np.: poprosić o pomoc bardziej doświadczonego kolegi z zespołu i/lub przełączyć się na inne zadanie, które pozwoli nam z dystansem spojrzeć na nasz problem. Należy pamiętać, że nie boksujemy się z problemem – szukamy pomocy i/lub przełączamy się na inne zadanie.

Łatwo powiedzieć, żeby opuścić pętlę nieskończoną, jednak znacznie trudniej to wykonać. Dobrze pamiętam jak samemu wpadałem w takie zapętlenia, które niestety generowały niepotrzebne opóźnienia i zgrzyty w projekcie. Na początku mojej pracy jako programista Java, nie mając doświadczenia, a chcąc się wykazać, zabrałem się za zadanie pobrania i zapisania zgód marketingowych użytkownika w serwisie internetowym.

Bez wnikania w szczegóły techniczne, walczyłem ze stroną www, która była podzielona na sekcje <div>, których nie dało się objąć jednym formularzem html <form>, co uniemożliwiało przesłanie kompletnych danych do serwera i zapisania ich w bazie danych. Spędziłem nad tym tydzień czasu, co chwile świętując sukces, a następnie zaliczając porażkę.

Będąc o krok od sukcesu zapomniałem o paśmie nieudanych prób rozwiązania problemu, to była moja nieskończona pętla, którą za późno przerwałem. Poprosiłem o pomoc bardziej doświadczonego programistę, który spokojnie powiedział, że tak się nie da, że muszę i mogę zmienić istniejący kod. Tak, to takie proste, ale z perspektywy czasu.

Oferty pracy z

4. Nadmierne używanie framework’ów

Zauważyłem, że większość młodszych programistów Java, traktuje Spring Framework jak remedium dla wszelkich zadań do wykonania oraz problemów do rozwiązania. Owszem, Spring jako framework jest bardzo przydatny, obecnie bez niego trudno sobie wyobrazić tworzenie projektów. Nie zwalnia on jednak programistów z myślenia nad tworzonym kodem.

Nadal obowiązują dobre praktyki wytwarzania oprogramowania takie, jak SOLID, DRY czy KISS. Wciąż należy pamiętać o paradygmatach programowania obiektowego: dziedziczenie, polimorfizm oraz enkapsulacja. Należy wiedzieć jakie struktury danych użyć, aby tworzony kod był wydajny. Tak, można stworzyć projekt bez użycia Spring Framework, a następnie nanieść adnotacje Spring’owe.

Pamiętam aplikację, którą studenci tworzyli pod moim okiem – zgodnie z zasadą Stop! Zanim zaczniesz pisać kod zastanów się, co chcesz kodować? Analiza, projekt i implementacja. Przez cztery tygodnie zrobiliśmy analizę oraz projekt. Kolejne cztery tygodnie poświęciliśmy na implementację rdzenia aplikacji: podział na warstwy i moduły, model danych, utrwalanie danych oraz REST API – wszystko bez Spring Framework.

Jak dziś dzień pamiętam rosnące z tygodnia na tydzień zdenerwowanie studentów, którzy codziennie dopytywali dlaczego jeszcze nie używamy Spring’a?! Przeprowadziłem dla studentów krótkie szkolenie ze Spring Framework. Później poprosiłem ich o dodanie do projektu zależności (Maven Dependencies) dla Spring Framework, a następnie o naniesienie adnotacji Spring’owych dla stworzonych wcześniej klas Java.

Nastała „cisza”, nikt więcej nie dopytywał o Spring Framework, Spring był, działał, ale sam „czysty kod Java” nadal działał w „niezmienionej postaci”. Przez ten opis nie umniejszam wartości jaką niesie ze sobą Spring Framework, chcę jedynie przekazać, że Spring Framework nie jest remedium na wszystko.

Zdjęcie główne pochodzi z unsplash.com