Ostatnio przeprowadzałem rozmowę kwalifikacyjną z programistą JavaScript, który ubiegał się o stanowisko seniora. Kolega, który również brał udział w rozmowie, poprosił kandydata o napisanie funkcji, która wykonuje żądanie HTTP i w przypadku niepowodzenia powtarza próbę kilka razy.
Pisał kod od razu na tablicy, więc wystarczyło by zilustrować coś przybliżonego. Gdyby po prostu pokazał, że dobrze rozumie, na czym polega problem, bylibyśmy całkiem zadowoleni. Niestety, nie udało mu się znaleźć dobrego rozwiązania. Wtedy, przypisując to jego zdenerwowaniu, postanowiliśmy nieco ułatwić zadanie i poprosiliśmy go, aby przekształcił funkcję z wywołaniami zwrotnymi na funkcję opartą na obietnicach.
Ale niestety. Tak, było oczywiste, że podobny kod spotkał go wcześniej. Ogólnie rzecz biorąc, wiedział, jak to wszystko działa. Wystarczyło by nam szkic rozwiązania, który wykazywałby zrozumienie koncepcji. Niemniej jednak kod, który kandydat pisał na tablicy, był kompletną bzdurą. Miał bardzo mgliste pojęcie o tym, czym są obietnice w JavaScript i nie potrafił skutecznie wyjaśnić, dlaczego są potrzebne. Dla juniora byłoby to jeszcze do przyjęcia, ale na stanowisko seniora już się nie nadawał. Jak ten programista mógłby naprawić błędy w skomplikowanym łańcuchu obietnic i wytłumaczyć innym, co dokładnie zrobił?
Programiści uważają gotowy kod za coś oczywistego.
W procesie tworzenia oprogramowania nieustannie stykamy się z materiałami, które można powielać. Przenosimy fragmenty kodu, aby nie musieć ich za każdym razem pisać od nowa. Koncentrując się zatem na kluczowych częściach, patrzymy na gotowy kod, z którym pracujemy, jako na coś oczywistego – po prostu zakładamy, że wszystko będzie działać jak należy.
I zazwyczaj tak jest, ale gdy pojawiają się trudności, zrozumienie jego mechaniki zdecydowanie się opłaca.
Nasz kandydat na stanowisko programisty seniora uważał, że obiekty obietnic są czymś oczywistym. Prawdopodobnie wiedział, jak się nimi posługiwać, gdy pojawiają się w cudzym kodzie, ale nie rozumiał ogólnej zasady i nie mógł jej powtórzyć podczas rozmowy kwalifikacyjnej. Być może zapamiętał fragment na pamięć – to nie jest aż tak trudne:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Ja też tak robiłem – wszyscy prawdopodobnie robiliśmy to kiedyś. Po prostu zapamiętywaliśmy kawałek kodu, aby móc go potem wykorzystać w pracy, mając jedynie ogólną wizję, jak to wszystko działa. Gdyby jednak programista naprawdę rozumiał koncepcję, nie musiałby niczego zapamiętywać – po prostu wiedziałby, jak to zrobić, i bez trudu odtworzyłby wszystkie niezbędne elementy w kodzie.
Sięgaj do korzeni
W 2012 roku, kiedy jeszcze nie zapanowało panowanie frameworków frontendowych, światem rządził jQuery, a ja czytałem książkę , której autorem był John Resig, twórca jQuery.
Książka uczy czytelnika, jak stworzyć własne jQuery od podstaw i daje unikalną możliwość zapoznania się z myśleniem, które doprowadziło do stworzenia tej biblioteki. W ostatnich latach jQuery straciło swoją dawną popularność, ale wciąż bardzo polecam tę książkę. To, co najbardziej mnie w niej zaskoczyło – to uporczywe poczucie, że mógłbym sam do tego wszystkiego dojść. Kroki, które opisywał autor, wydawały się na tyle logiczne i zrozumiałe, że przeżyłem moment przekonania, że mógłbym stworzyć jQuery, gdybym tylko się za to wziął.
Oczywiście w rzeczywistości nie poradziłbym sobie z czymś takim – uznałbym, że to zbyt trudne. Moje własne rozwiązania wydawałyby mi się zbyt proste i naiwne, aby zadziałały, i poddałbym się. Uważałbym jQuery za coś oczywistego, w poprawne działanie czego trzeba po prostu ślepo wierzyć. W późniejszym czasie zapewne nie zainwestowałbym czasu na zgłębianie mechaniki tej biblioteki, a po prostu korzystałbym z niej jak z rodzaju czarnej skrzynki.
Jednak zapoznanie się z tą książką uczyniło mnie inną osobą. Zacząłem wczytywać się w kod źródłowy i odkryłem, że realizacja wielu rozwiązań jest w rzeczywistości bardzo przejrzysta, nawet oczywista. Oczywiście, samodzielne wymyślenie czegoś takiego to już inna sprawa. Ale to właśnie badanie cudzych kodów i odtwarzanie istniejących już rozwiązań pomaga nam wymyślać coś własnego.
Inspiracja, którą czerpiesz, oraz wzorce, które zaczynasz dostrzegać, zmienią cię jako programistę. Odkryjesz, że ta wspaniała biblioteka, z której nieustannie korzystasz i którą przywykłeś postrzegać jako magiczny artefakt, wcale nie opiera się na magii, lecz po prostu rozwiązujesz problem w sposób zwięzły i pomysłowy.
Czasami trzeba się zmagać z kodem, analizując go krok po kroku, ale właśnie w ten sposób, posuwając się małymi, systematycznymi krokami, możesz powtórzyć drogę autora do rozwiązania. Pozwoli ci to głębiej zanurzyć się w proces pisania kodu i zwiększy pewność siebie podczas szukania własnych rozwiązań.
Kiedy dopiero zaczynałem pracę z obietnicami, wydawało mi się, że to czysta magia. Potem dowiedziałem się, że opierają się na tych samych callbackach, a mój programistyczny świat się przewrócił. To znaczy, że wzorzec, którego celem jest uwolnienie nas od callbacków, sam jest realizowany za pomocą callbacków?!
To pomogło mi spojrzeć na to z innej perspektywy i zrozumieć, że przede mną nie stoją żadne skomplikowane fragmenty kodu, które są dla mnie nieosiągalne. To tylko wzorce, z którymi można sobie poradzić przy odpowiedniej ciekawości i głębokim zanurzeniu. Tak ludzie uczą się programować i rozwijają się jako programiści.
Wynajdź to koło na nowo
Nie bój się więc wynajdywać kół na nowo: sam napisz kod do łączenia danych, stwórz domowy promises lub nawet zbuduj własne rozwiązanie do zarządzania stanami.
Nie ma znaczenia, że nikt nigdy z tego nie skorzysta – teraz już umiesz to robić. A jeśli później będziesz miał okazję wykorzystać takie osiągnięcia w swoich projektach, to będzie wspaniale. Będziesz mógł je rozwijać i nauczyć się czegoś nowego.
Sęk w tym, żeby nie wysyłać swojego kodu na produkcję, ale aby nauczyć się czegoś nowego. Samodzielne implementowanie już istniejącego rozwiązania to doskonały sposób, aby uczyć się od najlepszych programistów i doskonalić swoje umiejętności.
Źródło: habr.com
