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

Witaj świecie! Kiedy już nauczysz się wszystkiego, co musisz wiedzieć i wreszcie zaczniesz pracować jako stażysta lub młodszy programista, prawdopodobnie możesz się zrelaksować, prawda? Nie. Wszystko dopiero się dla Ciebie zaczyna... Otacza Cię wiele rzeczy nowych i niezrozumiałych. Jak nie schrzanić tego od razu za bramą? Właśnie o tym dzisiaj porozmawiamy. W tym artykule chcę przeanalizować najczęstsze błędy popełniane przez nowicjuszy i udzielić kilku rad, opartych na własnym doświadczeniu, jak ich uniknąć. Zacznijmy więc bez zbędnych ceregieli:

1. Strach przed szukaniem pomocy u bardziej doświadczonych kolegów

Wszyscy jesteśmy ludźmi. Wszyscy boimy się wyjść na głupców, zwłaszcza w oczach naszych nowych, bardziej doświadczonych kolegów. Kiedy programiści podejmują pierwszą pracę, często kierują się tym strachem i z ciężkim sercem wycofują się w siebie, próbując wszystko rozgryźć na własną rękę. Dodatkowo można kogoś otoczyć bardziej doświadczonymi współpracownikami, którzy z kolei są w stanie wskazać mu najbardziej obiecujący kierunek, pomagając uniknąć kolejnych błędów i niepotrzebnych „uderzeń w głowę”. Więc pamiętaj: nie bój się zadawać pytań. Jesteś początkujący i wszyscy doskonale to rozumieją. Kiedy poprosisz, nikt nie będzie cię bił kijami. Być może stanie się nawet coś przeciwnego: szybciej zaprzyjaźnisz się ze swoimi współpracownikami i zaczniesz cieszyć się bardziej aktywną komunikacją z nimi. I' Powiem więcej: im więcej pytasz i omawiasz różne kwestie techniczne, tym szybciej będziesz w stanie zrzucić zieloną skórę nowicjusza i wyrosnąć na eksperta w swojej dziedzinie. I jeszcze jedna rada. Nie bądź obcyPrzepełnienie stosu . Mówię konkretnie o zadawaniu pytań dotyczących tego zasobu. Z jednej strony uzyskanie odpowiedzi na Twoje pytanie zajmuje trochę czasu. Ale z drugiej strony możesz szybko nauczyć się wielu podejść do rozwiązania swojego problemu i spojrzeć na niego z nieco innej perspektywy. Chcę również zauważyć, że istnieją praktyczne korzyści z pisania komentarzy/odpowiedzi i pisania pytań wyjaśniających na pytania StackOverflow od innych programistów: masz szansę na debatę i zagłębienie się w problemy, nie wspominając o wzmocnieniu karmy.

2. Niepróbowanie samodzielnego wyszukiwania informacji

Ten błąd można uznać za drugą stronę poprzedniego.Mam tu na myśli moment, w którym zaczynasz dręczyć swoich kolegów i znajomych każdym napotkanym problemem lub czkawką. Pytania są dobre, ale nie przesadzaj z pytaniami. W przeciwnym razie ludzie mogą po prostu uznać Cię za irytującego. Jeśli coś Cię zdezorientuje, pierwszą rzeczą do zrobienia jest ćwiczenie umiejętności wyszukiwania w najlepszej wyszukiwarce — Google. Ktoś inny spotkał się już z przytłaczającą większością niezrozumiałych błędów i innych problemów. Zdziwisz się, jeśli wpiszesz w Google swoje pytanie i zobaczysz liczbę osób, które znają podobny problem i które otrzymały już wyczerpujące odpowiedzi, które możesz zastosować we własnej pracy. Dlatego często słyszysz, jak twoi współpracownicy odpowiadają „Google it”. Przywdziewać' nie obrażaj się na tę odpowiedź — twój kolega nie jest twoim osobistym nauczycielem, który musi przekazać wszystkie subtelności twojej dziedziny pracy. Niekończące się przestrzenie Internetu będą twoim mentorem. Czasami programiści są również określani jakoosoby z czarnym pasem w wyszukiwarce Google . Więc jeśli mamy „czkawkę”, najpierw szukamy problemu w Google. Jeśli nie można znaleźć rozwiązania (jest to rzadkie, ale się zdarza), dopiero wtedy zaczynamy pytać kolegów. Natychmiastowe pytania służą raczej uzyskaniu porady na temat tego, które podejście należy wybrać, aby rozwiązać problem, niż tego, co zrobiłbyś, gdy uderzysz w próg zwalniający lub niezrozumiały komunikat o błędzie. W końcu mogą być w stanie spojrzeć poza preferowane podejście i natychmiast przewidzieć, dokąd dane podejście doprowadzi na dłuższą metę.

