Analiza typowych błędów popełnianych przez początkujących programistów, cz. 2

Witam ponownie wszystkich! W dalszym ciągu będziemy rozważać problemy, z jakimi może spotkać się młody i niedojrzały programista w swojej pierwszej pracy. Pierwszą część można znaleźć tutaj . Kontynuujmy.

13. Nieprzestrzeganie wytycznych dotyczących stylu kodowania.

Zespoły programistyczne zazwyczaj trzymają się jednego stylu kodowania. Oznacza to, że poszczególni programiści przestrzegają pewnych pisanych i niepisanych zasad, aby mieć pewność, że ich styl kodowania nie różni się od innych. Nie próbuj wyróżniać się charakterystycznym stylem kodowania: to nie sprawi, że będziesz dobrze wyglądać. Jeśli jesteś nowy w projekcie, powinieneś od razu dowiedzieć się, czy istnieje jakakolwiek dokumentacja określająca ogólne wytyczne dotyczące stylu kodowania. Mogą istnieć pewne pliki stylów dla Twojego konkretnego projektu, o które musisz poprosić i zaimportować je do swojego IDE (na przykład IntelliJ IDEA), aby IDE mogło zapewnić prawidłowe wskazówki dotyczące stylu kodowania. Na przykład styl może wymagać użycia końcowego modyfikatora, jeśli to możliwe. Plik stylu pozwala IntelliJ IDEA podświetlać na żółto wszelkie zmienne, w których nie jest to przestrzegane.

14. Zniechęcanie się błędami

Błędy to coś, do czego trzeba się przyzwyczaić. Byli, są i będą. Nie ma znaczenia, czy jesteś początkującym, czy poważnym architektem, zawsze będziesz popełniać błędy. Liczba i dotkliwość Twoich błędów może się zmieniać, ale będą Ci one towarzyszyć przez całą Twoją karierę. Czasami przez cały tydzień nie możesz znaleźć czegoś, co zadziała, popełniasz błąd, a potem jest piątkowy wieczór i przemykasz do domu jak zbity pies, nie mogąc naprawić tego cholernego błędu. To uczucie nie do opisania, ale nie coś, co powinno Cię zniechęcić. W końcu kolejną ważną różnicą między doświadczonym programistą a nowicjuszem jest to, jak radzi sobie on z błędami. Doświadczeni programiści nie biorą ich sobie do serca, zamiast tego traktują je jako doświadczenie. Nikt nie będzie Cię ganił za popełnienie błędu. To normalne – każdemu czasem zdarza się wpaść w kłopoty. Ponownie możesz poprosić kolegów o pomoc. I nie zapomnij o ludziach takich jak kierownicy projektów (PM). Jeśli utkniesz na czymś, powinieneś natychmiast skontaktować się z PM. On lub ona może pomóc Ci znaleźć kogoś, kto jest ekspertem w problematycznej dziedzinie. W każdym razie kierownik projektu musi być na bieżąco informowany o wszelkich problemach, jakie napotkasz w projekcie. Zadaniem PM jest pomaganie w rozwiązywaniu wszelkiego rodzaju problemów, w tym w komunikacji i interakcjach pomiędzy członkami zespołu. Podsumowując: Błędy się zdarzają , nie pozwól, żeby cię zabiły. Zamiast tego zaakceptuj je jako wyzwanie dla Ciebie i Twoich umiejętności. W końcu to tylko część pracy.

15. Niewdrożenie bezpieczeństwa wątków.

Nic dobrego nie powstaje łatwo. Każdy programista musi zrozumieć, że napisanie określonej funkcjonalności, niezależnie od tego, czy będzie to moduł, czy tylko metoda, wymaga planu dotyczącego tego, co i jak zostanie wykonane. Z reguły opracowując funkcjonalność o dowolnej złożoności, należy przestrzegać następującej procedury: Wiele błędów pojawiających się w kodzie pisanym przez początkujących programistów ma związek z etapami tej procedury. Oczywiście nie można wykluczyć, że są momenty, w których trzeba szybko i bez wahania napisać kod, gdy tylko zobaczysz zadanie. Ale generalnie działa to tylko w przypadku niektórych mniejszych zadań i metod, których wdrożenie jest oczywiste i nie wymaga większego myślenia. Wspomniana powyżej procedura programistyczna jest bardziej odpowiednia w przypadku złożonych i dużych zadań, które można podzielić na podzadania. Nie jest dobrym pomysłem rozpoczynanie pisania kodu bez jasnego zrozumienia, co chcesz napisać. Najpierw musisz wszystko dokładnie przemyśleć i zaplanować. Pomocne może być również chwycenie kartki papieru i ołówka i próba naszkicowania pomysłów na wdrożenie. Zawsze tak robię planując rozbudowaną funkcjonalność. Programista spędza większość swojego czasu nie na pisaniu kodu, ale raczej na myśleniu o tym, jak ustrukturyzować wymaganą funkcjonalność . Rzeczywiście, kiedy już wszystko zaplanujesz i przemyślisz, pisanie kodu staje się bezproblemowym, czysto mechanicznym procesem.

