Analiza typowych błędów początkujących programistów: część 1

Witaj świecie! Kiedy już nauczysz się wszystkiego, czego potrzebujesz i w końcu zostaniesz zatrudniony jako stażysta lub junior, prawdopodobnie możesz się zrelaksować, prawda? Nieważne jak to jest! Wszystko się dopiero zaczyna... Wokół Ciebie dzieje się mnóstwo nowych i niezrozumiałych rzeczy, a jak tu nie schrzanić od razu? Właśnie o tym dzisiaj porozmawiamy. W tym artykule chcę przyjrzeć się częstym błędom popełnianym przez początkujących i dać kilka wskazówek z własnego doświadczenia, jak ich unikać. Zacznijmy więc bez zbędnych ceregieli:

1. Strach przed poproszeniem o pomoc bardziej doświadczonych kolegów

Wszyscy jesteśmy ludźmi i wszyscy boimy się wyjść na głupców, szczególnie w oczach naszych świeżo upieczonych, bardziej doświadczonych kolegów. Deweloperzy po zdobyciu pierwszej pracy często poddają się temu strachowi i niepocieszeni zamykają się w sobie, próbując wszystko przemyśleć na własną rękę. Jednocześnie osobę można otoczyć bardziej doświadczonymi kolegami, którzy z kolei będą w stanie początkowo poprowadzić go najwłaściwszą ścieżką, co pomoże uniknąć większej liczby błędów i niepotrzebnych „uderzeń”. Dlatego pamiętaj: nie bój się zadawać pytań: jesteś początkujący i każdy doskonale to rozumie. Kiedy poprosisz, nikt nie będzie cię bił kijami. Być może jest nawet odwrotnie: szybciej zaprzyjaźnisz się ze współpracownikami i zaczniesz z nimi aktywniej się komunikować. Powiem więcej: im więcej będziesz pytać i omawiać różne kwestie techniczne, tym szybciej możesz wyjść z butów zielonego początkującego i stać się ekspertem w swojej dziedzinie. I jeszcze jedna rada. Nie zaniedbuj StackOverFlow . W tym kontekście mam na myśli zadawanie pytań na temat tego zasobu. Z jednej strony uzyskanie odpowiedzi na Twoje pytanie zajmuje trochę czasu. Ale z drugiej strony możesz od razu poznać kilka podejść do rozwiązania bieżącego problemu i spojrzeć na niego z nieco innej perspektywy. Chciałbym również zauważyć, że pisanie komentarzy-odpowiedzi, wyjaśnianie pytań na pytania dotyczące StackOverFlow od innych programistów, oprócz plusu w karmie, ma praktyczną korzyść: masz możliwość głębszego omówienia i zrozumienia tego problemu.

2. Nie próbuj samodzielnie szukać informacji

Być może ten błąd jest odwrotną stroną poprzedniego. Mam na myśli, kiedy zaczynasz ciągnąć swoich kolegów i znajomych z każdym problemem lub problemem. Zadawanie pytań jest dobre, ale nie powinieneś zadawać pytań zbyt daleko, w przeciwnym razie możesz się po prostu znudzić. Pierwszą rzeczą, którą należy zrobić, jeśli pojawi się jakiś niezrozumiały punkt, jest wykorzystanie swoich umiejętności wyszukiwania w najlepszej wyszukiwarce – Google. Ktoś już napotkał zdecydowaną większość niezrozumiałych błędów i innych problemów. Będziesz dość zaskoczony, jeśli wpiszesz w Google i zobaczysz liczbę osób, które znają podobny problem i które otrzymały już wyczerpujące odpowiedzi, nadające się do wykorzystania w ich pracy. Na tej podstawie często można usłyszeć, jak kolega odpowiada na pytanie „Wygoogluj to”. Nie powinna Cię urazić ta odpowiedź, bo przecież Twój kolega nie jest osobistym nauczycielem, który powinien przekazywać Ci wszystkie zawiłości z Twojej dziedziny pracy. Niekończące się przestrzenie Internetu pomogą Ci w takim mentoringu. Czasami programista nazywany jest także osobą z czarnym pasem w wyszukiwarce Google . Dlatego, gdy utkniemy, najpierw wyszukujemy problem w Google, a jeśli nie znajdziemy rozwiązania (rzadko, ale się zdarza), to zaczynamy pytać naszych kolegów. Warto zapytać ich od razu, nie wtedy, gdy pojawi się jakaś usterka lub niezrozumiały błąd, ale przy wyborze podejścia do rozwiązania problemu. W końcu potrafią spojrzeć poza twoje i od razu powiedzieć, jak to czy inne podejście może okazać się na dłuższą metę.