3. Ślepe kopiowanie i wklejanie

Ale googlowanie problemów i ich rozwiązań ma swoje pułapki. Na przykład ślepe kopiowanie i wklejanie plików .Zwykle dzieje się tak, gdy znajdziesz podobny problem (ale być może nie do końca ten sam) i powiązane rozwiązanie, na przykład na StackOverflow. Chwytasz to rozwiązanie i kopiujesz je i wklejasz bez dalszego zagłębiania się w szczegóły. A potem ty lub twoi współpracownicy odkrywacie dziwne błędy lub nieprawidłowe zachowanie w kodzie. I nikt nie może od razu odgadnąć, skąd pochodzą. W końcu oczywiście miejsce ze skopiowanym kodem zostanie znalezione i na pewno nie zostaniesz pochwalony za swoje rozwiązanie. Dlatego, gdy znajdziesz gotowe rozwiązanie na StackOverflow (lub gdziekolwiek indziej), musisz najpierw dokładnie zrozumieć, co, jak i dlaczego. Być może wyszukaj w Google odpowiednią funkcjonalność i przeczytaj jej dokumentację. I dopiero po wykonaniu tej czynności należy dodać go do swojego projektu.

4. Trzymanie się niewłaściwego rozwiązania

Pisząc rozwiązanie, czasami zauważysz, że staje się ono coraz bardziej skomplikowane, aż w końcu dochodzi do ślepego zaułka. A potem próbujesz uczynić rozwiązanie jeszcze bardziej rozbudowanym, aby jakoś sprawić, by działało, zamiast szukać innej, bardziej odpowiedniej alternatywy. Może czujesz, że zainwestowałeś dużo czasu i wysiłku i dlatego zdecydowałeś, że bez względu na wszystko nie poddasz się i rozwiążesz problem swoim dotychczasowym podejściem. To nie jest do końca właściwa postawa. Przynajmniej w programowaniu. Im szybciej wypróbujesz inne podejście, tym więcej czasu w końcu zaoszczędzisz. Więc nie bój się eksperymentować i wypróbuj inne podejścia, niezależnie od ilości czasu zainwestowanego w obecne. Co więcej, próbując wielu podejść i zagłębiając się w temat,

5. Strach przed zadawaniem pytań na temat aktualnego zadania

Praca nad projektem programistycznym zazwyczaj sprowadza się do wykonywania określonych zadań. Na przykład w Jirze. Zadania te nie zawsze są jasno i szczegółowo nakreślone. Opisy zadań są zwykle pisane przez liderów zespołów, którzy również są zwykłymi śmiertelnikami. Mogą zapomnieć coś dodać lub nie uwzględnić faktu, że nie znasz tej lub innej funkcjonalności. A może nie masz dostępu do projektu (na przykład dostępu do bazy danych, serwera dziennika itd.). A teraz otrzymałeś zadanie, studiowałeś je przez ponad kilka godzin, ale nadal tam siedzisz, wpatrując się w ekran w oszołomieniu. Zamiast bezskutecznie próbować to zrozumieć, powinieneś zacząć prosić o wyjaśnienie lub wskazówki osobę, która stworzyła zadanie. Na przykład w aplikacji używanej przez Twój zespół do komunikacji (na przykład Microsoft Teams) możesz zadawać pytania lub bezpośrednio komentować zadanie. Z jednej strony, jeśli napiszesz swoje pytanie w wiadomości prywatnej, prawdopodobnie szybciej uzyskasz odpowiedź, ponieważ dana osoba natychmiast zobaczy twoje pytanie. Z drugiej strony, zadając pytanie w Jira, ustalasz dowód na to, że coś robisz, czyli analizujesz problem. Jest sposób na przyspieszenie tego procesu: zadaj pytanie w komentarzu w Jirze, a następnie w DM, podrzuć link do swojego komentarza i poproś o obejrzenie.