16. Przepracowanie

z filmu "Klub walki" (1999) Być może każdemu początkującemu wydaje się, że pracując do późna w nocy, zacznie wykonywać więcej zadań i powierzone mu zostaną większe obowiązki. Też tak kiedyś myślałem, ale już nie. Zauważyłem, że przychodzi taki moment, kiedy osiągasz swój limit i przestajesz być w stanie odpowiednio myśleć. Zaczynasz być dość nudny i doświadczasz mentalnej mgły. Zrobienie rzeczy, które mógłbyś zrobić w 10 minut, gdyby twój umysł był świeży, zajmuje godzinę. Niemal bez wyjątku po przekroczeniu tej granicy zmęczenia pojawia się problem, który wydaje się nie do pokonania. Ale kiedy następnego ranka przychodzisz do pracy, rozwiązujesz problem w mgnieniu oka. Kiedy więc poczujesz, że osiągnąłeś ten punkt, nie siedź do późna. Po prostu idź do domu i dobrze odpocznij. Przecież jeśli będziesz siedział przy biurku do późnej nocy, nie tylko nie osiągniesz szczególnie wybitnych wyników w tych godzinach udręki, ale jednocześnie ryzykujesz kiepskim (niewystarczającym) odpoczynkiem przed kolejnym dniem pracy, kiedy będziesz schrzanię jeszcze raz. Pomyśl o swoim zdrowiu: czy warto je tak podważać na początku kariery? Myślę, że nie. Chorowanie to kosztowny czas. I pomyśl o swoim pracodawcy. Przepracowując się, pogarszasz sytuację nie tylko siebie, ale także swojego pracodawcy. Po co pracownik, który jest wiecznie śpiący, który ze zmęczenia nie jest w stanie wdrożyć najprostszego algorytmu sortowania? Tak, niewątpliwie są chwile, kiedy masz napięty termin, chwile, kiedy wszystko poszło nie tak, i chwile, kiedy – i to jest mój osobisty faworyt – „potrzebujemy tego na wczoraj”. Ale takie sytuacje są na ogół rzadkie, a kiedy już sobie z nimi poradzisz, musisz usiąść i dokładnie rozważyć, jak w ogóle mogły się wydarzyć i jak ich uniknąć w przyszłości.

17. Zaniedbywanie znajomości języka angielskiego

Wielu aspirujących programistów priorytetowo traktuje technologię uczenia się i odkłada naukę języka angielskiego. To poważny błąd, gdyż często programista idealnie nadaje się na stanowisko juniora (lub staż), ale nie dostaje tej pracy ze względu na słabą znajomość języka angielskiego. Tak, oczywiście, zdarzają się przypadki, gdy można obejść się bez języka angielskiego. Z reguły takie osoby są zatrudniane lokalnie do projektów w krajach nieanglojęzycznych. Jednak lokalne firmy nie płacą takich samych wynagrodzeń jak firmy zagraniczne. I bardzo, bardzo trudno będzie uzyskać przyzwoitą pensję, nawet z czasem. Dlatego nie należy ignorować języka angielskiego. Zamiast odkładać angielski na później, musisz się go nauczyć, aby od razu skupić się na projektach anglojęzycznych. Rzeczywiście, pomyśl o tym przez chwilę – angielski jest obecnie językiem międzynarodowego biznesu. Niezależnie od tego, do jakiego kraju się udasz, jeśli znasz angielski, możesz znaleźć wspólny język z innymi. To samo dotyczy projektów deweloperskich. Nie ma znaczenia, gdzie znajduje się projekt: Niemcy, Australia, Francja czy gdziekolwiek indziej – cała komunikacja, wszystkie zadania, dokumentacja itp. będą prowadzone w języku angielskim. A jeśli pomyślisz o tym przez chwilę, zgodzisz się, że jest to bardzo wygodne, prawda?