3. Ślepe kopiuj-wklej

Ale wygooglowanie problemu i, w związku z tym, jego rozwiązania, ma swoje pułapki. Na przykład ślepe kopiowanie i wklejanie . Zwykle dzieje się tak, gdy znajdziesz podobny problem (ale być może nie dokładnie taki sam) i pod nim, na przykład w StackOverFlow, znajduje się rozwiązanie. Bierzesz to rozwiązanie, kopiujesz i wklejasz sam, bez wchodzenia w szczegóły. A potem Ty lub Twoi koledzy z projektu odkrywacie dziwne błędy lub nieprawidłowe zachowanie Twojej funkcjonalności. I od razu nikt nie ma pojęcia, skąd się wzięły nogi. Wtedy oczywiście znajdzie się miejsce z tym kodem i na pewno nie zostaniesz pochwalony za tę decyzję. Dlatego też, gdy znajdziesz gotowe rozwiązanie na StackOverFlow (lub gdzie indziej), przede wszystkim musisz je szczegółowo przeanalizować, co to jest, jak i dlaczego. Być może wyszukaj w Google tę funkcję i zajrzyj do jej dokumentacji. I dopiero potem zaimplementuj to w swoim projekcie.

4. Rzucenie złego rozwiązania

Podczas pisania rozwiązania czasami zdarza się, że staje się ono coraz bardziej złożone i ostatecznie trafia w ślepy zaułek. Próbujesz coraz bardziej to komplikować, aby w jakiś sposób rozwiązać ten problem, stosując to podejście, zamiast szukać innej, bardziej praktycznej alternatywy. Może po prostu żałujesz poświęconej energii i czasu, więc decydujesz: nieważne co się stanie, nie poddawaj się, ale rozwiąż problem w ten sposób. Nie jest to do końca właściwe podejście. Przynajmniej w programowaniu. Im szybciej wypróbujesz inne podejście, tym więcej czasu zaoszczędzisz. Nie bój się więc eksperymentować i próbować innych podejść, pomimo ilości czasu, jaki w to zainwestowałeś. Co więcej, będą to punkty za twoje doświadczenie, ponieważ wypróbujesz kilka podejść i lepiej przestudiujesz ten obszar.

5. Strach przed zadawaniem pytań na temat bieżącego zadania

Praca nad projektem zazwyczaj sprowadza się do wykonania pewnych zadań (Zadań). Na przykład w Jirze . A zadania te nie zawsze są szczegółowo i przejrzyście opisane. Piszą je zazwyczaj liderzy zespołów, a jeśli tak się dzieje, są to także ludzie. Mogą też zapomnieć coś dodać lub nie wziąć pod uwagę, że nie znasz zbyt dobrze tej czy innej funkcjonalności. No cóż, albo nie masz dostępu do projektu (na przykład dostępu do bazy danych, do serwera logów i tak dalej). A teraz, po otrzymaniu zadania i przestudiowaniu go przez ponad kilka godzin, nadal siedzisz i patrzysz na ekran ze zdziwieniem. Zamiast bezskutecznie rozwiązywać tę kwestię, powinieneś zacząć zadawać pytania prowadzące/wyjaśniające twórcy tego zadania. Powiedzmy, w aplikacji, której używasz do komunikacji w zespole (na przykład Microsoft Teams) lub bezpośrednio jako komentarz pod tym zadaniem. Z jednej strony, jeśli napiszesz pytanie w wiadomości prywatnej, najprawdopodobniej odpowiedź będzie szybsza, ponieważ dana osoba od razu zobaczy pytanie. Z drugiej strony zadając pytanie w Jirze masz dowód, że coś robisz, czyli analizujesz problem. Jest sposób na przyspieszenie tego procesu: zadaj pytanie w komentarzu w Jira i wyślij link do tego komentarza w wiadomości prywatnej z prośbą o zajrzenie.

