Czarno-białe zdjęcie biurka, na którym leży laptop, zeszyt oraz kubek. Biurko stoi przy ścianie z cegły.

Wprowadzenie do serii – Powtórka przed ReactJS #0

Początki samodzielnej nauki programowania front-endowego bywają trudne. Od kilkunastu miesięcy, zgodnie z zaleceniami zmagamy się dzień w dzień z HTML, CSS i Javascript. Zbudowanie prostych aplikacji wymaga wielu godzin pracy. Gdy wkładasz w realizację projektów tyle wysiłku i zaangażowania, każde zwycięstwo jest powodem do dumy. Jednak, mimo ciągłych postępów, lista o nazwie ‚do opanowania’ zdaje się rozrastać w niebywałym tempie. Po pewnym czasie pojawia się znajome uczucie przytłoczenia, którego chcemy pozbyć się jak najszybciej. Pytamy ekspertów, jakie wymogi należy spełnić, aby móc zabrać się do działania. Co rzadko zdarza się w przypadku programistów, opinie są jednogłośne, a na szczycie każdej z list króluje dogłębne zrozumienie podstaw.

To, jak istotne jest załatanie luk w wiedzy na temat fundamentów, uświadomiłem sobie podczas kursu Harvard cs50: Introduction to Computer Programming. Zaczynałem kurs z myślą o tym, że kolejnym krokiem w moim planie nauki będzie zabranie się za Reacta. Myślałem, że wreszcie nadejdzie czas na ujarzmianie tego potężnego narzędzia. Ile można czekać na dołączenie do grona osób, które zachwycają się tą technologią na blogach i konferencjach? Jednak, kolejne tygodnie z cs50 dostarczały mi coraz więcej informacji na temat algorytmów, struktur danych i optymalizacji. Są to dziedziny, które rzadko trafiają na listy istotnych koncepcji do opanowania przez początkujących webowców. Nic bardziej mylnego. Kilka tygodni zabawy ze wskaźnikami w C odmieniło moje spojrzenie na dalszą naukę front-endu. Postanowiłem przeanalizować, czy poświęcenie jeszcze kilku miesięcy na gruntowną powtórkę informacji i zgłębienie tajników Javascript nie byłoby rozsądniejszą inwestycją niż rzucanie się w wir frameworkowego hype’u.

Zaczynając od najważniejszej z zalet takiej decyzji, znajomość języka pozwala na rozwiązywanie trudniejszych problemów. Tworząc bardziej rozbudowane aplikacje, natrafimy na funkcjonalności, których logika wymaga zastosowania bardziej złożonych konstrukcji niż wariacje pętli for wspomagane podstawowymi metodami. Tutaj na pomoc przychodzi dogłębne zrozumienie zasad programowania obiektowego oraz funkcyjnego, które znacznie poszerza nasze możliwości. Ponadto, w przypadku problemów z działaniem tworzonej aplikacji, znajomość mechaniki języka pozwala na szybsze naprawianie błędów. Jedną z największych zalet frameworków jest dodawanie dodatkowych warstw abstrakcji, które pozwalają na szybsze postępy przy budowie programu. Niewielka z tego korzyść, jeżeli większość zaoszczędzonego czasu poświęcimy na szukanie rozwiązań prostych problemów. Doliczając przerwy na uderzanie głową w ścianę z powodu narastającej frustracji, może się to naprawdę przełożyć na naszą produktywność.

Mając solidne podstawy, jesteśmy w stanie znacznie szybciej uczyć się kolejnych technologii. Będziemy zauważać cechy wspólne pomiędzy nimi, a wówczas opanowane nowości będą miały solidny fundament w naszym zrozumieniu kluczowych zasad. Zrozumienie fundamentalnych zasad niezależnych od technologii pozwala nam na zadawanie lepszych pytań, dzięki czemu otrzymamy lepsze odpowiedzi. Często mówi się, że w świecie programowania nie ma problemu, który nie został już rozwiązany. Większość z tych rozwiązań czeka na odkrycie w jakimś wątku na stackoverflow. Problem polega na tym, że jeżeli nie wiemy, jak sformułować nasz problem (chociażby przez brak zaplecza w zakresie pojęć programistycznych), możemy nigdy na taką odpowiedź nie natrafić.

O czym nie można zapomnieć, język zmienia się znacznie wolniej niż jakikolwiek oparty na nim framework. Ponadto czas życia frameworków jest zawsze krótszy niż czas życia języka. W książce „Antykruchość”, jeden z moich ulubionych pisarzy, Nicholas N. Taleb, doradzał, jak analizować czas życia fenomenu w warunkach niepewności. Najrozsądniejszą możliwością jest założenie, że znajdujemy się w samym środku tego okresu. Tak więc, skoro Javascript jest używany od 1995 roku to możemy się spodziewać, że będzie z nami przez kolejne 22 lata. Nawet jeżeli nie przemawia do Ciebie takie założenie, to wystarczy prosta metafora z dziedziny finansów. Inwestycja w naukę języka jest jak przeznaczanie swoich oszczędności na zakup nieruchomości pod wynajem. Cały proces jest dużo bardziej czasochłonny, ale w końcu wejdziemy posiadanie aktywa przynoszącego stabilny zysk przez lata. W przypadku frameworków wchodzimy na grunt spekulacyjnego inwestowania w akcje startupów. Oczywiście, drugi rodzaj inwestycji może przynieść znacznie większe zyski, jeżeli znajdziemy się w odpowiednim miejscu w odpowiednim czasie. Mimo wszystko, porównując skalę ryzyka, nietrudno domyślić się, co jest rozsądniejszym rozwiązaniem. Zwłaszcza na początku kariery.