6. Stawianie nierealistycznie wysokich wymagań wobec lidera zespołu

Ponownie, jest to odwrotna strona poprzedniego punktu. Lider zespołu jest szefem zespołu deweloperskiego. Z reguły lider Twojego zespołu spędza większość czasu na różnego rodzaju komunikacji. Jednak pisze też kod, aby nie zapomnieć wszystkiego o programowaniu. Jak możesz zrozumieć, życie lidera zespołu jest bardzo pracowite. Szarpanie lidera zespołu za rękaw za każdym razem, gdy musisz kichnąć, oczywiście nie będzie przyjemne. Wyobraź sobie, że każdy członek zespołu bombarduje lidera mnóstwem pytań. To może doprowadzić każdego do szaleństwa, prawda? A jeśli masz mnóstwo pytań, szef twojego zespołu będzie musiał poświęcić dużo czasu na udzielenie ci odpowiedzi. Co można zrobić, aby zmniejszyć liczbę pytań kierowanych do lidera zespołu:

• Zapoznaj się z dokumentacją projektu bardziej szczegółowo, aby zmniejszyć liczbę martwych punktów.
• Kieruj swoje pytania do pozostałych członków zespołu. Mogą być tak samo zaznajomieni z tą funkcjonalnością jak lead, a może nawet bardziej, ponieważ funkcjonalność została najprawdopodobniej napisana przez jednego z nich.

Alternatywnie możesz spojrzeć na adnotacje w IDE, kto i kiedy kod w określonej linii został ostatnio zmieniony. Właśnie w ten sposób możesz dowiedzieć się, kto jest najbardziej odpowiednią osobą do zadania pytania. Jak zapewne już wiesz, jeśli chodzi o pytania do lidera zespołu, podobnie jak w przypadku pytań do kolegów, musisz spróbować znaleźć złoty środek — nie bój się zadawać pytań, ale też nie zadawaj ich zbyt wiele z nich.

7. Strach przed recenzjami kodu