6. Zbyt wiele oczekujesz od lidera zespołu

Ponownie, jest to druga strona poprzedniego punktu. Lider zespołu to osoba, która jest szefem zespołu programistów. Z reguły większość czasu takiego członka zespołu spędza na różnego rodzaju komunikacji. A jednocześnie pisze też kod, żeby nie zapomnieć o co w tym wszystkim chodzi. Jak rozumiesz, jest to bardzo zajęta postać. A nadmierne drżenie przy każdym kichnięciu oczywiście nie sprawi mu radości. Wyobraź sobie, że każdy członek zespołu bombardował go mnóstwem pytań. Można więc zwariować, prawda? I nie będzie zaskakujące, że przy wielu pytaniach z Twojej strony będzie ci odpowiadał przez długi czas. Co możesz zrobić, aby zmniejszyć liczbę pytań kierowanych do lidera zespołu:

• Przestudiuj dokładniej dokumentację tego projektu, aby zmniejszyć liczbę martwych punktów.
• Zadawaj pytania innym członkom zespołu. Całkiem możliwe, że są zaznajomieni z tą funkcjonalnością tak samo jak lead, albo nawet bardziej, bo najprawdopodobniej któryś z nich napisał tę funkcjonalność.

Alternatywnie, w IDE możesz przeglądać adnotacje: kto i kiedy ostatnio zmienił kod w określonej linii. W ten sposób dowiemy się, kto najsłuszniej zadaje to pytanie. Jak zapewne już zrozumiałeś, zadając pytania liderowi zespołu, a także zadając pytania współpracownikom, trzeba starać się zachować złoty środek – nie bać się zadawać pytań, ale też nie zadręczać ich nadmierną liczbą.

7. Strach przed przeglądem kodu

Przegląd kodu lub przegląd kodu to etap poprzedzający przesłanie kodu do wspólnej aplikacji (do wspólnej gałęzi, na przykład master lub dev). Kontrolę tę przeprowadza niezwiązany z tym zadaniem programista, który dzięki świeżemu spojrzeniu może odkryć błędy, nieścisłości lub niedociągnięcia w stylu kodu, które pozostały niezauważone w początkowej fazie rozwoju. Jeśli istnieją komentarze, pozostają one jako komentarze do niektórych sekcji kodu. W takim przypadku deweloper, który wykonał to zadanie, musi skorygować błędy zgodnie z recenzją (lub przedyskutować swoje decyzje z recenzentem, być może przekonując go o słuszności swojej decyzji). Następnie odeślij go z powrotem do recenzji i tak dalej, aż recenzent nie będzie miał żadnych komentarzy. Recenzent pełni rolę „filtra” przed przesłaniem kodu. Dlatego wielu początkujących programistów postrzega recenzję kodu jako krytykę i potępienie. Nie doceniają jej i się jej boją, a to jest złe. To przegląd kodu pozwala nam ulepszyć nasz kod. Dostajemy przecież ważne informacje o tym, co robimy źle i na co powinniśmy zwrócić uwagę. Każdą recenzję kodu należy traktować jako część nauki, coś, co może pomóc w ulepszeniu. Kiedy ktoś zostawia komentarz na temat Twojego kodu, dzieli się z Tobą swoim doświadczeniem, najlepszymi praktykami. Jeśli chodzi o mnie, nie można zostać dobrym programistą bez sprawdzenia kodu. Bo nie wiesz jak dobry jest Twój kod i czy z punktu widzenia doświadczonej osoby z zewnątrz nie ma w nim błędów.

8. Skłonność do zawiłych rozwiązań