18. Pogoń za modną technologią

Deweloperzy rozpoczynający swoją drogę często starają się nadążać za najnowszymi technologiami. Czy to właściwe postępowanie? Z jednej strony tak: najnowsze technologie, projekty… Ale czy warto stawiać to na pierwszym miejscu? Może lepiej sięgnąć po „klasyczny zestaw narzędzi” dla specjalisty w swojej dziedzinie? Nowe jest z pewnością dobre, ale nie możesz zapominać o podstawowych technologiach w Twojej branży. I dopiero wtedy, gdy zdobędziesz trochę doświadczenia i głęboką wiedzę o podstawach, będziesz mógł spróbować czegoś nowego. Weź także pod uwagę, że nowe technologie mogą być lepsze pod pewnymi subtelnymi względami, ale mogą stracić przewagę w innych. Dopóki początkujący programista nie zrozumie tych kompromisów, lepiej trzymać się sprawdzonych rozwiązań. Na przykład, jeśli programista tworzy aplikację, która wchodzi w interakcję z niektórymi danymi, nie spiesz się z użyciem najnowszego rozwiązania NoSQL tylko dlatego, że jest na to modne. Zwykła, wypróbowana baza danych SQL (MySQL, PostrgreSQL itp.) najprawdopodobniej ma szczegółową dokumentację i rozwiązania na StackOverFlow dla wszelkich potencjalnych problemów :)

19. Nauka kilku różnych technologii i/lub języków jednocześnie

Mówiliśmy powyżej o początkujących, próbujących nauczyć się modnych technologii. A co powiesz na jednoczesne studiowanie wielu technologii lub języków? Oczywiście słyszałeś o programistach, którzy znają więcej niż jeden język programowania i opanowali wiele technologii. Ale szybko zwrócę uwagę, że ci ludzie nie są nowicjuszami w programowaniu. To ludzie, którzy mają za sobą wieloletnie doświadczenie. Opanowali swoją oryginalną technologię, a następnie poszli dalej i dalej. Początkujący, chcący opanować wszystko na raz, powinni pamiętać doskonałe przysłowie: „goń dwie zające, a nie złapiesz żadnej”. Konsekwencją może być to, że nie opanujesz dobrze żadnego tematu, a jedynie powierzchownie nauczysz się przedmiotów. Większe zapotrzebowanie będzie na specjalistę znającego dogłębnie jeden język, niż na takiego, który o wszystkim wie po trochu. Jeśli więc chcesz poznać wiele języków i technologii, musisz podejść do nich mądrze. Na początek musisz wybrać podstawowy, rdzeń języka, którego musisz się dogłębnie nauczyć. I dopiero wtedy powinieneś zacząć studiować inne obszary. Na przykład zostań guru Java, a następnie naucz się Pythona jako drugiego języka. Potem możesz dowiedzieć się czegoś na temat reakcji/angulara dla frontendu. W tym przypadku mówimy o technologiach, które nie są wymienne, takie jak C# i Java, ale raczej uzupełniają się, poszerzając możliwości kariery. Ale jeszcze raz powtarzam: nie należy uczyć się wszystkiego na raz. Trzeba iść po kolei. Złap jednego zająca na raz, że tak powiem.

20. Nieprawidłowo sformułowane cele

Jak wyznaczasz sobie cele? Zostać fajnym programistą? Pamiętaj o tym raz na zawsze: musisz wyznaczyć konkretne cele, czyli innymi słowy – cele osiągalne. O czym ja mówię? Przykładowo wyznaczasz sobie cel: „Chcę się wzbogacić”. Ale skąd możesz wiedzieć, czy osiągnąłeś ten cel? Albo jak zmierzyć, jak blisko jesteś osiągnięcia tego celu? Cóż, jeśli postawisz sobie za cel „Chcę zarobić milion dolarów”, będzie to trochę jaśniejsze, prawda? Gdy zarobisz 10 000 dolarów, jesteś o 10 000 dolarów bliżej celu — pozostało tylko 990 000 dolarów. Pozostało jeszcze wiele do osiągnięcia, ale czujesz postęp i wiesz, gdzie jest meta, dzięki czemu będziesz zmotywowany do dalszego działania. Jeśli chodzi o karierę, co powiesz na wyznaczenie sobie bardziej namacalnego celu? Na przykład: Chcę zostać liderem zespołu. Lub starszy programista. Albo ostatecznie architektem. Cóż, każde duże zadanie należy podzielić na mniejsze podzadania. Nie zostajesz liderem zespołu na początku swojej kariery. Jeśli to możliwe i właściwe, wyznaczaj terminy i skup się na bieżącym etapie.