Przegląd koduto taki etap, który ma miejsce przed przesłaniem kodu do wspólnej aplikacji (do współdzielonej gałęzi, na przykład master lub dev). To sprawdzenie jest przeprowadzane przez programistę, który nie jest zaangażowany w zadanie, którego świeże spojrzenie może wykryć błędy, nieścisłości lub wady w twoim stylu kodu, które pozostały niezauważone podczas początkowego pisania kodu. Jeśli pojawiają się uwagi krytyczne, pozostawia się je jako komentarze do niektórych części kodu. W takim przypadku programista, który napisał kod, musi poprawić błędy zidentyfikowane w recenzji (lub omówić swoje decyzje z recenzentem, ewentualnie przekonując go, że są prawidłowe). Następnie kod jest wielokrotnie przesyłany do recenzji, dopóki recenzent nie będzie miał więcej komentarzy. Recenzent działa jako „brama” przed zatwierdzeniem kodu. Wyzwanie polega na tym, że wielu początkujących programistów postrzega przegląd kodu jako krytykę i potępienie. Nie doceniają recenzji kodu i boją się ich. Nie powinni. Recenzje kodu są dokładnie tym, co pozwala nam ulepszać nasz kod. Otrzymujemy przecież ważne informacje o tym, co robimy źle i na co warto zwrócić uwagę. Powinieneś rozważyć każdą recenzję kodu jako część krzywej uczenia się, coś, co może pomóc ci stać się lepszym. Gdy ktoś komentuje Twój kod, dzieli się z Tobą doświadczeniem i najlepszymi praktykami. Osobiście nie wierzę, że można zostać dobrym programistą bez recenzji kodu. Ponieważ nie jesteś nawet świadomy jakości swojego kodu i tego, czy doświadczony outsider wskaże błędy. nie doceniasz recenzji kodu i boisz się ich. Nie powinni. Recenzje kodu są dokładnie tym, co pozwala nam ulepszać nasz kod. Otrzymujemy przecież ważne informacje o tym, co robimy źle i na co warto zwrócić uwagę. Powinieneś rozważyć każdą recenzję kodu jako część krzywej uczenia się, coś, co może pomóc ci stać się lepszym. Gdy ktoś komentuje Twój kod, dzieli się z Tobą doświadczeniem i najlepszymi praktykami. Osobiście nie wierzę, że można zostać dobrym programistą bez recenzji kodu. Ponieważ nie jesteś nawet świadomy jakości swojego kodu i tego, czy doświadczony outsider wskaże błędy. nie doceniasz recenzji kodu i boisz się ich. Nie powinni. Recenzje kodu są dokładnie tym, co pozwala nam ulepszać nasz kod. Otrzymujemy przecież ważne informacje o tym, co robimy źle i na co warto zwrócić uwagę. Powinieneś rozważyć każdą recenzję kodu jako część krzywej uczenia się, coś, co może pomóc ci stać się lepszym. Gdy ktoś komentuje Twój kod, dzieli się z Tobą doświadczeniem i najlepszymi praktykami. Osobiście nie wierzę, że można zostać dobrym programistą bez recenzji kodu. Ponieważ nie jesteś nawet świadomy jakości swojego kodu i tego, czy doświadczony outsider wskaże błędy. robisz źle i na co warto zwrócić uwagę. Powinieneś rozważyć każdą recenzję kodu jako część krzywej uczenia się, coś, co może pomóc ci stać się lepszym. Gdy ktoś komentuje Twój kod, dzieli się z Tobą doświadczeniem i najlepszymi praktykami. Osobiście nie wierzę, że można zostać dobrym programistą bez recenzji kodu. Ponieważ nie jesteś nawet świadomy jakości swojego kodu i tego, czy doświadczony outsider wskaże błędy. robisz źle i na co warto zwrócić uwagę. Powinieneś rozważyć każdą recenzję kodu jako część krzywej uczenia się, coś, co może pomóc ci stać się lepszym. Gdy ktoś komentuje Twój kod, dzieli się z Tobą doświadczeniem i najlepszymi praktykami. Osobiście nie wierzę, że można zostać dobrym programistą bez recenzji kodu. Ponieważ nie jesteś nawet świadomy jakości swojego kodu i tego, czy doświadczony outsider wskaże błędy.

8. Skłonność do tajemnych decyzji

Różne zadania/problemy mogą często mieć kilka różnych rozwiązań. A spośród wszystkich dostępnych rozwiązań, początkujący zwykle korzystają z najbardziej złożonych i tajemniczych. I to ma sens: początkujący programiści dopiero wczoraj nauczyli się wielu różnych algorytmów, wzorców i struktur danych, więc ich ręce świerzbią, żeby zaimplementować niektóre z nich. Zaufaj mi, byłem taki, więc wiem, o czym mówię :) Miałem sytuację, w której przez długi czas wdrażałem pewną funkcjonalność. Okazało się to bardzo, bardzo skomplikowane. Następnie starszy programista przepisał mój kod. Oczywiście byłem bardzo zainteresowany tym, co i jak to zmienił. Przyjrzałem się jego implementacji i byłem zdumiony, o ile była prostsza. I było trzy razy mniej kodu. Co zaskakujące, automatyczne testy tej funkcjonalności nie zostały usunięte ani zmienione! Innymi słowy, ogólna logika pozostała taka sama. Z tego doszedłem do wniosku, żenajbardziej pomysłowe rozwiązania są zawsze proste . Po tej realizacji kodowanie stało się znacznie łatwiejsze, a jakość mojego kodu skoczyła na znacznie wyższy poziom. Kiedy więc warto zastosować wzorce projektowe i fantazyjne algorytmy, pytasz? Podczas ich stosowania będzie to najprostsze i najbardziej kompaktowe rozwiązanie.