Często różne zadania/problemy mogą mieć kilka różnych rozwiązań. A ze wszystkich dostępnych rozwiązań początkujący zwykle korzystają z najbardziej skomplikowanych i „zawiłych”. I to prawda: jeśli jeszcze wczoraj początkujący programista studiował wiele różnych algorytmów, wzorców, struktur danych, to ręce go swędzą, żeby zaimplementować któryś z nich. Tak i chcę, że tak powiem, zadeklarować się. Uwierz mi, sam taki byłem i wiem, co mówię :) Miałem sytuację, w której spędziłem dużo czasu na pisaniu jednej funkcjonalności, która okazała się bardzo, bardzo złożona. Następnie został przepisany przez programistę na poziomie Senior+. Oczywiście ciekawiło mnie co i jak to zmienił. Przyjrzałem się jego realizacji i byłem zdumiony, o ile stało się to prostsze. A kod stał się trzy razy mniejszy. Jednocześnie testy tej funkcjonalności nie zmieniły się i nie zawiodły! Oznacza to, że ogólna logika pozostaje taka sama. Z tego doszedłem do wniosku, że: najbardziej pomysłowe rozwiązania są zawsze proste . Po tej realizacji pisanie kodu stało się znacznie łatwiejsze i stało się zauważalnie bardziej zaawansowane. No cóż, kiedy zatem warto stosować wzorce i algorytmy, pytacie? Wtedy ich użycie będzie najprostszym i najbardziej kompaktowym sposobem.

9. Wynalazek rowerów

Koncepcja ta znana jest również jako wynalazek koła. Jego istota polega na tym, że programista wdraża własne rozwiązanie problemu, dla którego rozwiązania już istnieją, a wielokrotnie lepsze od tych wymyślonych przez programistę. Wynalezienie własnego roweru z reguły będzie wiązało się ze stratą czasu i spadkiem efektywności pracy programisty, ponieważ może nie zostać znalezione rozwiązanie dalekie od najlepszego lub może w ogóle nie zostać znalezione. Jednocześnie nie można odrzucić możliwości samodzielnego podejmowania decyzji. Programista musi poprawnie poruszać się po zadaniach, które mogą się przed nim pojawić, aby kompetentnie i terminowo je rozwiązać, korzystając z gotowych rozwiązań lub wymyślając własne. Z jednej strony na uczelniach i na kursach jesteśmy bombardowani różnego rodzaju zadaniami, które powinny nam pomóc w zajęciu się tworzeniem rowerów. Ale to tylko na pierwszy rzut oka. W rzeczywistości celem tego jest rozwinięcie myślenia algorytmicznego i głębsze opanowanie składni języka. A takie zadania pomagają też lepiej zrozumieć algorytmy/struktury i, jeśli zajdzie taka potrzeba, dają im umiejętności implementacji ich zaawansowanych analogów (choć jest to bardzo rzadko potrzebne). W prawdziwym życiu w zdecydowanej większości przypadków nie ma potrzeby wymyślania własnego koła, ponieważ od dawna istnieją analogi, które zaspokajają nasze potrzeby. Być może ze względu na twoje doświadczenie nie będziesz wiedział o istnieniu implementacji tej lub innej funkcjonalności, której potrzebujesz. W tym miejscu należy skorzystać z pierwszego punktu tego artykułu, a mianowicie poprosić o pomoc bardziej doświadczonych kolegów. Będą w stanie Cię poprowadzić (np. doradzić w jakim kierunku do Google) lub zasugerować konkretną implementację (konkretną bibliotekę).

10. Nie pisz testów

