Nauka z HackerRank i Leetcode to nie wszystko

Ostatnio wśród programistów oraz rekruterów popularne stały się platformy programistyczne, takie jak HackerRank oraz Leetcode. Umożliwiają one ćwiczenie na problemach algorytmicznych i strukturach danych w ramach przygotowań do rozmowy kwalifikacyjnej (lub czegokolwiek innego). Ale ocena (i co najważniejsze — przygotowanie) umiejętności tworzenia oprogramowania na podstawie tych ćwiczeń jest niedokładna i niereprezentatywna, co zaraz dokładniej wyjaśnię.

Bubble sort, insertion sort, merge sort, heap sort, quick sort, algorytm Dijkstry, algorytm Floyda i tak dalej. Poświęciłeś wiele godzin na algorytmy i struktury danych i wydaje Ci się, że wiesz już wszystko. Czujesz się pewnie i świetnie wypadasz na rozmowie kwalifikacyjnej, rozwiązując wszystkie zadania.

Potem przychodzi pierwszy dzień pracy, otwierasz listę zadań i zdajesz sobie sprawę, że musisz naprawić 2 błędy CSS, refaktoryzować test jednostkowy i dodać obsługę błędów do wywołania API. Nic takiego nie pojawiło się jak dotąd na drodze Twojej nauki, czujesz się przytłoczony studiowaniem ogromnej bazy kodu i powoli się wypalasz.

Ta krótka historia ma pokazać Ci, że programowanie to nie tylko algorytmy i struktury danych. Są też rzeczy, na które nikt nie zwraca uwagi. Omówię teraz 5 rzeczy, na które należy zwrócić uwagę poza algorytmami i strukturami danych.

Czytanie kodu innych ludzi

Jest to najbardziej niedoceniana umiejętność. Czytanie istniejącego (i być może kodu legacy) jest niezbędne w każdym zawodzie programistycznym. Musisz w pełni zrozumieć kod źródłowy, zanim wprowadzisz w nim jakiekolwiek zmiany. Powinieneś być w stanie dokonać przeglądu kodu swoich rówieśników i być na niego otwarty.

Code review jest niezbędny do utrzymania spójnej bazy kodu i upewnienia się, że wszystkim chodzi o to samo. Jeśli czujesz się pewnie, czytając kod, nie będziesz tak często odnosić się do dokumentacji i innych użytkowników z niepotrzebnymi pytaniami, zwiększając w ten sposób produktywność.

Co więcej, czytanie kodu innych ludzi sprawi, że Twój kod będzie coraz lepszy. Znajdziesz tam rozwiązania dla typowych problemów, zanim sam na nie wpadniesz. Zauważysz też różne zapachy kodu. Łatwo się tego nauczyć.

Poczytaj sobie jakąś bibliotekę open-source na Githubie. Spróbuj  zrozumieć kod i spróbuj naprawić niektóre problemy. Wykonując to proste ćwiczenie, natychmiast poprawisz się w tworzeniu wysokiej jakości kodu, a seniorzy w pracy to docenią. Będziesz także dawać coś od siebie dla społeczności open source, która ma swoje zalety.

Czytelność