1. Jeśli mówimy o zostaniu starszym programistą , pierwszym małym celem byłoby znalezienie stażu lub pracy jako młodszy programista w firmie.
2. Następnie możesz wyznaczyć cele pogłębiania wiedzy na temat określonych technologii. Jeśli chodzi o Javę, możesz przygotować się do certyfikacji Oracle na poziomie 1. Ustalamy ramy czasowe na nasze przygotowania i realizujemy cel.
3. Następnie możesz na przykład wyznaczyć sobie cel, aby poprawić swój angielski o jeden poziom (powiedzmy z B1 do B2). Ustalamy plan nauki, ustalamy czas i zmierzamy do celu.

W ten sposób krok po kroku (zdobywając jednocześnie doświadczenie w tworzeniu oprogramowania) możemy osiągnąć swój ostateczny cel.

21. Teoria bez praktyki

Niepodważalnym faktem jest to, że studiując nowe technologie i zagłębiając się w tematy, które już znamy, stajemy się lepszymi profesjonalistami. Ale na początku tej podróży programiści rzadko zdają sobie sprawę, że pożeranie książek technicznych jedna po drugiej nie przynosi ogromnych korzyści, jeśli nowa wiedza nie zostanie wypróbowana w praktyce. Osobiście spotkałem się z tym nie raz. Jeśli poświęcasz książce dużo czasu, ale nic z niej nie ćwiczysz, prawie cała nowo nabyta wiedza zostaje zapomniana: pozostaje Ci jedynie ogólne, mgliste wspomnienie, jak wszystko działa. Rezultatem jest mnóstwo zmarnowanego czasu bez wymiernych rezultatów. Dlaczego powinniśmy marnować czas? Życie nie trwa wiecznie. Wniosek jest taki, że ucząc się nowej technologii, nie powinieneś skupiać się na teorii: zapisuj podane przykłady równolegle z lekturą, eksperymentuj z nową technologią. To jedyny sposób, aby zmusić mózg do zapamiętania informacji. Tak, nowe materiały będziesz konsumował wolniej, ale za to przyswoisz znacznie więcej z tego, co przeczytasz. Co więcej, jeśli dobrze opanujesz jedną technologię, to następna będzie jeszcze łatwiejsza do opanowania (podobnie jak przy nauce języków).

22. Nadmierny perfekcjonizm

Większość programistów to perfekcjoniści: ludzie, którzy dążą do perfekcji. Oznacza to, że ich kod również musi być doskonały. Twój kod został napisany, przetestowany, dostrojony i wygląda na to, że nadszedł czas, aby przesłać go do głównej gałęzi. Ale nadal nie jesteś zadowolony z kodu, więc zaczynasz go przekręcać w tę i tamtą stronę, poświęcając na to dużo czasu. I w tym przypadku czas to pieniądz Twojego klienta. Początkujący programiści są bardziej podatni na to dążenie do perfekcji. Doświadczeni programiści są przyzwyczajeni do poczucia, że ​​kod nigdy nie będzie idealny i powinni starać się pisać go lepiej. Ale jednocześnie nie popadają w skrajności w dążeniu do zbliżenia się do „ideału”. Pamiętaj więc, aby nauczyć się, jak osiągnąć złoty środek: nie w sposób niechlujny i nie próbując odtworzyć Mony Lisy w kodzie.

23. Brak myślenia o architekturze