Wszyscy początkujący nie lubią pisać testów. A co z nowicjuszami: nie-nowicjusze też nie lubią pisać testów, ale lepiej rozumieją, dlaczego jest to potrzebne. Kiedy jesteś zupełnie zielony, myślisz: po co je pisać? Wszystko działa i nie może być żadnych błędów. Ale skąd możesz mieć pewność, że wprowadzone zmiany nie uszkodzą czegoś w innej części systemu? Twoi współpracownicy nie docenią tego, jeśli przeforsujesz zmiany, które bardziej zakłócają niż przynoszą korzyści. I tu z pomocą przychodzą testy. Im bardziej aplikacja jest objęta testami, tym lepiej (tzw. procent pokrycia). Jeśli aplikacja jest dobrze objęta testami, uruchamiając je wszystkie, możesz znaleźć miejsca, które mogą zostać uszkodzone przez wprowadzone zmiany. I jak powiedziałem w powyższym przykładzie, podczas refaktoryzacji funkcjonalności testy nie zawiodły, a wszystko dlatego, że ogólna logika się nie zmieniła. Oznacza to, że testy mogą również wykazać, czy logika określonej funkcjonalności uległa zmianie, czy nie. Nawet jeśli nie lubisz pisać testów, korzyści z nich płynące są niewątpliwe i warto poświęcić im czas.

11. Nadmierne komentowanie

Wielu programistów cierpi na perfekcjonizm, a początkujący nie są wyjątkiem. Ale czasami efektem ubocznym tego pragnienia jest to, że zaczynają komentować wszystkich i wszystko. Nawet to, co niepotrzebne, bo to takie oczywiste:

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

Nie wszyscy początkujący programiści od razu zdają sobie sprawę, że komentowanie kodu nie zawsze jest dobrą rzeczą, ponieważ kod okaże się znacznie bardziej zaśmiecony i trudniejszy do odczytania. A co jeśli kod został zmieniony, ale nie było komentarza? Okazuje się, że nas oszuka i tylko zmyli. Skąd więc taki komentarz? Zwykle dobrze napisany kod nie wymaga komentarza , gdyż wszystko w nim jest już oczywiste i czytelne. Jeśli napiszesz komentarz, to znaczy, że już zrujnowałeś czytelność kodu i próbujesz jakoś załagodzić sytuację. Najlepszym rozwiązaniem byłoby na początku napisanie czytelnego kodu, który nie wymaga uzupełnienia komentarzami. Nie mogłem też nie wspomnieć o poprawnym nazewnictwie metod, zmiennych i klas, a mianowicie o zasadzie, której sam się trzymam: Najlepszym komentarzem jest brak komentarza, a zamiast niego poprawne nazewnictwo , które jasno to opisuje lub tę funkcję w aplikacji.

12. Złe nazewnictwo

Często początkujący fałszują nazwy klas, zmiennych, metod itp. Na przykład, gdy tworzą klasę, której nazwa w ogóle nie opisuje jej przeznaczenia. Albo tworzona jest zmienna o krótkiej nazwie, na przykład x , a kiedy tworzone są dwie kolejne zmienne o nazwach n i y , bardzo trudno jest zapamiętać, co robi x . W takich przypadkach trzeba dokładnie przemyśleć kod i przestudiować tę funkcjonalność pod mikroskopem (być może za pomocą debugera), aby po prostu zrozumieć, co się w nim dzieje. Tutaj z pomocą przychodzi nam prawidłowe nazewnictwo w kodzie, o którym wspomniałem powyżej. Prawidłowe nazwy poprawiają czytelność kodu, oszczędzając tym samym czas na zapoznawaniu się, ponieważ znacznie łatwiej jest zastosować metodę, w której nazwa w przybliżeniu opisuje jego funkcjonalność. W kodzie wszystko składa się z nazw (zmiennych, metod, klas, obiektów plików itp.), ten punkt staje się bardzo ważny przy tworzeniu poprawnego, czystego kodu. Warto pamiętać, że nazwa powinna przekazywać znaczenie: dlaczego np. zmienna istnieje, do czego służy i jak się ją wykorzystuje. I będę stale podkreślał, że najlepszym komentarzem do opisu zmiennej jest jej poprawna nazwa. Dla głębszego przestudiowania komentarzy i prawidłowego nazewnictwa radzę przeczytać ponadczasową klasykę: „Czysty kod. Tworzenie, analiza i refaktoryzacja”, Robert Martin . W tym miejscu zakończyła się pierwsza część artykułu (refleksje). Ciąg dalszy nastąpi…