Chociaż jest to ściśle związane z poprzednią częścią, to jest to tak ważny problem, że zasługuje on na osobną sekcję. Problem z czytelnością objawia się, gdy baza kodu rośnie, a Ty nie możesz zachować jej spójności i przejrzystości. Należy stosować takie zasady, jak hermetyzacja, możliwość ponownego użycia, KISS (Keep It Simple, Stupid, czyli najważniejsza jest prostota) i DRY (Don't Repeat Yourself, czyli nie powtarzaj się).

Nie ma jednego i uniwersalnego rozwiązania dla stworzenia czytelnego kodu. Czytelność można poprawić, czytając nieznany kod, refaktoryzując swój kod do tego momentu, aż wszyscy go zrozumieją. Pamiętaj również, że komentarze nie są lekarstwem na zły kod: jeśli Twój kod wymaga komentarzy ze względu na czytelność, coś jest z nim nie tak.

Jeśli chcesz tworzyć konsekwentnie czytelny i wysokiej jakości kod, gorąco polecam przeczytanie Czysty Kod autorstwa Roberta Cecila Martina. Przeprowadzi Cię ona przez typowe problemy, przedstawi ich rozwiązania i sprawi, że poczytasz i poćwiczysz trochę samemu. Gdyby to zależało ode mnie, książki tej nauczano by na wszystkich kierunkach technologicznych.

Współpraca

Samodzielne rozwiązywanie interesujących problemów komputerowych jest przyjemne, ale niezbyt w pracy wydajne. Wymaga to innego sposobu myślenia, którego nie można się przekazać, a da się jedynie nauczyć. Ponadto musisz mieć pewność co do narzędzi takich jak Git, Jira, Slack lub ich alternatyw.

Aby stać się bardziej wydajnym członkiem zespołu, będziesz musiał pracować w grupach, a jest to coś, czego platformy takie jak HackerRank / Leetcode nie mogą jeszcze zapewnić (nie z własnej winy).

Na szczęście większość ludzi zdobywa w tym doświadczenie, pracując nad projektami grupowymi na uczelniach/bootcampach, ale jeśli jesteś programistą samoukiem (tak jak ja), będziesz musiał podnieść swoje umiejętności współpracy i komunikacji.

Myślenie o szerszej perspektywie

Podczas rozwiązywania drobnych i niepodzielnych problemów szybko staniesz się zbyt pewny siebie. Ale nadal będzie Ci brakować kluczowej umiejętności: myślenia o szerszej perspektywie. Podczas gdy problemy na platformach edukacyjnych są najczęściej ograniczone do jednego pliku, to rzeczywisty projekt ma ich już więcej. Ponadto będą zawierać tysiące plików z setkami klas i milionami wierszy kodu.

Wprowadzając zmiany w jednej części kodu, musisz być stale świadomy zmian, jakie przyniesie to w innych jego częściach. Oczywiście czysty kod i rygorystyczne testy mogą w tym pomóc, ale nie pozbędą się całkowicie pewnych błędów.

Jako programista nieustannie podejmujesz decyzje, nawet na poziomie początkującym/juniorskim. Może to dotyczyć wywołania zmiennej i którego elementu HTML użyć oraz który dostawcy usług w chmurze najlepiej odpowiada naszym potrzebom i która struktura aplikacji będzie działać najlepiej.

Niezależnie od natury danej decyzji, deweloperzy muszą być świadomi konsekwencji swoich działań. Taki sposób myślenia można sobie wypracować, pracując przez chwilę nad jednym projektem i rozwinąć się na tyle, żeby dostrzec wszystkie konsekwencje swoich początkowych działań.

Bezpieczeństwo

Bezpieczeństwo informacji to obszerny i złożony temat i nikt nie oczekuje, że będziesz wiedzieć na ten temat wszystko, kiedy zaczniesz już pracę. Mówiąc o bezpieczeństwie, mam na myśli stosowane praktyk na poziomie kodu, których każdy powinien przestrzegać.

Są to: hermetyzacja (ukrywanie implementacji funkcji wewnętrznych), zasada jednej odpowiedzialności (jeden podmiot powinien robić jedną rzecz, a żadne inne podmioty nie powinny w nią ingerować) oraz single point of truth principle (SPOT — twoje dane pochodzą z jednego źródła oraz nigdy się nie powtarzają).

Zasady te chronią Twój kod przed najbardziej oczywistymi atakami i są naprawdę łatwe do ogarnięcia. Nie potrzebujesz ich podczas wykonywania pojedynczych ćwiczeń, a są one niezwykle ważne.

Podsumowanie

Dziękuję za uwagę, mam nadzieję, że teraz rozumiesz, że programowanie to coś więcej niż wykonywanie pojedynczych ćwiczeń.

Mimo to chciałbym zaznaczyć, że algorytmy i struktury danych są równie ważne i istotne jest, żeby znać przynajmniej te najpopularniejsze.

Źródła

• Clean Code: A Handbook of Agile Software Craftsmanship
• How to Contribute to Open Source

Oryginał tekstu w języku angielskim możesz przeczytać tutaj.