9. Wymyślanie koła na nowo

Koło to trwałe rozwiązanie, które zostało wynalezione dawno temu. W tym antywzorcu programista implementuje własne autorskie rozwiązanie problemu, który został już rozwiązany. Czasami te istniejące rozwiązania są lepsze niż to, co wymyśli programista. Z reguły odkrywanie koła na nowo prowadzi do straconego czasu i zmniejszenia produktywności, ponieważ znalezione rozwiązanie może być dalekie od najlepszego lub, no cóż, możesz go w ogóle nie znaleźć. To powiedziawszy, nie możemy wykluczyć możliwości stworzenia własnego, niezależnego rozwiązania: gdybyśmy to zrobili, pozostałoby tylko programowanie typu kopiuj i wklej. Programista powinien być odpowiednio zorientowany w pojawiających się konkretnych zadaniach programistycznych, aby móc je kompetentnie i szybko rozwiązać, czy to korzystając z gotowych rozwiązań, czy też tworząc rozwiązania niestandardowe. Z jednej strony, na uniwersytetach i na kursach online jesteśmy bombardowani różnego rodzaju zadaniami, które wydają się mieć na celu pomóc nam wymyślić koła na nowo. Ale tylko na pierwszy rzut oka: prawdziwym celem jest rozwijanie myślenia algorytmicznego i głębsze opanowanie składni języka. Takie zadania pomagają również lepiej zrozumieć algorytmy i struktury danych oraz dają umiejętności implementacji bardziej wyrafinowanych odpowiedników, jeśli to konieczne (czasami jest to konieczne, ale zdarza się to niezwykle rzadko). W prawdziwym życiu w przytłaczającej większości przypadków nie musisz wymyślać własnego koła, ponieważ koła spełniające Twoje potrzeby istnieją już od dawna. Być może brak doświadczenia nie pozwala Ci wiedzieć o istnieniu implementacji potrzebnej Ci funkcjonalności. W tym miejscu należy skorzystać z porady podanej w pierwszym punkcie tego artykułu, a mianowicie: poproś bardziej doświadczonych kolegów o pomoc. Będą w stanie Cię poprowadzić (na przykład wskazać właściwy kierunek w wyszukiwarce Google) lub zasugerować konkretną implementację (na przykład jakąś bibliotekę).

10. Niepisanie testów

Wszyscy nowicjusze nie lubią pisać testów. Ale dlaczego mielibyśmy wyróżniać nowicjuszy tutaj? Bardziej doświadczeni programiści również nie lubią pisać testów, ale lepiej rozumieją, dlaczego testy są potrzebne. Kiedy jesteś całkowicie zielony, zastanawiasz się, dlaczego powinieneś je napisać. Wszystko działa, więc nie może być żadnych błędów. Ale jak upewnić się, że zmiany nie zepsują czegoś w innym miejscu systemu? Twoi współpracownicy nie docenią, jeśli będziesz forsować zmiany, które przyniosą więcej szkody niż pożytku. Tutaj z pomocą przychodzą nam testy. Im więcej testów obejmuje kod aplikacji, tym lepiej (nazywa się to pokryciem kodu lub pokryciem testów). Jeśli aplikacja ma dobre pokrycie testowe, możesz uruchomić wszystkie testy, aby znaleźć miejsca, które zostaną złamane przez Twój kod. I jak powiedziałem w powyższym przykładzie, kiedy starszy programista dokonał refaktoryzacji kodu, testy nie zakończyły się niepowodzeniem. Stało się tak, ponieważ ogólna logika się nie zmieniła. Używamy testów, aby wykazać, czy logika niektórych funkcjonalności uległa zmianie, czy nie. Więc nawet jeśli nie lubisz pisać testów, są one zdecydowanie przydatne i warte czasu spędzonego nad nimi.