Powiem to jeszcze raz: nie powinieneś pisać niechlujnego kodu. Oprócz czytelności i wydajności musisz także pomyśleć o tym, jak Twój kod może wpłynąć na resztę aplikacji jako całości. Na przykład, jak trudne będzie rozszerzenie kodu i tak dalej. Problem w tym, że początkujący programiści, ze względu na brak doświadczenia, mogą nie od razu zdać sobie sprawę, jak ich nowa funkcjonalność wpłynie na aplikację w przyszłości. Rozwój takiego przewidywania z pewnością wymaga dużo praktyki. Ale co w takim razie mają zrobić nowicjusze? Nie pisać kodu? W takich sytuacjach z pomocą przychodzą nam różne paradygmaty programowania. Na przykład zasady SOLID lub różne wzorce projektowe, które mogą przekazać Ci przydatne praktyki. Do tych paradygmatów również należy podchodzić ostrożnie i nie posuwać się za daleko. Ale jak określić moment, w którym przesadzasz? W tym miejscu pomoże Ci przegląd kodu przez bardziej doświadczonego kolegę. Wnosząc świeże i obiektywne spojrzenie, Twój współpracownik może wskazać Ci właściwy kierunek.

24. Syndrom oszusta

Syndrom oszusta to zjawisko psychologiczne, w którym dana osoba nie jest w stanie przypisać swoich osiągnięć osobistym cechom, zdolnościom i wysiłkom. Pomimo zewnętrznych dowodów potwierdzających ich konsekwentne działanie, osoby podatne na ten syndrom nadal wierzą, że są oszustami i nie zasługują na osiągnięty sukces. Wielu programistów ma ten syndrom. Być może daje nam to wytrwałość, która pcha nas ku nowej wiedzy i technologiom. Patrzysz na bardziej doświadczonych i utalentowanych kolegów i czujesz się nieswojo, jakbyś nie był wart swojej pensji. Uwierz mi, to nieprawda. Są i zawsze będą programiści lepsi lub gorsi od Ciebie. Ktoś inny patrzy na ciebie i czuje się nieswojo, myśląc, że nigdy nie będzie taki jak ty. I to jest normalne. Informacje zwrotne od Twojego zespołu, recenzje kodu i dyskusje pomagają trochę zwalczyć to uczucie. Uwierz mi, opinia osoby z zewnątrz mile Cię zaskoczy, ale tylko pod warunkiem, że naprawdę nie zaniedbujesz swojej pracy i rozwoju zawodowego. Jeżeli zaniedbujesz te rzeczy, to wybrałeś zły zawód. W tym zawodzie trzeba ciągle uczyć się czegoś nowego i dążyć do tego, co najlepsze. Myślę jednak, że ludzie, którzy się tu gromadzą, wcale nie są leniwi. Zamiast tego, ludzie tutaj wytrwale zmierzają do swojego ukochanego celu. Jeśli to Cię opisuje, nie masz się czego obawiać.

25. Rzadko popełniam zobowiązania

Pamiętaj o częstym wykonywaniu zatwierdzeń! Nie co pół godziny, pamiętaj. Jeśli spędzasz tydzień na wdrażaniu jakiejś funkcjonalności, nie powinieneś wykonywać jednego zatwierdzenia w piątkowy wieczór, ale, powiedzmy, pięć zatwierdzeń. Prawie każde duże zadanie można dla wygody podzielić na mniejsze zadania. Wykonujesz więc te mniejsze zadania i zatwierdzasz. I nie zapomnij od razu wysłać tych zatwierdzeń na zdalny serwer. W przeciwnym razie możesz dokonywać zmian przez cały tydzień, a w piątek w porze lunchu w Twoim komputerze wystąpi awaria sprzętowa i wtedy stracisz cały tydzień na darmo! Ale jeśli przesłałeś swoje zatwierdzenia na zdalny serwer, po prostu przeciągnąłbyś gałąź z ostatnim zatwierdzeniem na inny komputer i kontynuowałbyś pracę. Jeszcze jedno: nie przesyłaj nowej funkcjonalności na serwer produkcyjny na żywo w piątkowy wieczór. Po prostu mi zaufaj. Nie potrzebujesz tego. Jest wysoce prawdopodobne, że wyjdą na jaw nieoczekiwane błędy, a Ty spędzisz weekend na ich naprawianiu. I to nie jest zabawne. W weekend musisz odpocząć. To chyba wszystko na dzisiaj. PS Ostatnia wskazówka: pisz dużo kodu. PPS Napisz NIESAMOWICIE dużą ilość kodu, ponieważ tylko w ten sposób możesz zdobyć tak potrzebne doświadczenie.