Któregoś dnia przeprowadziłem rozmowę z programistą JavaScript, który aplikował na wyższe stanowisko. Kolega, który również był obecny na rozmowie kwalifikacyjnej, poprosił kandydata o napisanie funkcji, która wyśle żądanie HTTP i w przypadku niepowodzenia ponawia próbę kilka razy.
Kod napisał bezpośrednio na tablicy, więc wystarczyło narysować coś w przybliżeniu. Gdyby po prostu pokazał, że dobrze rozumie, o co chodzi, bylibyśmy całkiem usatysfakcjonowani. Ale niestety nie udało mu się znaleźć skutecznego rozwiązania. Następnie, tłumacząc to ekscytacją, postanowiliśmy nieco ułatwić sobie zadanie i poprosiliśmy go, aby zamienił funkcję z wywołaniami zwrotnymi w funkcję zbudowaną na obietnicach.
Ale niestety. Tak, było oczywiste, że spotkał się już z takim kodem. Wiedział ogólnie, jak tam wszystko działa. Potrzebujemy jedynie szkicu rozwiązania, który wykaże zrozumienie koncepcji. Jednak kod, który kandydat napisał na tablicy, był kompletną bzdurą. Miał bardzo mgliste pojęcie o tym, jakie obietnice znajdują się w JavaScript i nie potrafił tak naprawdę wyjaśnić, dlaczego były potrzebne. Juniorowi byłoby to wybaczalne, ale on nie nadawał się już na stanowisko seniora. W jaki sposób ten programista byłby w stanie naprawić błędy w złożonym łańcuchu obietnic i wyjaśnić innym, co dokładnie zrobił?
Programiści uważają gotowy kod za coś oczywistego
W procesie rozwoju stale spotykamy materiały powtarzalne. Przesyłamy fragmenty kodu, abyśmy nie musieli za każdym razem pisać ich od nowa. W związku z tym, skupiając całą swoją uwagę na kluczowych fragmentach, patrzymy na gotowy kod, z którym pracujemy, jak na coś oczywistego - po prostu zakładamy, że wszystko będzie działać tak, jak powinno.
I zazwyczaj to działa, ale gdy sprawy stają się trudne, zrozumienie mechaniki bardziej niż się opłaca.
Tym samym nasz kandydat na stanowisko starszego programisty uznał obiekty obiecujące za oczywiste. Pewnie miał pomysł, jak sobie z nimi poradzić, gdy pojawiają się gdzieś w czyimś kodzie, jednak nie rozumiał ogólnej zasady i nie potrafił sam jej powtórzyć podczas rozmowy kwalifikacyjnej. Być może zapamiętał ten fragment na pamięć - to nie jest takie trudne:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Ja też to zrobiłem – i prawdopodobnie wszyscy to kiedyś robiliśmy. Po prostu zapamiętali fragment kodu, aby móc go później wykorzystać w swojej pracy, mając jedynie ogólne pojęcie o tym, jak wszystko tam działa. Ale gdyby programista naprawdę zrozumiał tę koncepcję, nie musiałby niczego pamiętać - po prostu wiedziałby, jak to zrobić i z łatwością odtworzyłby wszystko, czego potrzebował w kodzie.
Wróć do korzeni
W 2012 roku, gdy dominacja frameworków front-endowych nie była jeszcze ustalona, światem rządziło jQuery, a ja przeczytałem książkę , którego autorem jest John Resig, twórca jQuery.
Książka uczy czytelnika, jak od podstaw stworzyć własne jQuery i zapewnia unikalny wgląd w proces myślowy, który doprowadził do powstania biblioteki. W ostatnich latach jQuery straciło swoją dawną popularność, ale mimo to gorąco polecam tę książkę. To, co mnie w niej najbardziej uderzyło, to ciągłe poczucie, że sam mogłem o tym wszystkim pomyśleć. Kroki, które opisał autor, wydawały się tak logiczne, tak jasne, że poważnie zacząłem myśleć, że mógłbym łatwo stworzyć jQuery, gdybym tylko się do tego zabrał.
Oczywiście w rzeczywistości nie byłbym w stanie zrobić czegoś takiego – stwierdziłbym, że jest to nieznośnie trudne. Moje własne rozwiązania wydawałyby się zbyt proste i naiwne, aby zadziałały, więc bym się poddał. Zaliczyłbym jQuery do rzeczy oczywistych, w których prawidłowe działanie trzeba po prostu ślepo wierzyć. Następnie nie traciłbym czasu na zagłębianie się w mechanikę tej biblioteki, ale po prostu użyłbym jej jako swego rodzaju czarnej skrzynki.
Jednak lektura tej książki uczyniła mnie inną osobą. Zacząłem czytać kod źródłowy i odkryłem, że implementacja wielu rozwiązań była tak naprawdę bardzo przejrzysta, wręcz oczywista. Nie, oczywiście, samodzielne wymyślenie czegoś takiego to inna historia. Ale to studiowanie kodu innych osób i reprodukowanie istniejących rozwiązań pomaga nam wymyślić coś własnego.
Inspiracja, którą zyskasz i wzorce, które zaczniesz zauważać, zmienią Cię jako programistę. Przekonasz się, że ta wspaniała biblioteka, z której stale korzystasz i którą zwykłeś uważać za magiczny artefakt, w ogóle nie działa na magię, a po prostu rozwiązuje problem lakonicznie i pomysłowo.
Czasami trzeba będzie zagłębić się w kod, analizując go krok po kroku, ale w ten sposób małymi, konsekwentnymi krokami można powtórzyć drogę autora do rozwiązania. Pozwoli Ci to głębiej zagłębić się w proces kodowania i da Ci większą pewność w znajdowaniu własnych rozwiązań.
Kiedy po raz pierwszy zacząłem pracować z obietnicami, wydawało mi się to czystą magią. Potem dowiedziałem się, że bazują na tych samych wywołaniach zwrotnych i mój świat programowania wywrócił się do góry nogami. Zatem wzorzec, którego celem jest uchronienie nas przed wywołaniami zwrotnymi, sam jest implementowany przy użyciu wywołań zwrotnych?!
Pomogło mi to spojrzeć na sprawę innymi oczami i zdać sobie sprawę, że nie mam przed sobą jakiegoś zawiłego kodu, którego zaporowej złożoności nigdy w życiu nie pojmę. To tylko schematy, które można bez problemu zrozumieć przy należytej ciekawości i głębokim zanurzeniu. W ten sposób ludzie uczą się kodować i rozwijają jako programiści.
Wymyśl to koło na nowo
Więc śmiało wymyśl koła na nowo: napisz własny kod powiązania danych, stwórz własną obietnicę, a nawet stwórz własne rozwiązanie do zarządzania stanem.
Nie ma znaczenia, że nikt nigdy z tego wszystkiego nie skorzysta - ale teraz wiesz, jak to zrobić. A jeśli masz możliwość późniejszego wykorzystania takich rozwiązań we własnych projektach, to ogólnie jest świetnie. Będziesz mógł je rozwijać i uczyć się czegoś innego.
Nie chodzi tu o wysłanie kodu na produkcję, ale o nauczenie się czegoś nowego. Napisanie własnej implementacji istniejącego rozwiązania to świetny sposób na naukę od najlepszych programistów i tym samym doskonalenie swoich umiejętności.
Źródło: www.habr.com