Jak algorytmy i struktury danych wpływają na Twoją karierę w IT?
Pytanie o użyteczność znajomości algorytmów i struktur danych (A&DS, ang. Algorithms & Data Structures) w codziennej pracy pojawia się cyklicznie na forach, blogach, mediach społecznościowych. Często towarzyszą tej dyskusji argumenty typu: "A kiedy ostatnio musiałeś zaimplementować merge sort od zera?!" Kiedy? Nigdy. 🤔
TL;DR; Czy znajomość A&DS przydaje się w pracy? Tak!
Znajomość i zrozumienie tych podstaw pozwoli Ci:
Uniknąć prostych pułapek z wydajnością 💡
Rozwiązywać problemy w ustrukturyzowany sposób 🧩
Wykorzystywać gotowe rozwiązania 🛠️
Lepiej komunikować się ze współpracownikami 🗣️
Jeśli jest jedna rzecz, którą chciałbym, abyś wyniósł(a) z tego wpisu, to to, że znajomość algorytmów i struktur danych przydaje się niezależnie od tego, jak skomplikowany jest projekt, nad którym pracujesz.
„Dla człowieka, który ma tylko młotek, wszystko, co napotyka, zaczyna wyglądać jak gwóźdź.”
Podstawowe algorytmy i struktury danych to Twoje narzędzia. Do większości codziennych zadań wystarczy młotek i kombinerki, ale czasem przychodzi problem wymagający większej finezji.
Unikanie prostych pułapek z wydajnością
Klasyczna sytuacja "U mnie działa 🤷": robisz sobie jakiś feature w lokalnym środowisku, wszystko działa. Deployment na produkcję i nagle Twój feature zaczyna spowalniać. Często takie problemy wynikają ze skali ilości danych, na których operuje system produkcyjny.
Nie sposób mówić o algorytmach bez rozmowy o ich wydajności i sposobie jej mierzenia - O(n)
(Big O notation). O(n)
to formalny zapis, jak zmienia się czas / ilość operacji, jakie algorytm musi wykonać w stosunku do ilości elementów, na których operuje. Spokojnie, nie musisz znać wszystkich niuansów, IMO wystarczy relatywnie powierzchowna wiedza co to znaczy, że algorytm ma złożoność czasową O(n^2)
, O(n)
, O(1)
- polecam 👉 Big O Cheat Sheet.
Jeśli potrafisz zidentyfikować, że dane rozwiązanie jest O(n^2)
zanim trafi ono na produkcję (np. przy code review!), to zaoszczędzisz sobie, firmie i użytkownikom nerwów i pieniędzy.
Rozwiązywanie problemów
Praca programisty polega głównie na rozwiązywaniu problemów i, o ile najważniejszy jest wynik końcowy, to jak do niego dojdziesz też ma znaczenie. Nauka (i ćwiczenie!) algorytmów pozwala Ci wyrobić sobie szerszą perspektywę.
Ile razy miałeś(aś) jakiś złożony problem przed sobą i pojawiała się panika? Ja mam tak często (cough! cough! syndrom oszusta!). Wiele problemów jest zbyt skomplikowanych, aby rozwiązać je od razu, stąd też podejście divide & conquer, czyli w skrócie - rozbij duży problem na parę mniejszych.
Rozwiązując zadania algorytmiczne wyrobisz w sobie nawyk szukania tych mniejszych problemów, które łatwiej rozwiązać, a być może nawet już jest gotowy sposób na ich rozwiązanie.
Wykorzystywanie gotowych rozwiązań
No właśnie, w przeważającej ilości przypadków zadanie, które stoi przed Tobą, nie jest niczym nowym. Może niekoniecznie TEN DOKŁADNIE problem, ale na tyle podobny, że da się go wpasować w odpowiednią abstrakcję. Musisz tylko wiedzieć, jaką 🙂
Załóżmy, że dostajesz zadanie zaimplementować "org chart" pracowników. Jedną z funkcjonalności jest wyświetlenie najbliższego wspólnego menedżera. Moje pierwsze kroki?
Google: nodejs graph library
Jeśli choć zahaczyłeś o algorytmy i struktury danych, to powinna Ci się zapalić lampka, że to szukanie "lowest common ancestor" w grafie. Wierz mi, wszyscy będą Ci wdzięczni, że nie naklepałeś dziesiątek linii kodu, które ktoś będzie musiał potem utrzymywać.
Always code as if the person who will maintain your code is a maniac serial killer knows where you live
A może nawet zaproponujesz zastosowanie bazy danych opartej na grafach (graph database), to jest myślenie seniora 👍.
Komunikacja
No właśnie, wspomniałem wcześniej o code review i szukaniu gotowych rozwiązań. Żeby robić to skutecznie, musisz znać słownictwo. Nie zrozum mnie źle, nie chodzi o popisywanie się trudnymi słowami - chodzi o zwięzłą, precyzyjną komunikację. Zamiast mówić o "liście elementów, które się nie powtarzają", wystarczy powiedzieć "Zbiór" (rada ode mnie, lepiej posługiwać się angielskimi określeniami, to jest de facto język komputerów).
Podsumowanie
Gdybym miał zaczynać naukę od nowa, zacząłbym właśnie od algorytmów i struktur danych. To inwestycja w fundament, to Twój toolbox. Codziennie powstają nowe frameworki, ale te podstawy się nie zmieniają. Nie daj sobie wmówić, że jeśli jesteś front-end developerem (tu możesz wstawić jakąkolwiek inną rolę aktualnie uznawaną za łatwą), to nie potrzebujesz znać algorytmów. Jest powód, dlaczego big tech - FAANG, MAANG i inne skróty - podczas rozmów technicznych stosują właśnie zadania algorytmiczne. Jeśli potrafisz rozwiązywać problemy, to z nauczeniem się kolejnej biblioteki też sobie poradzisz.
Materiały do nauki
Żeby nie zostawiać Cię z pustymi rękoma, tutaj parę linków do materiałów, z których sam korzystałem przy nauce:
Grokking the Coding Interview Patterns in JavaScript - 11$/mies., świetny kurs nakierowany głównie na rozpoznawanie, jaki algorytm / strukturę danych wykorzystać do danego problemu
LeetCode - darmowe, zadania algorytmiczne, duże aktywne community
Abdul Bari’s YouTube channel - darmowe, przystępny język, sporo zaawansowanych tematów
AlgoExpert - 100$, fajnie wytłumaczone rozwiązania + cała platforma do pisania i testowania kodu, IMO warte swojej ceny
Jeśli znasz kogoś, kto mógłby skorzystać z tych treści, zachęć go do zapoznania się z „Zatrudnialnym”. 📢
Jeśli któryś z tych tematów szczególnie Cię interesuje lub chcesz, abym poruszył inną kwestię, daj mi znać – ten newsletter jest dla Ciebie. Możesz mnie złapać na:
LinkedIn - mpasierbski
Twitter / X - @notMichal_
albo zostaw komentarz tutaj, na Substacku.