11. Nadmierne komentarze

Wielu programistów cierpi na perfekcjonizm, a nowicjusze nie są wyjątkiem. Czasami przejawiają tylko jeden aspekt tej skłonności, kiedy zaczynają komentować wszystkich i wszystko. Nawet dodawanie niepotrzebnych komentarzy, ponieważ kod jest tak oczywisty:

Cat cat = new Cat(); // Cat object

Nie wszyscy początkujący programiści od razu zdają sobie sprawę, że komentowanie kodu nie zawsze jest dobre, ponieważ zbędne komentarze zaśmiecają kod i utrudniają jego czytanie. A co jeśli kod się zmieni, ale stare komentarze nie zostaną zaktualizowane? Wtedy będą nas tylko wprowadzać w błąd i dezorientować. Więc po co w ogóle taki komentarz? Zwykle dobrze napisanego kodu nie trzeba komentować , ponieważ wszystko w nim jest już oczywiste i czytelne. Jeśli musisz napisać komentarz, to już zepsułeś czytelność kodu i próbujesz jakoś zaradzić tej sytuacji. Najlepszym podejściem jest pisanie od początku czytelnego kodu, czyli takiego, który nie wymaga komentarzy. Nie mogę też nie wspomnieć o potrzebie przestrzegania poprawnych konwencji nazewnictwa metod, zmiennych i klas. Oto moja zasada: Najlepszym komentarzem jest brak komentarza lub poprawne nazewnictwo , które jasno opisuje funkcjonalność Twojej aplikacji.

12. Złe nazewnictwo

Nowicjusze bawią się szybko i luźno w nazywaniu klas, zmiennych, metod itp. Na przykład tworząc klasę, której nazwa w ogóle nie opisuje jej celu. Lub deklarują zmienną o krótkiej nazwie, na przykład x . Oni, gdy dwie kolejne zmienne nazwane n i ysą tworzone, pamiętanie, za co odpowiada x, staje się bardzo trudne. W obliczu takiej sytuacji trzeba dokładnie przemyśleć kod, przeanalizować go pod mikroskopem (być może za pomocą debuggera), przestudiować funkcjonalność, aby po prostu zrozumieć, co się dzieje. W tym miejscu z pomocą przychodzą nam prawidłowe konwencje nazewnictwa, o których wspomniałem powyżej. Poprawne nazwy poprawiają czytelność kodu, skracając tym samym czas potrzebny na zapoznanie się z kodem, ponieważ użycie metody jest znacznie łatwiejsze, gdy jej nazwa w przybliżeniu opisuje jej funkcjonalność. Wszystko w kodzie składa się z nazw (zmienne, metody, klasy, obiekty, pliki itp.), więc ten punkt staje się bardzo ważny podczas tworzenia poprawnego, czystego kodu. Należy pamiętać, że nazwa powinna przekazywać znaczenie, np. dlaczego zmienna istnieje, co robi, i jak się go używa. Nieraz zauważę, że najlepszym komentarzem do zmiennej jest nadanie jej dobrej nazwy. W celu głębszego przestudiowania komentarzy i poprawnego nazewnictwa polecam lekturę ponadczasowych klasyków:„Czysty kod: podręcznik zwinnego tworzenia oprogramowania” autorstwa Roberta Martina . Tym akcentem pierwsza część tego artykułu (moje refleksje) dobiegła końca. Ciąg dalszy nastąpi...