Co do wad, musimy dołożyć jeszcze większą liczbę zagadnień do wspomnianej wcześniej listy ‚do opanowania’. Patrząc krótkoterminowo, wymaga to znacznie więcej wysiłku i wytrwałości. Aby otrzymać te same rezultaty co osoba, która wspomaga się narzędziami, będziemy musieli spędzić znacznie więcej godzin przy klawiaturze. Istotnym minusem jest ciągła walka z pokusą porzucenia tego nastawienia, którą dzień w dzień napędzają gorące dyskusje i zachwyty, na które można natrafić na blogach czy forach dyskusyjnych. Trzeba oswoić się z myślą, że omija nas coś niesamowitego, coś, co cały czas jest na wyciągnięcie ręki. Jeżeli sami zarządzamy swoim kształceniem, ciężko określić moment, w którym faktycznie opanowaliśmy podstawy. Łatwo wpaść w pułapkę wiecznego podważania tego, czy jesteśmy gotowi na kolejny duży krok na naszej ścieżce rozwoju.

Jak widać szala zdecydowanie przeważa się na rzecz metodycznego podejścia do nauki. Aby cały proces przebiegał sprawnie, postanowiłem przygotować solidny plan opracowania interesujących mnie zagadnień. Zaprojektowałem go w oparciu o metodę 10 kroków do opanowania umiejętności Johna Sonmeza. Jej zwięzły opis znajduje się w jednym z rozdziałów książki Sprawny programista. U podstaw tej metody leży zasada pareto. Chcemy opanować 20% wiedzy, która da nam 80% rezultatów. Postawiłem nacisk na te koncepcje, które dadzą największy zwrot w późniejszej nauce Reacta. Zagadnienia dobierałem w oparciu o rady udzielone przez ekspertów.  Ich lista wygląda następująco:

  1. Funkcje strzałkowe.

  2. Łańcuchy szablonowe.

  3. Destrukturyzacja.

  4. Operator spread, oraz parametry rest i default.

  5. Obietnice.

  6. Importowanie oraz eksportowanie modułów.

  7. Zakresy.

  8. Domknięcia.

  9. Słowo kluczowe this.

  10. Metody bind, call, apply.

  11. Funkcje wyższego rzędu.

  12. Rozwijanie funkcji.

  13. Programowanie funkcyjne: filter, map, reduce.

  14. Prototypy oraz dziedziczenie.

Skąd decyzja o rozpoczęciu serii od nowości z ES6? Większość materiałów, z których będę korzystał przy omawianiu drugiej części planu, jest oparta o starszą specyfikację, ES5. Będzie to świetna okazja do wykorzystania nabytej wiedzy poprzez odświeżanie przykładów.

Każdemu z wymienionych zagadnień poświęcę jeden wpis. Znajdzie się w nim opis teoretyczny, przykłady, omówienie dobrych praktyk, zadania do samodzielnego wykonania oraz linki do materiałów, które pozwolą na dalszą naukę.

Do zobaczenia za tydzień, zgodnie z rozkładem zaczniemy od arrow functions.

Marcin Czarkowski

Cześć! Ja nazywam się Marcin Czarkowski, a to jest AlgoSmart - blog, na którym dzielę się wiedzą o ReactJS oraz JavaScript. Tworzę poradniki na YouTube i jestem współtwórcą przeprogramowani.pl

  • Jerzy Wachniew

    Bardzo dobre podejście, życzę wytrwałości.

  • Krystian

    Z pewnością będę obserwował bloga, czekam z niecierpliwością na koleje wpisy.

  • Guy Diamond

    O Panie, z nieba mi Pan spadł 🙂
    Chwilę temu skończyłem książkę o podstawach JS. Trochę pisałem w JS, używając funkcji, pętli, łańcuchów, obiektów itp.
    Oczywiście sam dla siebie, dla nauki. Nadarzyła się okazja pracy w
    grupie. Prosta strona, którą zrobiłbym w trzy dni. Jednak prowadzący
    postanowili wymóg pisania w React. Pomyślałem no dobra, let’s rock!
    Dorwałem poradnik podstaw Reacta i dalej. Na start webpack, yarn (pierwszy raz używałem). React ruszył! Byłem wielki. Później eslint i github, który używałem, ale nie w pracy w zespole. Dodatkowo yaml z markdown.

    Pierwsze problemy z kodem i używanie wójka googla, który nie umiał odpowiadać na źle zadane pytania! Skandal, Google musi poprawić swoją wyszukiwarkę ;). Złość i frustacja. Przecież znam podstawy!

    Jednak nie, znam podstawy podstaw. Na 14 punktów, które wymieniłeś, opanowałem 4-5.
    Co prawda z pomocą kolegi jakoś sobie poradziłem, ale czułem jakbym
    błądził w ciemności. Często zadawałem sobie pytanie: ale właściwie, po
    co ten reactjs jest, w czym on ułatwia pracę? Dziś natrafiłem na twój blog z modułami i pojawił się płomyk w tej ciemności.

    Cieszę
    się, że nie zaczynasz od totalnych podstaw, bo to łatwy temat chętnie
    poruszany przez blogerów. Fajnie zaplanowałeś zagadnienia. Po nich
    znacznie lepiej będzie skoczyć w React.

    Wielkie dzięki!

    • Podobnie jak Ty czułem się tworząc pierwszy większy projekt w dużo łatwiejszym w obsłudze Vue. Stąd pomysł na tę serię przed rozpoczęciem prawdziwej zabawy z Reactem.

      Bardzo mi miło, że blog stanowi dla Ciebie źródło wartościowej wiedzy. Taki był plan :D.

      Pozdrawiam!