Na większości moich zajęć językowych w szkole nauczyciel skupiał się bardzo mocno na:

• czytaniu artykułów na różne tematy – rzadko na takie, którymi byłbym choć trochę zainteresowany,
• uczeniu się teorii gramatyki,
• robieniu ćwiczeń, żeby „ćwiczyć” w tak sztucznym środowisku, że bardziej sztucznie się nie dało.

Jeśli już dochodziło do konwersacji, to głównie z innymi uczniami – którzy byli na podobnym (zbyt niskim) poziomie znajomości języka obcego.

Większość korepetycji polegała na tym samym – znowu była to strata czasu, ale uczęszczanie na nie wystawiało przynajmniej na kontakt z językiem.

Moja droga w nauce języka

Języka zacząłem się uczyć w typowy sposób – język angielski w szkole państwowej ze szczyptą pomocy w domu, a potem ze wsparciem w postaci dodatkowych zajęć w szkole językowej. Miałem dobre oceny, ale praktycznie nie potrafiłem mówić.

Wszystko się zmieniło, kiedy zmieniłem szkołę językową na taką, gdzie uczono metodą bezpośrednią – skupioną na zachęcaniu uczniów do rozmawiania w czasie zajęć. Odblokowało to moją zdolność mówienia i po raz pierwszy miałem możliwość uczenia się, w jaki sposób używać elementów słownictwa i gramatyki w konwersacji.

Mniej więcej w tym samym czasie odkryłem program do powtarzania słówek – skuteczny sposób wkuwania słownictwa. Byłem tak zachwycony skutecznością nauki języka „po mojemu”, że zrobiłem z tego hobby, które trwało kilka dobrych lat. W tym czasie odstawiłem język angielski na bok i zacząłem się uczyć od zera francuskiego. Potem przeszedłem do niemieckiego – tym razem uzbrojony w szczerą chęć nauki. W okresie mojej „świetności” całkiem nieźle mówiłem po niemiecku i francusku, a stosowanie tych języków było istotnym elementem mojego życia towarzyskiego – mimo że mieszkałem w Krakowie.

Ostatnim językiem, do którego się przyłożyłem, był język hiszpański, po tym, jak wyjechałem do Hiszpanii. Mimo że nie byłem już wtedy zafascynowany nauką języków, zanurzenie w naturalnym środowisku języka i ludzie zachęcający do jego nauki bardzo mnie motywowały.

W jaki sposób uczyłbym się kolejnego języka teraz?

Tak więc nauczyłem się, jak uczyć się języków, na przykładzie angielskiego, a potem dopracowałem swoje metody, ucząc się francuskiego, niemieckiego i hiszpańskiego. Jak działałbym teraz, gdybym wrócił do uczenia się języków?

Kilka e-lekcji w tygodniu

Mamy obecnie dostęp do ogromnej liczby platform e-learningowych – na przykład italki – i możemy w rezultacie kontaktować się z rodzimymi użytkownikami języka, którego się uczymy, niezależnie od naszego miejsca zamieszkania. Chodziłbym na kilka zajęć w tygodniu. Gdybym musiał liczyć się z wydatkami, ograniczyłbym je do 30- lub 45-minutowych sesji, ale poumieszczałbym je w różne dni tygodnia, aby mieć regularny kontakt z językiem.

Wiem, że nie potrzebuję dużo wyjaśnień opartych na teorii, więc zdecydowałbym się na tańszych nauczycieli, którzy nie zajmują się nauczaniem zawodowo. Opcja ta byłaby nie tylko tańsza – dzięki niej uniknąłbym sytuacji, w których nauczyciel wnosiłby w moje lekcje nawyki nabyte w szkole, czego chciałbym uniknąć: na przykład tracenia czasu w ilościach sporych na omawianie subtelności gramatycznych. Chciałbym mieć opanowaną gramatykę – ale na poziomie intuicyjnym, a nie analitycznym.

Skup się na mówieniu

Moje lekcje skupiałyby się tylko na rozmawianiu. Pierwszymi frazami, których bym się nauczył, byłyby:

• „jak powiedzieć...?”
• „co to znaczy...?”

Dzięki temu mógłbym zacząć używać języka docelowego już od pierwszych zajęć.

O czym bym mówił? Przy odrobinie szczęścia miałbym z nauczycielem na tyle dużo wspólnego, że rozmowa sama by się kleiła. Jeśli nie, zawsze znalazłyby się tematy, na które mógłbym się wypowiedzieć:

• kim jestem,
• co robię,
• jakie mam plany na następny weekend,
• czym się ostatnio zajmowałem,
• aktualności, które dominują ostatnio wszystkie rozmowy – nie jakiekolwiek, ale te, o których nie da się nie mówić.

Są to dokładnie te rzeczy, o których się mówi, kiedy spotyka się obcokrajowca, z którym chce się porozmawiać lub z którym trzeba coś załatwić: ludzie, z którymi spędzasz czas na wakacjach, teściowie, ludzie, z którymi rozmawiasz na spotkaniach za granicą itd.

Notuj

Za każdym razem, gdy nauczyciel zwróciłby mi uwagę na nowe słówka czy wyrażenia, zapisywałbym je, żeby potem móc je powtarzać po godzinach. Kiedy intensywnie uczyłem się języka hiszpańskiego, miałem przyczepiony do ściany łańcuszek notatek, które starałem się czytać kilka razy dziennie. Same notatki przydawały się też podczas lekcji – jeśli ciągle zapominałem jakiegoś słowa, mogłem je po prostu znaleźć w swoich zapiskach.

Powtarzaj z innym nauczycielem

W idealnym świecie każda moja lekcja w tygodniu byłaby z innym nauczycielem. W ten sposób mógłbym nauczyć się nowych słówek dotyczących tematów poruszanych u jednego nauczyciela, a potem mógłbym je wykorzystać, opowiadając o tym samym drugiemu nauczycielowi. Oprócz tego istniałoby dużo mniejsze prawdopodobieństwo, że skończyłyby mi się tematy do rozmowy z kimś, kogo widzę tylko raz, a nie kilka razy w tygodniu.

Korzystaj z programów do nauki słownictwa

Powtarzanie w określonych odstępach czasu to świetny sposób na optymalizację nauki. Chodzi o powtarzanie słówek dokładnie w momencie, kiedy zaczynają zamazywać się w pamięci: z jednej strony dojdzie do ich zapamiętania, a z drugiej – nie będziesz spędzał nad nimi zbyt dużo czasu. Występują też papierowe wersje takich systemów, ale najskuteczniejszym sposobem jest zaprzęgnięcie do współpracy aplikacji, która zrobi wszystko za Ciebie. Przykłady programów:

• SuperMemo – płatny program, z którego często korzystałem podczas nauki języka angielskiego, francuskiego i niemieckiego,
• Anki – darmowy program na licencji open source, szczególnie przydatny, jeśli chcesz tworzyć własne listy słówek.

Obie aplikacje pytają o słówka, które powinieneś już znać, co pozwala na sprawdzenie swojej wiedzy, którą następnie oceniasz. Na podstawie tej oceny program umieszcza słówko w kalendarzu powtórek wcześniej, jeśli go nie pamiętałeś, albo później, jeśli je zapamiętałeś.

Co najbardziej spodobało mi się w SuperMemo:

• pliki audio dla wszystkich słówek i przykładowe zdania – mogłem je powtarzać ze słuchu, nie tracąc czasu na rozszyfrowywanie alfabetu fonetycznego,
• rozmiar baz danych – na wszystkich poziomach nauki aplikacja oferowała dziesiątki tysięcy słówek,
• powtarzanie w określonych odstępach czasu.

Niestety dla rzadszych języków dostępnych było mniej materiałów – na przykład do nauki języka angielskiego i francuskiego można wybierać z nieprzebranej bazy zasobów, ale nie ma już takiego luksusu w przypadku języka polskiego czy baskijskiego.

Jakie są Twoje wskazówki do nauki języków obcych?

Jak do tej pory szło Ci uczenie się języków? Masz jakieś wskazówki, którymi warto podzielić się z innymi czytelnikami? Czekam na nie w komentarzach!

• jeden z nich prowadzi firmę zajmującą się sprzedażą produktów online,
• drugi w zaledwie kilka lat przeszedł drogę od ukończenia bootcampu do wiodącego programisty.

Poniżej daję wam krótki poradnik na temat tego, jak poprawić teksty tworzone w ramach codziennych obowiązków zawodowych.

Rozbij swoje dzieło na akapity

Pierwszym krokiem na drodze doskonalenia umiejętności pisania jest rozbicie myśli na mniejsze kawałki. Zamiast zrzucać na czytelnika ogromną ścianę tekstu, rób nowe akapity, gdy zmienia się wiodąca myśl. Taki podział tekstu sprawi, że będzie on ekonomiczny, mniej przytłaczający i łatwiejszy w czytaniu. Dzięki mniejszym fragmentom czytelnik nie straci tyle energii na lekturze.

…i właśnie tak masz nie pisać.

Korzystaj z dostępnych opcji formatowania

Większość systemów, przez które będziesz wysyłać swoje wiadomości, będzie dawać możliwość formatowania tekstu. Najpewniej będą to:

• pogrubienia,
• kursywa,
• nagłówki,
• podkreślenia,
• przekreślenia.

Korzystanie z tych elementów szybko sprawi, że Twój tekst będzie bardziej przystępny. Dzięki temu w prosty sposób skierujesz uwagę czytelnika na najważniejsze rzeczy, co zwiększy szansę na osiągnięcie celu Twojego tekstu.

Diabeł tkwi w szczegółach.

Ułatw lekturę czytelnikowi

Życie swoim czytelnikom możesz ułatwić na dwa sposoby:

• korzystając z linków HTML,
• umieszczając w tekście obrazki, aby coś zakomunikować albo wyjaśnić.

Opcje te nie zawsze są dostępne. Kiedy na przykład używam Slacka, niezmiennie irytuje mnie, że nie mogę umieszczać obrazków między akapitami.

Dodatki tego typu znacznie poprawiają czytelność wysyłanego tekstu. Obrazki umieszczone w tekście widać od razu, a tekst nie jest przerywany przydługimi linkami.

Jest to kluczowe przy pracy z ticketami. Wyobraź sobie, że dodajesz do tekstu obrazek w Jira: wszystko będzie klarowne pod warunkiem, że obrazek jest jeden. Jeśli zespół doda kolejnych pięć obrazków w komentarzach, to wszystko stanie się nagle bardzo zagmatwane. Umieszczanie obrazków między fragmentami tekstu sprawia, że wiadomo od razu, który obrazek do czego się odnosi.

Internet oferuje linki od roku 1991, a obrazki od 1992. Używajmy ich!

Przeczytaj i zredaguj to, co napisałeś

Szczypta redakcji może bardzo poprawić jakość Twojego dzieła. Najlepiej zapisać szkic i wrócić do niego po pewnym czasie – po przerwie albo nawet następnego dnia. Przeczytanie całego tekstu przynajmniej raz przed publikacją powinno pozwolić Ci doszlifować sposób wyrażenia Twoich myśli, co poprawi ogólne wrażenia czytelnika.

Redakcja jest kluczem do dobrego odbioru tekstu. Zajmowanie się tym samemu powinno wystarczyć do większości pisanych przez Ciebie tekstów i jest jedną z podstawowych rzeczy, które jesteś winien swoim czytelnikom.

Ulepsz swój tekst za pomocą zautomatyzowanych narzędzi

Maszyna potrafi poprawić Twój tekst nie tylko poprzez sprawdzenie go pod kątem poprawności ortograficznej. W dzisiejszych czasach mamy dostęp do zaawansowanych narzędzi, które potrafią robić takie rzeczy jak:

• wyłapywanie wyrazów napisanych prawidłowo, ale umieszczonych w złych miejscach (w przypadku języka angielskiego zawsze mi się to zdarza z then i than),
• zaznaczanie strony biernej – pisanie w stronie czynnej „ożywia” tekst,
• przeredagowywanie zdań tak, aby były łatwiejsze w odbiorze – przynajmniej zdaniem algorytmu.

Jeśli do pisania podchodzisz poważnie, powinieneś zerknąć na aplikacje dostępne na rynku.

Grammarly

Jeśli na YouTubie pojawiają Ci się reklamy podobne do moich, na pewno słyszałeś o tym narzędziu. Korzystam z niego od lipca 2021 roku i jestem zadowolony. To był pierwszy postawiony przeze mnie krok na drodze do poprawienia jakości mojego bloga.

Plusy:

• rozumie kontekst wyrazów i sugeruje odpowiednie zmiany: podpowie Ci, czy chciałeś napisać it's czy its,
• zwraca uwagę na nadużywane wyrazy i sugeruje zamienniki,
• w wersji płatnej może zasugerować przeredagowanie zdania.

Minusy:

• obsługuje tylko język angielski,
• wtyczka dla Firefoxa na komputerach Mac ma problemy z Google Docs,
• płatna wersja kosztuje 144 $ rocznie, co jest kwotą wyższą niż u konkurencji,
• tu i ówdzie pojawiają się skargi na problemy z bezpieczeństwem i prywatnością. Z tego, co udało mi się sprawdzić, do największego naruszenia bezpieczeństwa doszło w 2018 roku i Grammarly szybko to naprawiło. Problemy związane z prywatnością mają związek z przetwarzaniem zachodzącym na serwerach firmy – korzystając z tego narzędzia, musisz zaufać, że stosuje się do swoich warunków świadczenia usług.

LanguageTool

Plusy:

• obsługuje większą liczbę języków (korekta gramatyczna 5 języków europejskich), podstawowe funkcje dla 20 języków,
• masz możliwość własnego hostingu darmowej wersji, dzięki czemu dane będą zawsze pod Twoją kontrolą.

Minusy:

• kiepski marketing – o asystencie LanguageTool dowiedziałem się dopiero wtedy, kiedy sam zasięgnąłem języka.

Bądź najlepszym przyjacielem swoich czytelników

Wszystkie podane wyżej wskazówki sprowadzają się do tego, żebyś myślał o osobach, które będą czytać Twój tekst. Twoim zadaniem jest sprawienie, żeby był on łatwy w odbiorze. Wymaga to empatii. Dodatkowy wysiłek powinien Ci się zwrócić: często zdarza się, że czytelnikami Twoich tekstów są: Twój szef albo ludzie, którzy mają wpływ na dalsze losy Twojej ścieżki zawodowej. Nawet jeśli piszesz coś dla kolegów z pracy, Twoje dzieło zostanie najpewniej przeczytane przez wiele par oczu – a reputacja osoby z dobrymi umiejętnościami komunikacji dobrze Ci zrobi.

Co dalej?

Jeśli podoba Ci się ten artykuł, subskrybuj, żeby być na bieżąco, kiedy opublikuję nowy.

Lepiej nie dopuszczać do takich sytuacji.

Zobaczmy zatem, jak rozwinąć umiejętność czytania dokumentacji.

Otwórz ją

Najważniejsza sprawa – jeśli masz jakiekolwiek trudności w pracy, zacznij od próby znalezienia odpowiedzi w dokumentacji. Największą zaletą takiego podejścia jest skuteczność: w wielu przypadkach w ten sposób znajdziesz potrzebne informacje. Musisz oddać się lekturze i nieco poszperać. Im dalej będziesz na swojej ścieżce zawodowej, tym więcej problemów będzie stawać Ci na drodze – nie ma gotowego przewodnika po wszystkich niuansach programowania.

Masz jakiś problem? I bardzo dobrze!

Większość dokumentacji jest zwykle rzeczowa do bólu, a ich zadaniem jest udzielenie odpowiedzi na ewentualne pytania – nie jest to porywająca lektura. Dużo łatwiej skupić się na niej, kiedy szukasz rozwiązania problemu.

Nie cierpię czytać dokumentacji tylko po to, żeby rozeznać się w projekcie. Nie ma znaczenia, czy chodzi o nowy projekt, czy o nieznaną mi bibliotekę. Mam wrażenie, że to strata czasu, bo nie mam kontekstu, na którym mógłbym się oprzeć, i trudno jest zrozumieć powiązania między rzeczami, o których czytam.

Wolę zrobić coś po swojemu, potknąć się i wrócić do dokumentacji z konkretnym pytaniem. W takim wypadku przynajmniej wiem, czego nie wiem, i jestem zmotywowany do uzupełnienia braków w wiedzy.

Skorzystaj z funkcji wyszukiwania

Aby szybko uzyskać informacje na temat tego, jak rozwiązać problem, na który się natknąłeś, skorzystaj z narzędzi do wyszukiwania.

W przypadku bibliotek zewnętrznych możesz wykorzystać wyszukiwarki, dzięki czemu ograniczysz wyszukiwanie do strony internetowej projektu: po prostu dodaj do wyszukiwanej frazy site:<domain>:

Funkcja ta działa w Google, Bing i DuckDuckGo.

W dokumentacji znajdującej się w kodzie możesz zastosować te same narzędzia, z których korzystasz do przeszukiwania bazy kodu:

• wyszukiwanie w edytorze,
• ripgrep,
• git grep.

Przykład na podstawie git grep:

$ git grep 'http\.post'
src/auto/injector.js: *          $http.post(trackingUrl, trackedEvents);
src/ng/http.js:     *   $http.post('/someUrl', data, config).then(successCallback, errorCallback);
src/ng/http.js:     * - {@link ng.$http#post $http.post}

Ręczne przeszukiwanie dokumentacji ma kilka zalet:

• możesz zapoznać się z jej strukturą,
• znajdziesz wszystkie fragmenty dokumentacji dotyczące Twojego problemu.

Dokumentacja API – suchy opis metod

Samouczek lub przewodnik dają większy kontekst.

Nie rozumiesz? Nic nie szkodzi!

Dokumentacja dokumentacji nierówna. Często nie są one łatwe w odbiorze. Ich twórcy mogą zakładać, że czytelnik posiada już pewną wiedzę o systemie, i nie wszystko będzie wprost opisane. Przez takie sytuacje nowi członkowie zespołu mogą czuć się zbici z tropu.

Najbardziej problematyczne okazują się projekty komercyjne closed source. Jeśli za utrzymywanie bazy kodu i jej dokumentacji odpowiada niewielki zespół, mogą minąć miesiące, zanim przeczyta go nowa para oczu, próbując rozeznać się w tym wszystkim.

Projekty open source są zwykle „łatwiejsze w obsłudze”. Te bez dobrej dokumentacji mają mniejsze szanse na sukces.

Dobry przewodnik nie jest zły

Jeśli w projekcie dostępny jest samouczek albo przewodnik, dobrze jest z niego skorzystać. Jeśli często borykasz się z podobnym problemem, znajdź dotyczący go fragment i po prostu go przeczytaj. Dobrze zrobiony przewodnik da Ci kontekst potrzebny do pełnego zrozumienia wykorzystywanego mechanizmu.

Zanurz się w odpowiedniej części API

Opis API to najbardziej techniczna z dokumentacji. Jest zwykle rzeczowa i brakuje jej opisów kontekstów, w których możesz zastosować konkretną metodę. Przedstawia wszystkie klasy, metody, argumenty i dane wyjściowe będące na Twoim podorędziu.

Jeżeli opis ten jest dostępny, zapoznaj się z różnymi fragmentami dotyczącymi tych samych lub podobnych rzeczy. Często jest tak, że rozwiązanie polega na odesłaniu do innej metody – więc jeśli nadal nic nie wiesz po przeczytaniu jakiegoś fragmentu, sprawdź, czy opis innych metod nie będzie bardziej przydatny.

Wyniki

W przypadku metod będziesz spotykał się albo ze zmianą stanu wewnętrznego obiektu, albo z danymi wyjściowymi. Przewodnik po API powinien dobrze opisywać oba te przypadki.

Zmiana danych wejściowych

Często zdarza się, że metody akceptują dane wejściowe w wielu kombinacjach argumentów. Dokumentacja opisze Ci pełen wachlarz możliwości wprowadzenia wszystkiego, czego potrzebujesz.

Podsumowanie

Czytanie dokumentacji jest istotną umiejętnością, której można się nauczyć tylko przez praktykę. Nie zniechęcaj się, jeśli na początku będzie Ci szło opornie; z czasem będziesz sobie radził coraz lepiej.

Chcesz wiedzieć więcej?

Przeczytaj o tym, jak zajść daleko, stawiając małe kroki.

Czym są testy jednostkowe

Testy pozwalają na ustalenie wyraźnych oczekiwań w stosunku do kodu. Dają Ci możliwość maszynowego sprawdzenia, czy Twój kod spełnia te oczekiwania.

Jest to program, który weryfikuje Twój program.

W przypadku projektów opartych na JavaScript będziesz zwykle korzystał z biblioteki testującej takiej jak:

• Jest,
• Jasmine,
• Chai.

Są to jednak tylko narzędzia. Najważniejsze, żebyś miał na podorędziu coś, co w sposób automatyczny zweryfikuje Twoją aplikację.

Jak testy jednostkowe mogą Ci pomóc

Pisanie testów ułatwi Ci życie na cztery sposoby:

1. Jest to szybki i sprawdzony sposób na sprawdzenie, czy kod działa, jak należy. Nie musisz myśleć o przypadkach brzegowych, zajmą się nimi testy jednostkowe.
2. Dobre pokrycie kodu to zawór bezpieczeństwa, który pozwala na nieco śmielszą refaktoryzację kodu. Zwiększysz w ten sposób prawdopodobieństwo tego, że Twoja baza kodu będzie znajdować się w niezmiennie dobrym stanie.
3. Pisanie testów jednostkowych zmusza Cię do myślenia o jednostkach i o tym, jak rozdzielić między nie odpowiedzialność: w rezultacie Twój kod stanie się modułowy i łatwiej będzie go utrzymać.
4. Testy jednostkowe zrobią z Ciebie szybszego programistę. Najpierw będziesz musiał zainwestować czas na stworzenie przypadku testowego – pozwoli Ci to jednak potem na bezwysiłkowe uruchamianie go raz za razem. Inwestycja przyniesie Ci dywidendy już we wstępnej fazie programowania.

Zbuduj strukturę

Zanim zabierzesz się za testowanie funkcjonalności, upewnij się, że możesz przetestować cokolwiek. Zainstaluj bibliotekę testującą i skonfiguruj testujący skrypt. Kiedy będziesz już coś miał, zacznij tworzyć rusztowanie pod niektóre z Twoich testów. Musisz przyjąć konwencję nazewnictwa. Jeśli na przykład Twój kod znajduje się w: my-project/plane-ticket.js, nazwą Twojego kodu testującego może być: my-project/plane-ticket.spec.js.

Zbuduj wszystko, co potrzebne do przetestowania danej klasy, a potem posprawdzaj podstawowe elementy:

• czy obiekt jest obiektem;
• czy funkcja jest funkcją.

Dzięki temu dowiedziesz swoich umiejętności testowania.

Stwórz atrapy

Atrapa (mock) to obiekt tworzony w celu zastąpienia zależności jednostki, którą testujesz. Jeżeli na przykład testujesz funkcję saveBlogPost, będzie Ci zależeć na przejęciu żądania HTTP, zanim zostanie ono wysłane przez funkcję. Będziesz chciał się dowiedzieć, przy pomocy czego Twoja funkcja wysyła żądanie, i zastąpić to atrapą. Korzystanie z atrap powinno być proste, jeżeli budujesz kod, korzystając ze wstrzykiwania zależności.

Utrzymuj porządek

Jak widzisz, w każdym teście dużo się dzieje. Możemy wyodrębnić trzy fazy całego procesu:

1. tworzenie atrap;
2. uruchamianie kodu do sprawdzenia;
3. sprawdzanie oczekiwań.

Zachowanie tego podziału w kodzie ma sens: dzięki temu łatwiej będzie go czytać. Prostym sposobem na jego organizację jest zebranie wszystkich linii razem i dodanie komentarza określającego, jaka to część kodu.

Programuj w oparciu o testy – test-driven development

Programowanie oparte na testach to często spotykane podejście pozwalające na tworzenie schludnie wyglądającego kodu z dobrym pokryciem testami. Zaczynasz od dodania testu do funkcji, zanim zostanie ona wprowadzona. Uruchamiasz testy, które powinny dać wynik negatywny – jeśli tak się nie stanie, będzie to oznaczać, że coś jest bardzo nie tak: Twoim zadaniem będzie zbadać co. Natomiast po uzyskaniu w teście wyniku negatywnego dodaj do kodu brakującą implementację. Zgodnie z założeniami problem zostanie naprawiony. Jeśli wszystko pójdzie zgodnie z planem, będzie to inwestycja w ulepszenie Twojego rozwiązania – zarówno po stronie kodu, jak i testu – bez zmieniania logiki. Pozwoli Ci to na szybką iterację procesu budowania kodu i tworzenia do niego testów.

Praktykowanie takiego podejścia powinno zagwarantować regularne pisanie testów do logiki. W tej sytuacji nie odczuwacz pokusy, żeby ominąć krok obejmujący pisanie testów – a dzieje się tak często, kiedy przesuwasz ich tworzenie na koniec sprintu.

Wyjątki od reguły

Aby gdzieś dotrzeć, musisz wiedzieć, dokąd idziesz. Jeżeli chcesz rozeznać się w tym, jakie rozwiązania są wykonalne, daj sobie na chwilę spokój z testami. Po rekonesansie albo je dodaj, albo podejdź do problemu jeszcze raz, tym razem opierając się na testach.

Brakujące testy

Możesz mieć pecha i pracować na przestarzałym kodzie bez testów i innych środków kontroli jakości – czyli na przykład na czymś takim. W takim wypadku lepiej zastosować się do powiedzenia „lepiej późno niż wcale”: pracując nad bazą kodu, pisz jednocześnie testy. Idąc tą drogą, poprawisz sytuację na przyszłość, a może nawet znajdziesz podstępny bug ukryty gdzieś na rubieżach przypadków brzegowych.

A co z Tobą?

Jak trudna jest dla Ciebie nauka testowania? W Internecie można spotkać się ze skargami ludzi, którzy mają problemy ze znalezieniem dobrych materiałów dydaktycznych. Daj mi znać, jak to dotychczas wyglądało u Ciebie.

Trzymaj się tego, co umiesz najlepiej

Perspektywa upieczenia dwóch pieczeni na jednym ogniu poprzez naukę lub ćwiczenie nowej technologii podczas starania się o pracę jest kusząca. Na pewno swego czasu dla mnie taka była. Ale to nie w taki sposób dojdziesz do kodu najlepszej jakości. Lepiej wyjdziesz na trzymaniu się tego, co znasz najlepiej, i uczeniu się nowych rzeczy przy okazji pracy nad odrębnymi projektami.

Dobrze wiesz, która opcja dostanie lepszą ofertę.

Łatwość weryfikacji

Zrób tak, żeby Twoja praca była łatwa do sprawdzenia. Z punktu widzenia rekrutera idealny proces weryfikacji wygląda następująco:

• otrzymanie działającego linku;
• zobaczenie na własne oczy, że aplikacja działa, jak trzeba;
• zagłębienie się w kod, aby zobaczyć, jak udało Ci się to uzyskać.

Weryfikacja kodu bez wiedzy o tym, czy działa, wydaje się pozbawiona sensu. Jeżeli kod nie będzie działał prawidłowo, to, jak on wygląda, nie będzie miało większego znaczenia. Jeśli natomiast sprawdzenie, czy kod działa, będzie problematyczne, może to zniechęcić do zagłębienia się w Twoją pracę.

Podaj im wszystko na tacy

Zrób coś interaktywnego

Gdy mamy do czynienia z frontendową aplikacją, najprostszym rozwiązaniem będzie wdrożenie jej na darmowy serwer:

• strony GitHub,
• strony GitLab,
• lub Netlify.

Zapomnij o wysyłaniu plików ZIP

Przesyłanie plików ZIP jest obarczone dwiema wadami, przez które możesz odpaść już w przedbiegach:

• niewygodne rozwiązanie,
• otwieranie pliku ZIP stanowi zagrożenie dla bezpieczeństwa.

Ciekawe, co jest w środku!

Upewnij się, że wszystko działa

I że działa na różnych przeglądarkach i urządzeniach. Nie musi być piękne, ale musi działać – niezależnie od tego, czy weryfikator siedzi przed komputerem, czy trzyma w ręku smartfon.

Dodaj README.md

Każdy typowy projekt potrzebuje pliku README, a zadanie rekrutacyjne potrzebuje go tym bardziej. Powinieneś pokrótce przedstawić zadanie, które wykonujesz, i dodać link do działającej aplikacji. Potem możesz dodać dokumentację podsumowującą – opis frameworka, z którego skorzystałeś, oraz przedstawienie, w jaki sposób zbudować czy przetestować Twój kod.

Przedstaw swój sposób myślenia

Przedstaw weryfikatorowi swój sposób rozumowania. Jeżeli korzystasz z pewnych wzorców czy dobrych praktyk, wyraźnie się do nich odnieś w dokumentacji. Jeśli w pewnym miejscu pójdziesz na kompromis, opisz go i wyjaśnij, dlaczego postąpiłeś tak, a nie inaczej.

Niech się błyszczy

Aby się czymś wyróżnić, możesz dodać do swojego zadania któryś z elementów przedstawionych poniżej. Będzie to nieco wykraczać poza to, co miałeś wykonać, ale pokaże, że dobrze poruszasz się po zadaniach, które będziesz wykonywał w pracy każdego dnia.

Niech będzie ciekawie

Dodaj do swojego projektu kilka ścieżek. Uwagę weryfikatora na swoim zadaniu utrzymasz dłużej poprzez dodanie kilku dodatkowych stron. Może krótkie /about, żeby łatwiej mu było powiązać aplikację demonstracyjną z Twoim CV?

Test jednostkowy

Konfiguracja testów jednostkowych może być świetnym elementem, na którego przykładzie pochwalisz się swoim skupieniem na jakości. Nie musisz objąć testem całego kodu: kilka testów pokazujących, że wiesz, o co chodzi, powinno wystarczyć.

Skonfiguruj Lint i Prettier

Wiele profesjonalnych zespołów ujednolica swój styl programowania za pomocą automatycznych narzędzi. W przypadku front-endu będą to najpewniej ESLint & Prettier. Zrobienie tego samego w zadaniu rekrutacyjnym będzie miłym akcentem – jeśli w zespole znajdują się programiści, którym zależy na spójności, z pewnością to docenią.

Wprowadzaj rewizje, które coś wnoszą

Git (albo, ogólniej rzecz biorąc, kontrola wersji) jest w branży IT narzędziem kluczowym do pracy zespołowej. Zespół wykorzystuje we współpracy repozytorium Git, więc dobre komunikaty o rewizjach są nieodzowne. Jeśli stworzysz historię rewizji sensowną dla zadania rekrutacyjnego, bardzo ładnie pokaże to, jak będzie wyglądać Twój wkład w projekt firmy.

A co z Tobą?

Jakim najlepszym projektem demo możesz się pochwalić? Prześlij link w komentarzach!

• przyjaźnie nastawiony kolega z pracy z większym doświadczeniem,
• uczynny znajomy,
• mentor z zewnątrz – za którego usługi trzeba płacić (albo i nie).

Co zrobić, żeby wycisnąć z takiej pomocy jak najwięcej?

Senior JS developer

Dziel się problemami z życia wziętymi

Twój mentor ma dużo większe doświadczenie „w terenie” niż Ty. Może się nim z Tobą podzielić – o ile powiesz mu o swoich trudnościach. Na przykład:

• jeśli masz przed sobą wyzwanie techniczne, może Ci polecić alternatywne rozwiązania;
• jeśli nie zgadzasz się ze współpracownikiem, może ocenić sytuację i nakierować Cię na lepsze rozwiązanie podobnego sporu w przyszłości;
• jeśli jesteś przytłoczony liczbą dostępnych bibliotek, może Ci pomóc w wyborze i skupieniu się na jednej z nich;
• jeśli Twoja sytuacja zawodowa ma się nie najlepiej, może pomóc Ci w przygotowaniu się do rozmowy o podwyżce lub w szukaniu nowej pracy. W tym wypadku lepiej by było, gdyby mentor nie pracował w firmie, w której aktualnie pracujesz.

Bądź dobrym uczniem

Mentoring jest przyjemny, o ile Ty – uczeń – jesteś otwarty na naukę. Zwracaj uwagę na zalecenia swojego mentora. Jeśli poleci Ci artykuł, przeczytaj go; jeśli zarekomenduje książkę, zdobądź ją i przeczytaj; jeżeli będzie wychwalał kurs, kup go i ukończ. Jeśli dostaniesz informacje zwrotne z weryfikacji kodu, przynajmniej zareaguj na jego propozycje: omów ich zalety i wady, nawet jeśli nie wykorzystasz ich akurat w tej konkretnej sytuacji.

Traktuj mentora tak, jak traktowałbyś sowę.

Ucz się... podczas nauki

Jeżeli Twoja praca nie stanowi źródła problemów programistycznych, stwórz je sobie sam. Możesz poprosić mentora o weryfikację Twojego kodu w ramach pracy nad własnym projektem. Najlepiej byłoby, gdyby taki projekt był ogólnodostępny. Workflow mógłby wyglądać tak:

1. Robisz pierwszą wersję sam.
2. Mentor daje Ci wskazówki.
3. Wprowadzasz zmiany na ich podstawie.

Jawna praca nad własnym projektem pokazuje potencjalnemu pracodawcy trzy ważne rzeczy:

• jesteś wystarczająco zmobilizowany do dostarczenia projektu;
• masz pomoc z zewnątrz i Twój rozwój nie będzie opierał się wyłącznie na zasobach pracodawcy;
• pokazujesz, jak dobrze znosisz krytykę i jak wykorzystujesz informacje zwrotne.

A Ty?

Jakie są Twoje doświadczenia z mentoringiem? Daj znać w komentarzach!

Pracuje się szybko

Klawiatura to najszybsze i najdokładniejsze urządzenie do wprowadzania danych do komputera. Każdy palec ma w zasięgu kilka klawiszy i nawet przeciętny użytkownik potrafi wystukać od dwóch do trzech liter na sekundę. W porównaniu z tym mysz wypada słabo – ma tylko kilka klawiszy, rolkę i osie x i y. Nadaje się wyłącznie do wyboru opcji widocznych na ekranie, które zostały określone wcześniej. A między kliknięciami zawsze będzie kilkusekundowa przerwa.

Ze względu na te wady większość aplikacji graficznych zawiera skróty klawiszowe. Wydajne korzystanie z komputera wymaga nauczenia się wielu z nich na pamięć; patrzenie, jak ktoś kopiuje i przekleja pliki ręcznie, bez korzystania ze skrótów systemowych, zakrawa w dzisiejszych czasach o torturę. Większość GUI nie jest jednak dobra w uczeniu użytkownika skrótów klawiszowych – to często na jego barkach spoczywa ciężar szukania skrótów klawiaturowych dla opcji, z których korzysta najczęściej.

W przypadku CLI wszystko natomiast opiera się na tekście. Niektóre aplikacje uruchamia się w jednym długim wierszu poleceń, np. Git, grep, sed itd. Inne z kolei otwiera się w interfejsie tekstowym, gdzie obsługiwane są przy pomocy skrótów klawiszowych – na przykład Vim czy Emacs.

Zarządzanie złożonością

Program tekstowy obsługuje dowolną liczbę parametrów, ale wystarczy, że znasz te, które są Ci potrzebne. Zastanawiałeś się kiedyś nad tym, jak dużo takich parametrów posiada przeglądarka internetowa Chromium? Ponad 1000 (źródło). Siedzą sobie tam i czekają, aż ich użyjesz. Są one jednak zazwyczaj niewidoczne – chyba że zaczniesz wczytywać się w dokumentację.

Takie bogactwo możliwości jest nieosiągalne dla aplikacji opartych na GUI. Rzadziej stosowane opcje albo zaśmiecają ekran, albo kryją się w ogromnych, wielowarstwowych menu. W rezultacie dostajemy:

• proste programy dla prostych przypadków użycia z przystępnym interfejsem albo
• profesjonalne programy z przytłaczającymi interfejsami, gdzie trudno o doszukanie się nawet najprostszych z opcji.

Skrypty

Programy tekstowe przyjmują tekst jako dane wejściowe i dane wyjściowe oddają również w postaci tekstu. Na poziomie dane wejściowe/wyjściowe wszystkie programy CLI są kompatybilne: przy pomocy git ls-files możesz wyświetlić wszystkie pliki w swoim repozytorium, a następnie zastosować grep, aby je przefiltrować – wystarczy Ci do tego operator potoku:

$ git ls-files | grep index
home-page/index.html
registration/index.html
index.js

Operator potoku daje Ci dostęp do supermocy obliczeniowych, do których świat graficzny dostępu nie ma i nigdy mieć nie będzie. Działania takie jak:

• tworzenie tysięcy folderów czy
• wyszukiwanie wszystkich plików pasujących do wzoru lub zawierających taki wzór i wykonywanie na nich wszystkich operacji

są całkiem proste i wymagają nieco pobuszowania w sieci, przeczytania dokumentacji i zastosowania metody prób i błędów.

Interfejs użytkownika

Z tych powodów wiersz poleceń stanowi w wielu programach główny interfejs. Jako użytkownik jesteś więc niemalże zmuszony do jego stosowania. Najlepszym przykładem będzie tu Git: można dostać do niego jakieś GUI, ale korzystanie z nich tworzy jeszcze jeden poziom abstrakcji nad danymi, którymi zarządzasz. Jeśli z Gita korzystasz codziennie, nauka jego CLI da Ci bardzo dużo. Moim zdaniem GUI pozwala Ci na osiągnięcie 80% swoich celów, ale możesz też natknąć się na jeden z tych dziwniejszych przypadków, którym będziesz mógł się zająć wyłącznie przy pomocy wiersza poleceń.

A co z Tobą?

Jakie masz doświadczenia z CLI? Jakich rzeczy chciałbyś się w ich zakresie nauczyć? Daj mi znać w komentarzach!

Iteracja

Niewielkie posunięcia, które nie wymykają się spod kontroli, są podstawą wielu metodologii popularnych w naszej branży, na przykład:

• Agile – opiera się całkowicie na nieustannym wprowadzaniu zmian w produkcie w celu odkrycia potrzeb klienta,
• produkt o kluczowej funkcjonalności (ang. minimum viable product – MVP) – zakłada wydanie pierwszej funkcjonalnej wersji produktu, aby umożliwić sprawdzenie jej przez rynek, a następnie wprowadzanie kolejnych zmian.

Zobaczmy, jak wykorzystać podobne podejście w życiu codziennym.

W nauce

Najlepszym pomysłem byłoby:

• nauczenie się części materiału, a następnie
• zastosowanie go w praktyce.

W dobrym kursie lub w dobrej książce będziesz regularnie dostawał wyzwania, które pozwolą Ci sprawdzić Twoje postępy. Jeśli uczysz się bez takich luksusów, tego rodzaju zadania będziesz musiał tworzyć sobie sam. W obu przypadkach najlepszą informacją zwrotną będzie to, czy Twój kod działa, jak należy – więc powinieneś albo wykorzystać to, czego uczysz się przy swoim dodatkowym projekcie, albo zacząć nowy.

W pracy nad ticketem

Czy często zdarza Ci się utknąć nad ticketem? Możliwe, że próbujesz robić zbyt wiele rzeczy naraz. Poszczególne zadania można zwykle podzielić na kilka części:

• refaktoryzacja kodu, nad którym masz zacząć pracować,
• dodanie infrastruktury kodu – helperów, różnych rodzajów aktualizacji itd.,
• wprowadzanie zmian w logice aplikacji,
• dodanie testów integracyjnych do nowej funkcji.

W większości przypadków warto zrobić osobną rewizję z każdą z tych zmian: nie ma sensu weryfikować lub cofać refaktoryzacji razem z implementacją zmian w logice. Podział na osobne rewizje, a nawet propozycje zmian pozwalają na szybszą weryfikację kodu, co przyspieszy Twoje postępy.

A co jeśli nie jesteś zaznajomiony z kodem wystarczająco dobrze, aby zaplanować działania z wyprzedzeniem, albo po prostu zapomniałeś i wprowadziłeś wszystkie zmiany jednocześnie? Nie martw się: wiedza, którą zdobyłeś przy pierwszej próbie, nie pójdzie na marne – daj sobie chwilę oddechu, zacznij nową gałąź i zastosuj lub przerób część tej dużej rewizji, nad którą zacząłeś pracować.

W pracy nad projektami

Niezależnie od tego, czy pracujesz w projektach komercyjnych, czy open source – wszędzie usłyszysz to samo:

• „wydawaj szybko, wydawaj często”,
• „działaj szybko i popełniaj błędy”.

Możesz to zastosować nawet w pracy nad swoim osobistym projektem do nauki. Zamiast planować dużą, końcową wersję produktu, spróbuj jak najbardziej uprościć to, co budujesz. Kilka rad w tej kwestii znajdziesz w moim artykule na temat tego, jak uczyć się podczas pracy nad własnymi projektami.

Unikaj utykania nad problemem

Twoim głównym celem w pracy na podstawie iteracji jest unikanie utknięcia z problemem. Dobrze jest przeznaczyć czas na zbadanie nowego tematu; jako programista musisz być odporny na frustrację wynikającą z niewiedzy na temat tego, jak coś działa albo jak naprawić bug. Odporność ta jednak jest jak miecz obosieczny i może zwrócić się przeciwko Tobie. Korzyści ze zgłębiania tematu będą coraz mniejsze, aż w końcu takie dokształcanie się stanie się zwyczajnym marnotrawstwem czasu. A kiedy do tego dojdzie, będziesz już dobrze obeznany w temacie i na dobrej drodze do naprawienia problemu, a co za tym idzie – niełatwo będzie Ci odpuścić. Zobaczmy, jak uniknąć takich pułapek!

Nie jesteś sam

Najczęściej nie pracujesz sam: w Twoim środowisku znajdują się ludzie, którzy mogą Ci pomóc. Jako początkujący programista możesz tu popełnić błąd w dwojaki sposób:

• poprosić o pomoc zbyt szybko,
• poprosić o pomoc zbyt późno.

Co to znaczy „zbyt szybko”, a co „zbyt późno”? To zależy od sytuacji Twojego zespołu. Na myśl od razu przychodzą mi dwie sytuacje:

• zespół pracuje pod dużą presją – trzeba zażegnać kryzys, więc żaden bardziej doświadczony programista nie ma czasu, żeby Ci pomóc;
• przejmujesz projekt po programiście, który kończy pracę za dwa tygodnie, więc Twoim głównym zadaniem jest uzyskanie od niego jak najwięcej informacji.

Radzę określić w zespole konkretne zasady, a potem się ich trzymać. Jeżeli ustalicie, że cztery godziny walki z ticketem bez żadnych rezultatów to za dużo, to po bezskutecznym upływie tych czterech godzin poproś o pomoc.

Czasem lepiej odpuścić

Pomysł nie stanie się nagle lepszy tylko dlatego, że przeznaczyłeś na jego wprowadzenie bardzo dużo czasu. Wręcz przeciwnie: takim działaniem tylko pokażesz, że nie jest wykonalny albo że nie jest tak prosty, jak zakładałeś. Miej świadomość efektu utopionych kosztów – najlepiej będzie z wyprzedzeniem określić czas, jaki chcesz przeznaczyć na zadanie, zanim odpuścisz jego realizację, a następnie porzucić zadanie, jeśli zajmie Ci ono więcej czasu, niż chciałeś na nie przeznaczyć. Odpuszczenie ticketu w zależności od jego rodzaju może znaczyć pozostawienie go innemu programiście lub całkowite zaniechanie pracy nad nim, przynajmniej w danym momencie.

Wypatruj informacji zwrotnej w każdej sytuacji

Każdy etap interakcji jest momentem, w którym możemy – i powinniśmy – uzyskać feedback. Dzięki niemu wprowadzimy potrzebne korekty i upewnimy się, że zmierzamy w dobrą stronę. Istnieje bardzo dużo rodzajów informacji zwrotnej, na które można zwrócić uwagę:

• testy automatyczne wykonywane lokalnie lub w ramach CI,
• weryfikacja kodu przez bardziej doświadczonego kolegę po fachu lub mentora,
• zebranie informacji zwrotnej po prezentacji produktu na zewnątrz.

Chcesz dowiedzieć się więcej? Przeczytaj artykuł o pętlach informacji zwrotnej.

• uczenie się,
• zbudowanie działającej aplikacji,
• zarabianie pieniędzy,

to masz do czynienia z systemem kontroli, który trywialny nie jest. Spójrzmy wobec tego na najważniejsze cechy skutecznej pętli informacji zwrotnej i zastanówmy się, jak mógłbyś ją wykorzystać w swojej karierze programistycznej.

Im szybciej, tym lepiej

Im szybciej dowiesz się, czy wszystko idzie zgodnie z planem, tym lepiej. Posuwanie się do przodu po omacku nic Ci nie da. Jeśli jesteś na dobrej drodze, informacja zwrotna zmotywuje Cię do dalszego działania. Jeśli natomiast robisz coś źle, uzyskany feedback pozwoli Ci to zmienić. Wyobraź sobie, jak skomplikowana byłaby jazda na rowerze, gdyby sygnał z Twoich oczu dochodził do mózgu z choćby milisekundowym opóźnieniem: prowadziłbyś rower, jakbyś był pijany.

W zależności od złożoności systemu podejmowanie działań na podstawie uzyskanej wiedzy wymaga czasu. Jeśli dowiesz się, że Twoja aktualna ścieżka zawodowa nie jest dla Ciebie, nadal będziesz musiał przeznaczyć kilka lat na nauczenie się nowego fachu. Ale zdecydowanie wolałbyś zdobyć tę informację na pierwszym semestrze studiów, a nie po ich ukończeniu.

Codzienne pętle informacji zwrotnej

Spróbujmy zebrać w jednym miejscu wszystkie pętle informacji zwrotnej, z którymi stykasz się codziennie jako programista.

Zmiany w kodzie

Praca nad kodem wymaga sprawdzania wpływu wprowadzanych zmian na jego zachowanie. Testy automatyczne są szybkim i dobrym sposobem na pozyskiwanie informacji zwrotnej. Pisanie ich wymaga na początku nakładu czasu, ale jednocześnie zwiększa Twoją produktywność, nie mówiąc już o ich długofalowym wpływie na jakość, jeśli stosowane są regularnie.

Gdy mam przed sobą logikę, która jest skomplikowana, lubię zaczynać pracę od napisania testów. Zrozumienie wszystkich szczegółów projektu jest trudne i wolę zrobić to podczas tworzenia testów, a nie za każdym razem, kiedy wprowadzam w kodzie zmiany.

Codzienna praca nad ticketem

Jeśli działasz w dobrze zorganizowanym zespole, ktoś będzie weryfikować Twoją pracę. Jest to świetny sposób na to, żeby się dowiedzieć, w jaki sposób zespół wykonuje swoje zadania, a także dokształcić się z programowania. Praca nad ticketem przez dzień czy dwa tylko po to, aby dostać ponad 40 propozycji zmian naraz, może być frustrująca.

Aby temu zapobiec, możesz podzielić swoją pracę na kilka mniejszych etapów i prosić o informacje zwrotne po zakończeniu każdego z nich:

1. Po przeczytaniu ticketu przekaż jego treść swoimi słowami osobie, która rozumie, czego on dotyczy. Jeśli czegoś nie zrozumiałeś, będzie ona mogła skorygować Twój sposób myślenia.
2. Napisz plan rozwiązania problemu – i daj go innemu programiście do weryfikacji, zanim przeznaczysz czas na jego wdrożenie. Możliwe, że zwróci Ci uwagę na coś, co Ci umknęło.
3. Najważniejsza jest jednak informacja zwrotna dotycząca logiki programu. Poproś o weryfikację kodu, kiedy jeszcze aktualizujesz testy.

Wersja aplikacji

W miarę jak sprint posuwa się do przodu, rośnie zbiór zmian czekających na dostarczenie. Czekanie w takiej sytuacji miałoby sens tylko wtedy, gdybyś w tym czasie robił coś konstruktywnego, na przykład realizował złożony protokół testowania aplikacji. Jeśli jednak nie są wykonywane żadne sensowne testy, to tylko opóźniasz moment, w którym zaczniesz dostawać feedback od użytkowników. Zamiast tego proces wdrażania staraj się przeprowadzać jak najczęściej. Dzięki temu unikniesz wydania jednego dużego release’u zawierającego wszystkie zmiany (i bugi) wprowadzone przez Twój zespół przez całe kilka tygodni sprintu – zamiast tego będziesz wydawał zmiany po trochu, co kilka dni.

Dopasowanie produktu do rynku

Aspekt ten znajduje zastosowanie nawet na szerszą skalę. Metody takie jak Agile czy Lean Startup wskazują, że najlepiej jest wydać produkt jak najszybciej, co pozwoli na zebranie feedbacku od klientów.

Co z jakością informacji zwrotnej?

Nie każda informacja zwrotna ma taką samą wartość. Wszystko dzieje się na pewnym kontinuum – od dokładnych wyników testów do subiektywnej opinii osoby udzielającej informacji zwrotnej. W przypadku informacji obiektywnych, takich jak:

• negatywny wynik testu lub nieprawidłowe działanie funkcji,
• zbyt wolne działanie aplikacji,
• przyjmowanie nieoczekiwanych wartości przez inne wskaźniki wydajności,

dobrze jest natychmiast rozpocząć proces naprawy.

Natomiast w przypadku opinii subiektywnych, które mogą dotyczyć:

• podejścia do kodowania,
• nazewnictwa zmiennych lub metod,
• innych spraw, które różni programiści zrealizowaliby na różne sposoby,

sytuacja wymaga wyważonego podejścia. Możliwe, że pracujesz wbrew konwencji przyjętej w projekcie albo Twoje nazewnictwo wprowadza zamęt – takimi problemami najlepiej zająć się od razu. Zdarza się jednak, że niektóre osoby dzielą się sposobem, w jaki poradziliby sobie z konkretnym problemem, tak po prostu, wiedzione chęcią omówienia metodologii pracy nad projektem.

A co z Tobą?

Czy kiedykolwiek dostałeś informację zwrotną, która zmieniła bieg Twojej kariery? Daj mi znać w komentarzach – przeczytam na pewno!

Przykładowa aplikacja

Żeby za bardzo nie komplikować sprawy, oprę się na przykładzie aplikacji wygenerowanej w Create React App (CRA). Dzięki temu będziemy mieć do dyspozycji aplikację, która:

• przypomina proste, rzeczywiste przypadki,
• posiada kilka zależności npm,
• zapewnia już większość tego, co potrzebujemy.

Powstała aplikacja wygląda następująco:

Etapy weryfikacji

Niedawno pisałem o działaniach, które możesz podjąć dzięki CI. Pokażę Ci teraz, jak skonfigurować ten proces pod naszą przykładową aplikację.

Budowanie

Kod wygenerowany przez CRA robi wszystko, co będzie Ci potrzebne do procesu budowania:

$ npm run build

> netlify-ci@0.1.0 build
> react-scripts build

Creating an optimized production build...
Compiled successfully.

File sizes after gzip:

  43.71 kB  build/static/js/main.1fb16459.js
  1.78 kB   build/static/js/787.c84d5573.chunk.js
  541 B     build/static/css/main.073c9b0a.css
…

Netlify wybiera skrypt build z repozytorium wygenerowanego przez CRA automatycznie jako polecenie budowania i wszystko działa bez żadnych problemów:

Testy

Kod wygenerowany przez CRA obejmuje konfigurację pozwalającą na uruchamianie testów jednostkowych i jeden test przykładowy. Skrypt npm test został stworzony do programowania: uruchamia się w trybie interaktywnym, a jego domyślna konfiguracja zakłada obserwowanie plików. Uruchomienie w kontekście CI wymaga jednej iteracji:

$ npm test -- --watchAll=false

> netlify-ci@0.1.0 test
> react-scripts test "--watchAll=false"

 PASS  src/App.test.js
  ✓ renders learn react link (16 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.644 s, estimated 1 s
Ran all test suites.

Zdefiniujmy teraz nowy skrypt w package.json, aby mieć go na podorędziu:

{
  …
  "scripts": {
    …
    "test": "react-scripts test",
    "test:ci": "react-scripts test --watchAll=false",
    …
  },

Analiza statyczna

Kod warto wzbogacić o analizę statyczną. Podstawowa konfiguracja powinna być dość prosta, ale nie będę jej omawiał w tym artykule. Jeśli chcesz rozwinąć się w tym temacie, polecam zacząć od:

• ESLint – ze względu na to, że ostrzega Cię przed potencjalnymi problemami występującymi w kodzie,
• Prettier – bo pozwala Ci w sposób automatyczny zachować jednorodny styl programowania.

Nowy skrypt CI

Aby pomyślnie uruchomić CI/CD, wykonaj następujące działania na stworzonym kodzie:

• npm install – zapewnia zależności, realizowane domyślnie przez Netlify,
• npm run test:ci – zmodyfikowane polecenie testowania,
• npm run build – oryginalne polecenie budowania,
• wdrożenie – realizowane przez Netlify.

Build powinien być zależny od testów: jeśli one zawiodą, proces wykonywania powinien się zatrzymać – dlatego zastosuję '&&'. W ramach konfiguracji Netlify polecenie to może jednak uruchomić tylko jeden input. Stworzenie nowego skryptu przeznaczonego do tego przypadku użycia pozwala zająć się obiema kwestiami:

{
  …
  "scripts": {
    …
    "test:ci": "react-scripts test --watchAll=false",
    "ci": "npm run test:ci && npm run build",
    …
  },
  …
}

Przykładowe uruchomienie

Po całej konfiguracji skrypty będą zachowywać się tak:

• jeżeli testy buildów dadzą wynik negatywny, pulpit Netlify pokaże uruchomienie zakończone niepowodzeniem;
• jeżeli wszystko działa jak należy, aplikacja zostanie wdrożona.

Wykorzystanie zasobów

W ramach przeprowadzonych przeze mnie uruchomień testy nie miały praktycznie żadnego wpływu na czas budowania, czyli zasób, który Netlify sprawdza, aby kontrolować stopień wykorzystywania systemu. Będzie się to oczywiście zmieniać, w miarę jak Twój projekt będzie się rozrastał i będziesz do niego dodawał kolejne testy. W pewnym momencie dobrze będzie zainwestować w konfigurację dedykowanego rozwiązania CI, a z Netlify korzystać tylko na potrzeby hostingu.

Linki

• Wdrożona aplikacja,
• [przykładowe repozytorium] (https://github.com/how-to-js/es-modules).

Co zrobiłbyś dalej?

Uruchamianie CI na Netlify to tylko tymczasowe rozwiązanie. Z jakiego narzędzia skorzystałbyś w następnej kolejności? Chciałbym wiedzieć, co ciekawi czytelników mojego bloga. Daj mi znać w ankiecie:

Pilny współpracownik

Proces CI możesz traktować, jak pilnego współpracownika, który zawsze jest gotowy do pracy, tylko czekając na Twoje zmiany, aby móc je sprawdzić przed scaleniem ich do gałęzi głównej. W przypadku korzystania z CI warto mieć w workflow pull request, nawet jeśli pracujesz nad projektem sam. Twoje zmiany zostaną zweryfikowane przez maszynę, a umieszczenie ich na osobnej gałęzi pozwoli Ci na naprawę wszelkich wykrytych błędów, zanim zostaną scalone do gałęzi głównej.

Bez CI każdy programista odpowiada za weryfikację wszystkich wprowadzanych przez siebie zmian. Prędzej czy później któryś z członków zespołu zapomni o takiej weryfikacji – może oryginalne zmiany są w porządku, ale co będzie, jeśli po przeprowadzeniu rebase’a lub scalenia pojawi się problem? Jeśli nie korzystasz z procesu CI, pozwalasz mniej uważnym kolegom z zespołu na wrzucanie zmian z błędami i zapominanie o nich, a cały bałagan będą musieli po nich sprzątać inni.

Jak jest zorganizowane CI

Ciągła integracja sprawdza Twoje rewizje. Każda zmiana kodu pociąga za sobą wykonanie kilku różnych zadań w określonym porządku. Możesz wykorzystać dane wyjściowe z jednego zadania jako dane wejściowe w drugim zadaniu; możesz na przykład zbudować aplikację, a potem wykorzystać powstały dzięki temu pakiet do przeprowadzenia testów aplikacji. CI zarządza się zwykle z poziomu pliku konfiguracyjnego, który znajduje się w repozytorium – dzięki temu CI ewoluuje razem z Twoją bazą kodu.

Jeśli wszystkie zadania zostaną wykonane prawidłowo, commit przejdzie weryfikację pomyślnie; jeśli któreś z nich nie zostanie wykonane, commit nie przejdzie weryfikacji. W idealnej sytuacji sama zawartość commitu decyduje o wyniku CI: nie będą miały znaczenia usługi zewnętrzne ani nie będzie żadnego losowego elementu, który mógłby namieszać.

CI pokazuje wynik dla najnowszej rewizji. Gałąź główna powinna dawać wynik pozytywny w zdecydowanej większości przypadków; jakiekolwiek problemy wykryte w tym miejscu będą wpływać na cały zespół, jeśli więc dojdzie do regresji, naprawianie ich powinno być priorytetem. Gałęzie funkcjonalności należy scalać dopiero, gdy przejdą przez CI z wynikiem pozytywnym.

Zadania, którymi może zająć się CI

W procesie CI możesz umieścić wszelkie skrypty, które wykonujesz w swoim środowisku lokalnym. W przypadku większych projektów takich skryptów może być bardzo dużo. Przyjrzyjmy się jednak zadaniom tego procesu, które pojawią się najpewniej w każdym projekcie, niezależnie od jego wielkości.

Budowanie

Najprostszym testem, który możesz przeprowadzić na swoim kodzie, jest sprawdzenie, czy się kompiluje. Dzięki temu wyłapiesz wszystkie zależności, które zostały zainstalowane, ale nie zapisane, wszelkie rozbieżności typu TypeScript, które przedostały się do rewizji. Błędy te można łatwo usunąć, kiedy programista pracuje nad zadaniem, ale kiedy zostaną one udostępnione pozostałym członkom zespołu, mogą dezorientować i denerwować.

Analiza statyczna

Analiza statyczna zakłada sprawdzenie kodu bez jego uruchamiania. W projektach frontendowych często można spotkać się z narzędziami takimi jak:

• ESLint,
• HTMLHint,
• Stylelint.

Programy te dają najlepsze rezultaty, jeśli integruje się je z edytorem kodu. Sprawdzenie ich wyniku w ramach procesu CI stanowi dodatkową weryfikację, która może Ci pomóc w dwojaki sposób:

• zidentyfikuje każdego programistę, który zapomniał o wykonaniu tych programów u siebie – dzięki czemu możemy go poprosić, aby naprawił swoje zmiany, zanim zepsuje większy fragment kodu,
• zidentyfikuje wszelkie rozbieżności w wersjach i konfiguracjach, które mogą występować w różnych środowiskach programistycznych

Wykonywanie testów

Korzystanie z procesu CI i wykonywanie w jego ramach testów jest kluczowe, jeśli poważnie podchodzisz do zautomatyzowanych testów w swojej aplikacji. Testy te mają sens, jeśli wykonuje się je bardzo często – a nie ma na to chyba lepszego momentu niż zaraz przed wprowadzeniem zmian do głównej gałęzi. Zaniechanie tego prędzej czy później sprawi, że:

• jeden z programistów doprowadzi do regresji bazy kodu,
• pozostali członkowie zespołu naniosą na tę regresję zmiany,
• ktoś w końcu wykona testy, które wykryją początkową regresję,
• ten ktoś traci cenny czas na rozwiązywanie problemów, których nie spowodował, związanych ze zmianami, o których może nie mieć pojęcia.

Głównym wyzwaniem w takiej sytuacji jest to, że kiedy w końcu zaczniesz diagnozować problemy, nie będziesz nawet wiedział, kiedy one powstały: w poprzednim commicie, a może tydzień temu? Sprawę można załatwić poprzez git blame lub git bisect, ale dużo prościej jest, kiedy wiesz, w którym momencie testy przestały działać.

Podkreślę tu coś jeszcze: pisanie testów jest inwestycją w jakość. Jest to praca, którą trzeba wykonać każdego dnia. Jeśli to robisz, warto, żebyś skonfigurował CI – dzięki temu opracowywane przez Ciebie testy dadzą najlepsze rezultaty.

Wdrażanie

CI często idzie w parze z ciągłym wdrażaniem (CD), a połączenie to często skraca się do CI/CD. Jest tak dlatego, że kompilacja i weryfikacja kodu prowadzi do powstania gotowego do wdrożenia produktu – przynajmniej na serwer testowy. Proces CD z prawdziwego zdarzenia wezwałby Cię do wprowadzenia tego produktu do środowiska produkcyjnego, ale mogłoby to być jeszcze większym wyzwaniem, bo wystawiałoby użytkowników projektu na potencjalne regresje.

Minusy

Jakie są minusy CI?

Skomplikowana konfiguracja

Konfiguracja ciągłej integracji może Ci zabrać sporo czasu, zwłaszcza jeśli zajmujesz się nią po raz pierwszy. Weryfikacja nawet najprostszych zmian w konfiguracji może być czasochłonna, bo musisz ją przeprowadzić na zewnętrznym serwerze, do którego nie masz bezpośredniego dostępu.

Zależność od zewnętrznego dostawcy

Jeśli zintegrujesz CI ze swoim workflow, będziesz zależny od dostawcy tego procesu. Jeśli usługa będzie niedostępna, nie będziesz mógł scalać albo zostaniesz pozbawiony zaworu bezpieczeństwa, do którego już zdążyłeś się przyzwyczaić. Może to być frustrujące, szczególnie jeśli zdarza się dość często.

Koszt

Wielu dostawców CI oferuje opcję darmową, która powinna wystarczyć do prostych ćwiczeń lub projektów demo. Do projektów, nad którymi pracuje się na okrągło, prawie na pewno potrzebna będzie opcja płatna oraz dodatkowy czas, w którym CI będą mogły wykonać Twoje skrypty. Będzie to jednak najprawdopodobniej warte swojej ceny, nawet przy założeniu, że CI zaoszczędzi każdemu z programistów w Twoim zespole jedynie kilka minut pracy dziennie.

A co z Tobą?

Jesteś zainteresowany pogłębianiem wiedzy na temat konfiguracji CI? Myślę o napisaniu bardziej szczegółowych artykułów na temat konfigurowania narzędzi CI. Jeśli będę wiedział, jakie narzędzie interesuje Cię najbardziej, będę mógł tworzyć treści pod tym kątem. Tak więc daj mi znać w ankiecie! Twoje zdanie jest dla mnie bardzo cenne. Dzięki!

Co dalej?

Aby wycisnąć z CI jeszcze więcej, warto przeprowadzać w ramach tego procesu testy end-to-end (E2E). Konfiguracja E2E na CI to nie lada wyzwanie. Będę o tym pisał w kolejnym artykule. Tymczasem zachęcam do lektury poradnika, w którym tłumaczę, jak zacząć pracę z testami E2E.

Mniej plików JS

Swego czasu liczba plików JS wykorzystywanych przez witrynę internetową była kluczową sprawą, ponieważ duża liczba takich plików o niewielkim rozmiarze powodowała spadki wydajności. Przeglądarki ładowały każdy plik na podstawie odrębnego żądania HTTP. Każde żądanie wymagało połączenia między przeglądarką a serwerem, a to za każdym razem zajmowało nieco czasu. Aktualnie, dzięki protokołowi HTTP/2, liczba plików nie tworzy już takich problemów. Nadal jednak pakowanie plików razem ma sens. Każde żądanie jest zapisywane osobno w pamięci podręcznej, więc duża liczba plików sprawia, iż trudniej jest zapewnić, że przeglądarka nie załaduje z tej pamięci nieodświeżonego kodu.

Poza tym do 2018 roku wiele przeglądarek nie obsługiwało modułów ES. Ładowało się wiele plików z HTML i wszystkie dzieliły zakres globalny. Bundlery JS rozwiązują oba problemy, ponieważ:

• pozwalają na przechowywanie bazy kodu podzielonej na wiele dobrze zorganizowanych plików,
• pakują kod w duże pliki do wrzucenia na serwer.

Prosty import z node_modules

Bundlery dają Ci możliwość importowania zależności, co jest dużo wygodniejsze niż ładowanie ich jako modułów ES. Aby wykorzystać pakiety węzłów otrzymane z przeglądarki, musiałbyś:

• opublikować node_modules na serwerze produkcyjnym,
• zastosować ścieżkę względną od Twojego pliku do pliku, który chcesz importować.

Stosowanie ścieżki względnej jest problematyczne, bo zmusza Cię to do pisania importu na nieco różne sposoby, w zależności od tego, jak głęboko w strukturze folderowej akurat się znajdujesz. W przypadku Lodash będziesz mieć coś takiego:

// in ./src/core.js 
var _ = require('../node_modules/lodash/lodash.js');

// in ./src/app/main.js
var _ = require('../../node_modules/lodash/lodash.js');

Bundlery pozwolą Ci na uzyskanie tego samego prościej:

// anywhere
var _ = require('lodash');

Import innych rodzajów plików

Twoja baza kodu składa się nie tylko z JavaScript. Jeżeli porządkujesz swój kod według komponentów lub ścieżek, każdy taki element będzie mieć swój własny szablon i swoją własną stylizację. Natywne moduły ES nie pozwalają na importowanie typów zasobów innych niż JS. Przez to ograniczenie byłbyś zmuszony zaimportować CSS z HTML, ale reszta byłaby importowana w JavaScript – co sprawiłoby, że musiałbyś zsynchronizować dwa niezwiązane ze sobą pliki. Bundlery JS obchodzą ten problem, pozwalając Ci zarządzać wszystkimi zależnościami bezpośrednio z Twoich plików JS:

import ‘./core.js’;
import ‘./style.css’;

const template = require(‘./view.html’);

Transpilacja kodu

Duża część JavaScript to tak naprawdę nie tylko JavaScript: jest on pisany w językach takich jak TypeScript, a następnie kompiluje się go do JavaScript. Taka kompilacja z jednego kodu do drugiego nazywa się transpilacją. Poddawana jest jej większość kodu pisanego w JavaScript. Poniżej tłumaczę, dlaczego tak jest.

Minifikacja kodu

Jeśli piszesz swój kod tak, jak trzeba, to:

• nadajesz zmiennym sensowne nazwy,
• stosujesz wcięcia,
• zostawiasz komentarze dla pozostałych programistów.

To wszystko to tylko szum, który dla interpretera nie znaczy zupełnie nic. Minifikacja jest pierwszym krokiem na drodze redukcji rozmiaru payload. Usuwa wszystko, co nie ma wpływu na działanie aplikacji.

Downgrade do starszych wersji przeglądarek

Kiedy kod poszerza wachlarz swoich funkcji, w pewnym momencie dochodzi do sytuacji, w której:

• developerzy chcą zacząć już z niego korzystać,
• nie jest on obsługiwany przez wszystkie przeglądarki.

Na szczęście sytuacja taka utrzymuje się już znacznie krócej dzięki przeglądarkom typu evergreen, ale nadal istnieje zapotrzebowanie na projekty pokroju Babel. Kompilator ten pozwala Ci na korzystanie z najnowszej wersji języka podczas kodowania i na transpilowanie kodu do wersji obsługiwanej przez starszą wersję przeglądarki.

Odmiany JavaScript

Obok standardowego JavaScript możesz korzystać z wielu jego odmian:

• TypeScript,
• PureScript,
• Elm,
• CoffeeScript.

Bundlery JavaScript radzą sobie z jednolitym mieszaniem różnych odmian w jednym projekcie – co wydaje się kiepskim pomysłem dopóty, dopóki nie zaczniesz pracować z przestarzałym kodem i dopóki nie będziesz potrzebować dużej dozy elastyczności, żeby wybrać odpowiednie priorytety.

Osobne buildy dla różnych przypadków użycia

Kiedy zaczniesz już kompilować swój kod bundlerem, otworzą się przed Tobą nowe możliwości. Najpewniej od samego początku kompilujesz kod w jeden sposób na potrzeby środowiska produkcyjnego, a inny na potrzeby programowania lokalnego. Jeśli piszesz testy jednostkowe, możesz być ciekaw, jak dobrze weryfikują one Twój kod. Istnieją narzędzia, które dadzą Ci dokładną odpowiedź na to pytanie – są to tzw. narzędzia mierzące pokrycie kodu. Wymagają one dedykowanego buildu obejmującego narzędzia zliczające, ile razy test podczas wykonywania „odwiedza” daną linię kodu.

A co z Tobą?

Z jakiego bundlera JS chcesz skorzystać w ramach swojego kolejnego projektu? Daj mi znać w ankiecie, żebym wiedział, na czym skupić się tutaj w przyszłości:

Co dalej?

Możesz przeczytać mój artykuł o tym, jak korzystać z natywnych modułów ES, lub obejrzeć jeden z moich wideokursów:

• [wideokurs na temat esbuild] (https://bit.ly/esbuild-course),
• [wideokurs na temat webpack] (https://bit.ly/esbuild-course).

Czym są testy end-to-end

Testy E2E to skrypty, które „używają” aplikacji tak, jak zrobiłby to użytkownik. Otwierają przeglądarkę, ładują adres URL, klikają w elementy interfejsu użytkownika (UI), na przykład przyciski, i oczekują pewnych rezultatów. Testy przeprowadza komputer i są one dużo szybsze i mniej zawodne od ludzi. Poza tym nigdy się nie nudzą.

Ich jedynym słabym punktem jest to, że potrzebują precyzyjnych poleceń i zdarza się, że ich zaprogramowanie jest bardziej skomplikowane niż funkcja, którą mają testować. Pisanie testów stanowi element programowania i jest powiązane z aplikacją, która ma być testowana. Mimo to jest to zadanie, do którego wielu programistów nie podchodzi z entuzjazmem. Jeżeli rozwiniesz się w tej dziedzinie, może stać się to Twoją wyjątkową kompetencją, która pozwoli Ci błyszczeć w zawodzie.

Dobierz odpowiednie narzędzia!

Pakiet E2E można zbudować na wiele różnych sposobów:

• Cypress
• Playwright
• Protractor
• Selenium
• TestCafe

Sytuacja wygląda tu tak samo jak w przypadku innych decyzji dotyczących stosów technologii: dobrze jest gruntownie zapoznać się z wszystkimi możliwościami. Każdy pisany przez Ciebie test będzie ściśle związany z wybraną przez Ciebie platformą. Istnieje możliwość migracji z jednego narzędzia do testowania do drugiego, ale jest to przedsięwzięcie przypominające wymianę frameworka na frontendzie.

Moje doświadczenia ograniczają się głównie do Protractora, niedocenianego rozwiązania opartego na Angular. Aktualnie przeprowadzam migrację testów do Cypress i jestem pod wrażeniem postępu w dziedzinie narzędzi do testowania, do jakiego doszło na przestrzeni minionych lat. A Ty z jakiego narzędzia E2E chcesz korzystać w swoim kolejnym projekcie? Daj mi znać, biorąc udział w ankiecie:

Proste testy na lokalnym sprzęcie

Niech Twoje pierwsze testy będą wręcz banalne. Weź dowolny lokalny testowy URL, jaki masz pod ręką, i uruchom na nim swoje skrypty. Nie musisz nawet sprawdzać workflow aplikacji. Po prostu napisz kilka testów, po jednym dla każdej trasy, i sprawdź, czy na danej stronie pojawiają się elementy interfejsu UI. Możesz na przykład sprawdzić:

• on /login– czy pojawiają się pola wprowadzania hasła i nazwy użytkownika,
• on /product/12 – czy wyświetlana jest nazwa produktu,
• itd.

Nawet przy pomocy tak prostych testów możesz udowodnić, że:

1. aplikacja się uruchamia, a wszystkie trasy wyświetlają się razem z kluczowymi elementami interfejsu UI;
2. potrafisz tworzyć testy E2E.

I tym sposobem temat E2E zacznie się rozkręcać – zespół będzie mieć kilka testów do wyboru, a jeden z jego członków (czyli Ty) będzie chętny i zdolny do pisania kolejnych!

Podziel się dobrą nowiną z zespołem

Nie będziesz musiał być tu zbyt nachalny, przynajmniej na początku. Upewnij się tylko, że wszyscy wiedzą, że testy E2E są dostępne, i doprowadź do sytuacji, w której od każdego programisty oczekiwać się będzie, że przeprowadzi je przed scaleniem jakichkolwiek zmian w gałęzi głównej. Na tym etapie zauważysz wszelkie różnice między lokalnymi konfiguracjami używanymi przez Twoich kolegów po fachu – inne domeny lub porty, z których korzystają lokalnie. Możesz opanować sytuację przez dopilnowanie, żeby wszyscy używali tego samego adresu URL, albo przez sprawienie, że URL testowy będzie łatwy w konfiguracji, a nie zakodowany „na twardo”. Oba podejścia są w porządku. Ja zdecydowałem się na dopilnowanie, aby wszyscy korzystali z tego samego adresu URL localhosta; w moim przypadku zespół nie miał nic przeciwko.

Kolejnym krokiem jest przetestowanie ścieżki happy path w odniesieniu do workflow – czyli jak powinna działać aplikacja, kiedy wszystko funkcjonuje, jak należy. Innymi słowy – piszesz testy, które sprawdzają, czy przycisk „Dodaj do koszyka” rzeczywiście dodaje wybrane produkty do koszyka i czy przycisk „Kupuję i płacę” kieruje użytkownika na stronę dostawcy usług płatniczych. Testy takie trudniej się pisze, ale sprawdzają najważniejsze elementy aplikacji. Skrypty te powinny pomóc Ci w przekonaniu kolegów o przydatności E2E. A Twoje testy będą stawać się coraz bardziej zaawansowane.

Co dalej

Jeśli masz jakiekolwiek pytania lub wątpliwości w temacie testów E2E, podziel się nimi w komentarzach! Przeczytam je i postaram się odpowiedzieć na nie jak najlepiej. A jeśli jeszcze mało Ci czytania, zapraszam do zapoznania się z moim artykułem o zarządzaniu delikatnym przestarzałym kodem.

Przejrzyj kod

Otwórz kod i nieco się z nim zapoznaj. Kod przed Twoimi oczami będzie pewnie zagmatwany, pliki będą za duże, a cała reszta będzie przypominać jeden wielki bałagan. Dobrze by było, gdybyś najpierw skupił się na strukturze plików i znalazł pewne wzorce. W projekcie, który trwa już długo i w którym nikt nie zadał sobie trudu, żeby popracować nad spójnością, najpewniej znajdziesz rywalizujące designy zastosowane w pozornie dowolny sposób. W takim wypadku spróbuj zdiagnozować wagę problemu, a systematyzację zostaw na później.

Zaktualizuj plik README

Po przejrzeniu kodu trzeba będzie ocenić stan dokumentacji. Gdzieś powinien znajdować się jakiś plik README. Może ostatnia data jego edycji woła o pomstę do nieba, ale przynajmniej wyjaśni Ci sposób myślenia, zgodnie z którym stworzono bazę kodu. Możesz spróbować zaktualizować jego treść, jeśli natkniesz się na fragmenty, które nijak mają się do rzeczywistości. Na początek dobrze będzie wprowadzić zmiany, o których mowa w mailach i innej korespondencji dotyczącej projektu, i upewnić się, że ich opis znajdzie się w pliku README razem z odpowiednimi odnośnikami. Aktualizuj też plik regularnie, tak aby kolejna osoba pracująca nad projektem miała lżejszy początek.

Rozpracuj budowanie projektu

Niedawno pracowałem nad kursem dotyczącym upgrade’u Angular, którego ostatnia aktualizacja miała miejsce trzy lata temu. Pierwsze filmy dotyczyły Angular 4 – wersji, która jest tak stara, że nie jest kompatybilna z najnowszym Node.js i najnowszymi procesorami. Przed zainstalowaniem jej na moim sprzęcie musiałem przejść przez serię wymuszonych upgrade’ów – a był to tylko niewielki, przykładowy projekt. Natomiast projekt, nad którym Tobie dane będzie pracować, będzie prawdopodobnie w dużo gorszym stanie.

W idealnym świecie wszystko, czego potrzebujesz do zbudowania projektu, będzie:

1. ujęte w pliku README lub innej dokumentacji,
2. nadal aktualne,
3. działać jak należy.

W większości przypadków Twój projekt nie spełni jednak tych trzech warunków, przez co sam będziesz musiał coś wymyślić. Jeśli projekt nie działa, możesz poszukać problemu i dowiedzieć się, co jest jego przyczyną.

Jeśli dokumentacja nie zawiera pomocnych informacji, kolejnym miejscem, do którego powinieneś się udać, jest plik package.json. ”scripts” może zawierać jakieś wbudowane polecenie. Twoją ostatnią deską ratunku jest szukanie śladów narzędzi do budowania aplikacji, które były popularne w przeszłości, i rozpoczęcie swego rodzaju prac archeologicznych nad JavaScript:

• grunt,
• gulp,
• webpack,
• browserify,
• require.js.

A teraz wdrożenie

Tu też możesz mieć nieco zabawy. Brak wiedzy o tym, gdzie znajdują się Twoje programy, może być dość frustrujący: obawiasz się przez to tego, co się stanie, jeśli przestaną one działać. Mieliśmy kiedyś taką sytuację, że przez kilka miesięcy próbowaliśmy dociec, gdzie „żyje” nasz wewnętrzny chatbot. Informacje tego typu powinny być prostsze w znalezieniu w przypadku systemów krytycznych, ale szukanie ich i tak zajmuje więcej czasu, niż można byłoby się spodziewać.

Wyszukanie wszystkich szczegółowych informacji o procesie wdrożenia w środowisku produkcyjnym może być czasochłonne. Szyki może pokrzyżować Ci to, że nie masz prawidłowego użytkownika bądź brakuje informacji uwierzytelniających w niektórych obszarach, a poza tym wszystko musisz sprawdzać dwa razy, żeby mieć pewność, że niczego nie zepsujesz. Gratulacje! Właśnie nauczyłeś się wprowadzać zmiany w kodzie na własnym sprzęcie. Zmiany, które będą mogły wejść do środowiska produkcyjnego. Twoja praca będzie mogła komuś pomóc.

Zbadaj aktualnie stosowane środki zapewniania jakości (QA)

Podobnie jak w przypadku buildu – spróbuj znaleźć wszelkie dostępne Ci informacje na temat:

• testów integracyjnych,
• testów jednostkowych,
• lintingu.

Jeśli nie będzie ich w dokumentacji ani w skryptach package.json, możesz poszukać narzędzi, które były popularne w przeszłości.

• Testy integracyjne:
  • protractor,
  • selenium.
• Testy jednostkowe:
  • jasmine,
  • mocha,
  • sinon.
• Linting:
  • jslint,
  • jshint,
  • tslint.

Jeżeli dokopałeś się do śladów stosowania zautomatyzowanych środków QA, staraj się korzystać z tych środków jak najczęściej. Wszystko, co robili programiści przed Tobą, może okazać się bardzo wartościowe i naprawdę szkoda byłoby to wszystko wyrzucić do kosza.

Wprowadź test dymny

Jeśli chcesz odnowić stary silnik, za pierwszym razem uruchomisz go bez żadnego obciążenia, żeby zobaczyć, czy działa i czy się nie pali. Nazywa się to testem dymnym – wszystko jest w porządku, dopóki nie ma dymu. To samo tyczy się kodu przestarzałego: jeśli nie masz czym dokładnie przetestować aplikacji, przynajmniej ją zbuduj i sprawdź, czy uruchamia się prawidłowo. Zanim będziesz w stanie uruchamiać automatycznie bardziej skomplikowane testy, lepiej wyjdziesz na wprowadzaniu prostych zmian i korzystaniu z tej samej podstawowej procedury, aby upewnić się, że wszystko działa tak, jak trzeba.

Zacznij od drobnych zmian

Jesteś już na dobrej drodze, jeśli chodzi o przywracanie projektu do życia; nadeszła pora na wprowadzanie zmian w kodzie. Niech te pierwsze zmiany będą malutkie, takie, że nikt ich nawet nie zauważy. Możesz:

• zaktualizować jedną z bibliotek,
• zmienić nazwę niektórych zmiennych lokalnych,
• przeprowadzić refaktoryzację denerwującego antywzorca występującego w jednym miejscu.

Pamiętaj, że celem jest wprowadzenie zmiany, która nie będzie powodować żadnych skutków ubocznych.

Przeprowadź wdrożenie do środowiska produkcyjnego

Rozwiń kod przy pomocy swoich drobnych zmian i wdróż go we wszystkich środowiskach, w tym w środowisku produkcyjnym. Celem jest przetarcie szlaku dla tego odtworzonego procesu – przelanie zmian w kodzie z Twojej głowy na urządzenia klientów. Zadanie jest wymagające, dlatego właśnie ograniczamy zakres zmian do minimum. Twoim zadaniem jest zwiększenie swojej pewności siebie i zaufania interesariuszy.

Dodaj testy integracyjne

Testy integracyjne najprawdopodobniej będziesz musiał zbudować od zera. Chodzi tu o ten etap testowania, w którym sprawdza się, czy wszystko jest należycie zintegrowane i czy działa prawidłowo. Testy te znane są również pod nazwą end-to-end (e2e), ponieważ często polegają na jednoczesnej weryfikacji frontendu i backendu. Warto zacząć od nich, bo nie będzie miało znaczenia, że Twoja aplikacja prawidłowo wylicza na przykład podatek VAT, jeśli będzie wyłączać się po każdej próbie rozpoczęcia nowej transakcji. Na pierwszy rzut oka sensowniejszym pomysłem może wydawać się stworzenie prostych testów dla wielu stron, a nie precyzyjnych skryptów tylko dla kilku z nich. Proste testy, obejmujące choćby sprawdzenie trasy albo tego, czy kluczowe elementy interfejsu są nadal dostępne, mogą być bardzo wartościowe – wyłapią przypadki całkowitego rozsypywania się stron.

Przygotuj i zacznij dodawać testy jednostkowe

Po upewnieniu się, że aplikacja działa, jak trzeba, możesz przejść do szczegółów: sprawdzić, czy działają wszystkie jednostki – klasy, funkcje itd. Możesz je przetestować z poziomu interfejsu użytkownika, ale testy end-to-end:

• długo się pisze – zebranie odpowiednich danych w jednym miejscu zajmuje sporo czasu;
• działają powoli – utrzymywanie uruchomionych baz danych, backendu i przeglądarki wymaga dużo zasobów.

Zamiast wpychać do ustawień integracji wszystkie przypadki brzegowe, jakie tylko przyjdą Ci na myśl, lepiej jest mieć na podorędziu osobny test przeznaczony do zajmowania się drobiazgami. Innymi słowy – potrzebne Ci będą testy jednostkowe. Testy te:

• są o rzędy wielkości szybsze od testów e2e,
• nie łączą się z backendem ani z bazą danych,
• pozwalają na testowanie najdrobniejszych elementów aplikacji niezależnie od otaczającego je kodu i workflow.

Chcesz dowiedzieć się więcej? Tutaj dowiesz się, dlaczego według mnie warto pisać testy jednostkowe.

Kod lint

Lintery to programy do statycznej analizy kodu, których zadaniem jest identyfikacja wspólnych źródeł różnych problemów. Dobrze jest mieć ustawioną regularną weryfikację kodu, która sprawdza, czy wszystko działa prawidłowo. eslint, popularny linter dla JavaScript i TypeScript pozwala na szeroko zakrojoną konfigurację. Możesz ustawić plik konfiguracyjny tak, żeby wyłapywać tylko najbardziej problematyczne kwestie, naprawić całą bazę kodu i zintegrować ją przy pomocy Twojego edytora kodu. Aby uzyskać jeszcze więcej wartości, możesz zacząć dokonywać na tym pliku różnych iteracji – włączając lub wyłączając różne zasady i dodając wtyczki obejmujące konkretne frameworki. Dzięki temu sprawisz, że kod z czasem się poprawi; jednocześnie poszczególne kroki będą niewielkie i nie zabiorą Ci zbyt dużo czasu już na samym początku.

Trzymaj się jednego stylu kodowania

Stosowanie tego samego formatowania upraszcza czytanie kodu: unikniesz dziwnie sformatowanych miejsc, które przyciągają uwagę z niewłaściwych powodów. Konsekwencja w bazie kodu wprowadza poczucie porządku i daje spokój ducha, jeśli chodzi o aktualny stan projektu. Styl kodowania to temat zaciętych dyskusji. Nie przykładam szczególnej wagi do formatowania; zależy mi tylko na zachowaniu konsekwencji niezależnie od tego, kto i kiedy napisał kod, i chciałbym, aby ustalony styl był wykorzystywany automatycznie. Na szczęście istnieją narzędzia takie jak prettier, które w mgnieniu oka formatują całe projekty i pozwalają zespołowi zadecydować tylko o niektórych kwestiach. Co oznacza możliwość przerzucenia samego formatowania i niekończących się dyskusji na ten temat na zewnętrzne narzędzie!

Przeprowadź łatwe aktualizacje bibliotek

Czas na finalną rozgrzewkę. Możesz spróbować zaktualizować niektóre zależności z jednej wersji do wersji nowszej – na przykład z wersji 1.2.3 do 1.2.4. Wszystkie biblioteki zewnętrzne wykorzystywane przez Twój kod są najpewniej przestarzałe. Ich aktualizacja będzie wymagać dużo pracy, ale będzie warto: nowsze wersje będą pewnie miały nowe funkcje, poprawki bezpieczeństwa i więcej materiałów dostępnych online. Nawet wprowadzenie łatki nie jest trywialną zmianą, a z całą już wykonaną przez Ciebie pracą w zanadrzu możesz oczekiwać jednego z dwóch rezultatów:

• po aktualizacji pojawią się błędy, które zostaną wyłapane przez jedną z warstw weryfikacyjnych;
• wszystko będzie działać, jak należy – podczas testów i w środowisku produkcyjnym, już po wdrożeniu.

Pamiętaj, nie spiesz się z tymi aktualizacjami! Wprowadź jedną, wdróż ją i poczekaj na reakcję. Pamiętaj, uczysz ludzi wiary we wprowadzane przez Ciebie zmiany i ostatnią rzeczą, na której Ci zależy, jest regresja.

Wprowadź jak najmniejsze, jak najprostsze ulepszenie w interfejsie użytkownika

Jak dotąd Twoja praca była dla użytkowników niemalże niewidoczna – chyba że mimo wszystko udało Ci się zamieszać w środowisku produkcyjnym. Gdy organizację całej infrastruktury masz już za sobą, możesz zająć się dodawaniem wartości! Wybierz jak najdrobniejszy i najprostszy problem – literówkę na stronie albo brakujący margines na przycisku. Twoim celem jest pokazanie sobie i innym, że potrafisz naprawiać błędy i wprowadzać zmiany w kodzie bez psucia innych rzeczy. Nie zepsuj tego, porywając się z motyką na słońce.

Wdróż proces ciągłej integracji (CI)

Jeśli projekt zacznie przeżywać swoją drugą młodość, możesz spodziewać się napływu większej liczby żądań zmian. W takim wypadku sensownym posunięciem będzie wprowadzenie ciągłej integracji. Jeśli chcesz dowiedzieć się więcej, daj mi znać w akciecie:

Co dalej?

Gratulacje! Właśnie zostałeś osobą, do której wszyscy będą się zwracać, kiedy pojawią się problemy z przestarzałym kodem. Ciesz się z nowo nabytego bezpieczeństwa zawodowego – opisaną tu pracę trzeba wykonać, a ludzie raczej się do niej nie kwapią. W takim momencie aż prosi się, żebyś sprawdził, czy Twoje wynagrodzenie stoi na poziomie rynkowym i odzwierciedla wartość, którą wnosisz do firmy – więcej na ten temat przeczytasz tutaj.

Porozmawiaj o pensji z kolegami z pracy

Sposób, w jaki postrzega się rozmowy o pieniądzach, zależy od kultury. Dorastałem w Polsce, przez co rozmawianie o moich dochodach przez długi czas kojarzyło mi się ze zwyczajnym przechwalaniem się. Rzeczywiście mogłoby to tak wyglądać, gdyby dobrze opłacany specjalista mówił o swoich zarobkach komuś, kto ledwo wiąże koniec z końcem, pracując za minimalne wynagrodzenie. Warto jednak zauważyć, że konwersacje tego typu między osobami pracującymi na podobnych stanowiskach dadzą jeden z dwóch rezultatów:

• albo okaże się, że pensje rozmówców różnią się minimalnie,
• albo któryś z rozmówców – może Ty – zda sobie sprawę z tego, że jest wynagradzany niedostatecznie. Może to wynikać z kilku powodów:
  • brak umiejętności technicznych,
  • brak umiejętności negocjacyjnych,
  • pracodawca nie dysponuje finansowymi możliwościami pozwalającymi na wypłacanie wyższego wynagrodzenia.

A co z tymi, którzy w rezultacie takiej rozmowy dowiedzą się, że zarabiają lepiej? Na pewno nic na tym nie stracą.

Oprócz kulturowego tabu jedynym powodem do nierozmawiania o pieniądzach jest sytuacja, w której wynik finansowy firmy interesuje Cię bardziej niż dobro Twoje i Twoich kolegów. Może tak być na przykład wtedy, gdy Twój udział w kapitale firmy jest dla Ciebie ważniejszy niż Twoje wynagrodzenie, albo całym sercem wierzysz w misję swojego pracodawcy.

** Przeprowadzaj regularną analizę rynku pracy Jeśli działasz tak jak ja, to, na czym aktualnie skupiasz się w ramach pracy zawodowej, zmienia się wielokrotnie na przestrzeni lat. Czasami spędzam dużo czasu na uczeniu się nowych rzeczy czy angażowaniu w społeczności techniczne, a czasami miewam miesiące, podczas których cała moja aktywność w IT sprowadza się wyłącznie do wykonywania obowiązków pracowniczych. Rynek pracy zmienia się nieustannie: na popularności zyskują nowe technologie, na rynek lokalny wchodzą spółki oferujące lepsze warunki zatrudnienia, firmy z siedzibą w odległych lokalizacjach szukają ludzi do pracy zdalnej. Warto obiecać sobie regularną analizę takich zmian. Przeznaczenie nawet tylko jednego popołudnia w roku na przeszukanie ofert pracy da Ci świadomość sytuacji panującej poza murami Twojego obecnego pracodawcy.

Nie licz na ruch ze strony swojej firmy

Twojemu pracodawcy zawsze będzie zależeć na utrzymaniu status quo w zakresie swojej działalności. Możliwe, że ocena Twojego kierownika będzie zależeć od tego, ile osób już odeszło z jego zespołu, ale taki scenariusz da mu jedynie niewielką motywację do utrzymania Twojego wynagrodzenia na poziomie rynkowym. Motywacja ta będzie jeszcze mniejsza, jeśli powiesz mu, że lubisz swoją pracę i że na ten moment nie szukasz niczego nowego. Jeśli polityka firmy zakłada regularne podwyżki, będzie to najpewniej podyktowane indeksacją płac, a nie zmianami na rynku pracy IT. Jeśli dostaniesz awans i wejdziesz w nowy przedział płacowy, co wiązać się będzie z podwyżką, będzie to wyglądać jak krok do przodu w aspekcie finansowym, ale równie dobrze możesz wtedy znaleźć się przy dolnej granicy nowych widełek płacowych.

Przygotuj się na negocjacje

W 2019 r. kupiłem sobie na urodziny książkę [Fearless Salary Negotiation] (https://bit.ly/FearlessSalaryNegotiation). To był najlepszy prezent, jaki kiedykolwiek dostałem, a jego koszt spłacił się bardzo szybko. Książka zawiera multum praktycznych wskazówek – poradnik, co krok po kroku zrobić, zanim rozpoczniemy negocjowanie swojego wynagrodzenia. Lwią część tego procesu stanowią rozmowy z nowymi firmami, ale istnieje wiele działań, które przydadzą się w szerszym kontekście, a jeden z rozdziałów książki poświęcony jest awansom i podwyżkom.

Jeśli nie dysponujesz wolnymi środkami, autor książki udostępnia jej treść za darmo (https://bit.ly/FearlessSalaryNegotiationFree). A na jego stronie internetowej można zapoznać się z jego poradami w skrótowej formie: [Jak zredagować e-mail do kierownika rozpoczynający rozmowy o podwyżkę] (https://bit.ly/FearlessSalaryNegotiationRaise).

Po prostu poproś!

Rozmowa z kierownikiem o wynagrodzeniu może być stresująca. Należyte przygotowanie powinno pomóc Ci osiągnąć cel i poradzić sobie ze stresem. Spójrz na to z innej perspektywy – rozsądny kierownik powinien docenić, że z własnej inicjatywy zaczynasz rozmowę na tematy finansowe, zamiast od razu zatrudnić się u konkurencji. A jeśli okaże się, że kierownik jest nierozsądny? Będzie to po prostu sygnał, że warto zacząć interesować się inną firmą.

Nie wstydź się; powiedz kolegom

Kiedy już dostaniesz upragnioną podwyżkę, pochwal się swoim kolegom z pracy! Standardowa praktyka w branży polegająca na skakaniu między różnymi firmami w celu podwyższania wynagrodzenia sprawia, że Twoi doświadczeni koledzy w każdej chwili mogą zostać zastąpieni kimś, kto nie wie o Twoim projekcie nic, przez co znacząco zwiększy się zakres pracy, za którą będziesz odpowiedzialny. Podzielenie się dobrą nowiną może zainspirować członków Twojego zespołu do pójścia w Twoje ślady, a także podnieść ich morale i sprawić, że zostaną w obecnym miejscu pracy na dłużej. Dzięki temu Twoja praca będzie prostsza i przyjemniejsza.

Co dalej?

Refleksja nad pracą zawodową z Twojej strony i próby zapewnienia sobie jak najlepszych warunków pracy to dobry znak. Skoro dotarłeś do końca tego artykułu – proponuję Ci zastanowić się, czy Twoja aktualna posada do Ciebie pasuje. Pomoże Ci w tym poradnik na temat tego, jak ocenić swoje aktualne miejsce pracy. Jeśli w głowie już rodzą Ci się pytania, cały czas szukam chętnych na darmowy mentoring w zakresie JS i programowania – jeśli jesteś chętny, daj mi znać!

Wybierz prosty przypadek użycia

Krok pierwszy: nie porywaj się z motyką na słońce. Pracownikom z branży IT często zdarza się budować swego rodzaju klony popularnych stron internetowych. Prowadzi to jednak do mnożenia się funkcji, co uniemożliwia skuteczną pracę nad nimi. Jeśli chcesz inspirować się istniejącymi produktami, spróbuj maksymalnie je uprościć:

• Jeśli klonujesz Reddita, stwórz stałą, hardcodowaną listę linków (na przykład do najlepszych stron internetowych o programowaniu), gdzie ludzie mogą głosować za lub przeciw ALBO stwórz długą listę, do której po prostu dodajesz linki.
• Jeśli klonujesz Airbnb, ogranicz się do wyświetlenia nieruchomości – bez rezerwacji i bez dodawania nowych właściwości.
• Jeśli klonujesz Ubera, stwórz stronę z podsumowaniem zamówienia – przejazd z punktu A do punktu B.

Możesz też zacząć pracować nad nieco już wyświechtanymi produktami: aplikacją z listą rzeczy do zrobienia lub stroną blogową. Może Ci się to wydawać monotonne i nudne, ale taki przypadek użycia jest przynajmniej zrozumiały i nie powinien być przytłaczający.

Naszkicuj interfejs

Po wyborze przypadku użycia weź kartkę papieru i długopis i narysuj swój interfejs. Zacznij od jednej strony, maksymalnie dwóch stron. Na początku szkic na papierze będzie idealny: celem jest szybka iteracja, a mało zaawansowane rozwiązanie nadaje się do tego wyśmienicie. Pracując nad wspólnymi projektami, członkowie zespołu tworzą design przy pomocy wyszukanych aplikacji, ale korzystanie z nich jest czasochłonne – trzeba zainstalować aplikację, nauczyć się interfejsu itd., co spowalnia pracę. Szkic nada kształt Twoim myślom, a kiedy będzie gotowy, będziesz na niego zerkać tylko raz na jakiś czas, budując swój interfejs.

Złota rada dla początkujących programistów podaje, że najwięcej uczysz się podczas pracy nad własnymi projektami. Jest ona dobra, ale czasem trudno jest jej słuchać – zwłaszcza jeśli stawiasz na ścieżce IT swoje pierwsze kroki. W artykule tym opisuję krok po kroku, jak w prosty sposób rozpocząć pracę nad własnymi projektami i uczyć się podczas ich realizacji. Moje przykłady opierają się na stosie do tworzenia frontendowych aplikacji internetowych – HTML + CSS + JS – ale przedstawione tu podejście możesz zastosować do każdej wykorzystywanej przez Ciebie technologii.

Wybierz prosty przypadek użycia

Krok pierwszy: nie porywaj się z motyką na słońce. Pracownikom z branży IT często zdarza się budować swego rodzaju klony popularnych stron internetowych. Prowadzi to jednak do mnożenia się funkcji, co uniemożliwia skuteczną pracę nad nimi. Jeśli chcesz inspirować się istniejącymi produktami, spróbuj maksymalnie je uprościć:

• Jeśli klonujesz Reddita, stwórz stałą, hardcodowaną listę linków (na przykład do najlepszych stron internetowych o programowaniu), gdzie ludzie mogą głosować za lub przeciw ALBO stwórz długą listę, do której po prostu dodajesz linki.
• Jeśli klonujesz Airbnb, ogranicz się do wyświetlenia nieruchomości – bez rezerwacji i bez dodawania nowych właściwości.
• Jeśli klonujesz Ubera, stwórz stronę z podsumowaniem zamówienia – przejazd z punktu A do punktu B.

Możesz też zacząć pracować nad nieco już wyświechtanymi produktami: aplikacją z listą rzeczy do zrobienia lub stroną blogową. Może Ci się to wydawać monotonne i nudne, ale taki przypadek użycia jest przynajmniej zrozumiały i nie powinien być przytłaczający.

Naszkicuj interfejs

Po wyborze przypadku użycia weź kartkę papieru i długopis i narysuj swój interfejs. Zacznij od jednej strony, maksymalnie dwóch stron. Na początku szkic na papierze będzie idealny: celem jest szybka iteracja, a mało zaawansowane rozwiązanie nadaje się do tego wyśmienicie. Pracując nad wspólnymi projektami, członkowie zespołu tworzą design przy pomocy wyszukanych aplikacji, ale korzystanie z nich jest czasochłonne – trzeba zainstalować aplikację, nauczyć się interfejsu itd., co spowalnia pracę. Szkic nada kształt Twoim myślom, a kiedy będzie gotowy, będziesz na niego zerkać tylko raz na jakiś czas, budując swój interfejs.

Zbuduj interfejs

Po tych wszystkich przygotowaniach będziesz gotowy na pracę z kodem. Interfejs użytkownika jest najbardziej namacalnym i prawdopodobnie najprostszym elementem projektu. Stwórz plik HTML i ewentualnie dodaj CSS, jeśli będziesz mieć ochotę na upiększenie swojej aplikacji. Celem jest wykreowanie tego, co narysowałeś wcześniej, i wyświetlenie w jak najciekawszy sposób. Pamiętaj – zwłaszcza jeśli bawisz się w stylizację – że „gotowe jest lepsze niż idealne”: nie spędzaj na tym etapie zbyt dużo czasu, chyba że CSS i design to umiejętności, na których chcesz się skupić.

Stwórz dane fikcyjne i zaktualizuj interfejs tak, aby je wyświetlał

Kiedy skończysz już pracę z HTML i hardcodowanymi danymi, będziesz mógł przejść do stworzenia dynamicznego interfejsu. Na tym etapie wzbogacisz swój projekt przy pomocy języka JS. Możesz się ograniczyć do zwykłego JS i odtworzyć kod HTML jako DOM, albo dodać ramę JS, którą już znasz lub której chcesz się nauczyć. Będziesz musiał stworzyć tymczasową strukturę danych w zmiennej i odtworzyć JS formularza HTML na podstawie danych w tej zmiennej.

Zbuduj interfejs

Po tych wszystkich przygotowaniach będziesz gotowy na pracę z kodem. Interfejs użytkownika jest najbardziej namacalnym i prawdopodobnie najprostszym elementem projektu. Stwórz plik HTML i ewentualnie dodaj CSS, jeśli będziesz mieć ochotę na upiększenie swojej aplikacji. Celem jest wykreowanie tego, co narysowałeś wcześniej, i wyświetlenie w jak najciekawszy sposób. Pamiętaj – zwłaszcza jeśli bawisz się w stylizację – że „gotowe jest lepsze niż idealne”: nie spędzaj na tym etapie zbyt dużo czasu, chyba że CSS i design to umiejętności, na których chcesz się skupić.

Stwórz dane fikcyjne i zaktualizuj interfejs tak, aby je wyświetlał

Kiedy skończysz już pracę z HTML i hardcodowanymi danymi, będziesz mógł przejść do stworzenia dynamicznego interfejsu. Na tym etapie wzbogacisz swój projekt przy pomocy języka JS. Możesz się ograniczyć do zwykłego JS i odtworzyć kod HTML jako DOM, albo dodać ramę JS, którą już znasz lub której chcesz się nauczyć. Będziesz musiał stworzyć tymczasową strukturę danych w zmiennej i odtworzyć JS formularza HTML na podstawie danych w tej zmiennej.

źródło

Kodowanie bez modułów ES

Przed powstaniem modułów ES wszystkie JS trzeba było importować globalnie. Każdy plik miał dostęp do wcześniej zdefiniowanych zmiennych i mógł zostawić informację dla kodu wykonywanego później. Kolejność importowania miała znaczenie, zwłaszcza że elementy zaimportowane później mogły zmienić te, które zostały zaimportowane wcześniej. Starsze importy wyglądały mniej więcej tak:

display-data.js:

document.body.innerHTML = "lorem ipsum";

log.js:

console.log("Some test info");

index.html:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>No modules</title>
    <link rel="shortcut icon" href="#" />
  </head>

  <body>
    <script src="./display-data.js"></script>
    <script src="./log.js"></script>
  </body>
</html>

Konkretny przykład w akcji.

Problemy

Podejście to jest problematyczne głównie z dwóch powodów:

1. Zanieczyszcza zakresu globalnego przez kod. Jeśli kilka plików określa tę samą wartość, będą one ze sobą kolidować i będą się na siebie wzajemnie nadpisywać: powodzenia w szukaniu i naprawianiu powstałych w związku z tym bugów. Przykład: data-1.js:

   var data = “lorem ipsum”;
   

   data-2.js:

   var data = “sin dolor”;
   

   index.html:

   <html>
   <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Name collision</title>
    <link rel="shortcut icon" href="#" />
   </head>
   
   <body>
    <script src="./data-1.js"></script>
    <script src="./data-2.js"></script>
    <script>
      document.body.innerHTML = data;
    </script>
   </body>
   </html>
   

   Przykład. Obchodzenie tego problemu polegało najczęściej na wykorzystywaniu natychmiastowo wywoływanego wyrażenia funkcyjnego. Pozwalało to na izolację bloków kodu i chroniło przed zanieczyszczeniem zakresu globalnego, ale jednocześnie sprawiało, że kod stawał się bardziej zagmatwany.

2. Wszelkimi zależnościami trzeba zarządzać ręcznie. Jeśli jeden plik zależy od drugiego, pliki te trzeba zaimportować w odpowiedniej kolejności. Na przykład: log-data.js:

   console.log(data);
   

   data.js:

   const data = ‘some data’;
   

   display-data.js:

   document.html = data;
   

   index.html:

   <html>
   <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>File order</title>
    <link rel="shortcut icon" href="#" />
   </head>
   
   <body>
    <script src="./log-data.js"></script>
    <script src="./data.js"></script>
    <script src="./display-data.js"></script>
   </body>
   </html>
   

   Jak widać tutaj, część wyświetlająca dane działa, jak należy, a część z logowaniem danych – nie.

Moduły ES w akcji

Co się zmieni, gdy to samo zrobimy z modułami ES? Przede wszystkim zależności definiowane są na poziomie kodu. Jeśli więc chcesz, żeby plik wykorzystywał wartości z innego pliku, definiujesz to bezpośrednio w tym pliku. Podejście to wiele zmienia, zwłaszcza w zakresie czytania kodu: aby poznać cały kontekst stosowany przez konkretny plik, wystarczy go otworzyć i przeczytać.

Jak zatem stosować moduły ES?

data.js:

export const data = "lorem ipsum";

display-data.js:

import { data } from "./data.js";

document.body.innerHTML = data;

index.html:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Simple modules</title>
    <link rel="shortcut icon" href="#" />
  </head>

  <body>
    <script type="module" src="./display-data.js"></script>
  </body>
</html>

Główne zmiany wprowadzone w kodzie:

1. dodanie type=”module” do importu <script> w pliku HTML;
2. zastosowanie eksportowych i importowych słów kluczowych w plikach JS w celu zdefiniowania i załadowania modułów.

Działający przykład.

Import tego samego pliku przez kilka innych plików

Opisywany przykład można urozmaicić poprzez zaimportowanie tych samych plików dwukrotnie. Jako że każdy z plików musi być niezależny od tego drugiego, import zostanie dodany dwa razy – osobno dla każdego pliku. Przeglądarki zarządzają importem prawidłowo i ładują dany plik tylko raz.

data.js:

export const data = "lorem ipsum";

display-data.js:

import { data } from "./data.js";

document.body.innerHTML = data;

log-data.js:

import { data } from "./data.js";

console.log(data);

index.html:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Shared import</title>
    <link rel="shortcut icon" href="#" />
  </head>

  <body>
    <script type="module" src="./display-data.js"></script>
    <script type="module" src="./log-data.js"></script>
  </body>
</html>

Przykład

Leniwe ładowanie aka lazy load

Lazy load opóźnia ładowanie aplikacji do chwili, w której kod zaczyna być potrzebny. Ta technika optymalizacji jest bardziej skomplikowana niż ładowanie wszystkiego od razu, ale pozwala na większą kontrolę nad tym, co i kiedy się ładuje. W poniższym przykładzie ładuję i wyświetlam dane z około półsekundowym opóźnieniem:

display-data.js:

setTimeout(
  () =>
    import("./data.js").then(({ data }) => {
      document.body.innerHTML = data;
    }),
  500
);

data.js:

export const data = "lorem ipsum";

index.html:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Lazy load</title>
    <link rel="shortcut icon" href="#" />
  </head>

  <body>
    <script type="module" src="./display-data.js"></script>
  </body>
</html>

[Przykład lazy load] (https://how-to-js.github.io/es-modules/lazy-load/)

Czy moduł ES obejmuje wszystko, czego potrzeba w nowoczesnym JS?

Chociaż natywne moduły ES znacznie poprawiają wcześniejsze modele wprowadzania nowych elementów, brakuje im kilku cech kluczowych w nowoczesnym procesie programowania w JavaScript. Aktualnie nie można wykonać następujących działań:

1. Importu typów innych niż JS. Obecnie przygotowywane są inne pliki [JSON] (https://tc39.es/proposal-json-modules/), ale minie jeszcze trochę czasu, zanim będą one obsługiwane przez przeglądarki.
2. Importu zewnętrznych bibliotek tak jak w Node.js. Można by skopiować pliki podczas kompilacji i zaimportować je z lokalizacji w node_modules, ale proces ten wydaje się dużo bardziej skomplikowany niż zwyczajne import “library”.
3. Transpilacji. Wiele nowoczesnych kodów JS pisze się w różnych językach – na przykład w TypeScript. Nawet czysty JS wymaga transpilacji do obsługi starszych przeglądarek lub wykorzystywania najnowszych funkcji języków.

Z tych względów większość projektów wykorzystuje narzędzia typu JS bundler, czyli swego rodzaju kompilatorów, które przygotowują build na poszczególne wdrożenia. Jeśli zaciekawił Cię temat bundlerów, daj znać w komentarzu i sprawdź poniższe linki.

Linki

• [Repozytorium przykładów] (https://github.com/how-to-js/es-modules),
• [wszystkie przykłady] (https://how-to-js.github.io/es-modules/),
• [mój wideokurs na temat esbuild] (https://bit.ly/esbuild-course),
• [mój wideokurs na temat webpack] (https://bit.ly/esbuild-course.)

Podsumowanie

W niniejszym artykule omówiłem istotne przypadki użycia modułów ES. Kolejnym krokiem będzie skonfigurowanie JS bundlera tak, aby obejść ograniczenia modułów natywnych.

masz pełne prawo wątpić w jakikolwiek sens ich pisania. Poniżej przedstawiam powody, dla których jednak warto je pisać.

Czym są testy jednostkowe?

Testy jednostkowe to proste skrypty, które sprawdzają, czy dana jednostka – klasa, funkcja, moduł itd. – działa tak, jak powinna. Powinny być raczej nieskomplikowane i obejmować szczęśliwą ścieżkę (happy path) kodu plus garść przypadków brzegowych, czyli tzw. edge cases. Z powodów opisanych poniżej przyczyniają się one do sukcesu projektu.

Przyspiesz testowanie w trakcie programowania

Kiedy zaczynasz zajmować się budowaniem aplikacji, testowanie kodu z poziomu interfejsu użytkownika wydaje się rozwiązaniem całkowicie normalnym. Proces ten może stać się jednak szybszy i mniej zawodny po napisaniu skryptu, który będzie sprawdzał kod za Ciebie. Gdy już przygotujesz takie testy, uruchamianie ich raz za razem nie będzie wymagać żadnych dodatkowych procesów myślowych; możesz je przeprowadzać tak często, jak tylko chcesz. Przeprowadzanie testów prowadzi też do skrócenia pętli sprzężenia zwrotnego, co ułatwi Ci skupienie i poprawi produktywność.

Odkryj przypadki brzegowe

Pisanie testów jednostkowych od razu przywodzi mi na myśl przypadki brzegowe – wszystkie sytuacje, które występują rzadko, są nieoczekiwane lub po prostu błędne. To normalne, że pisząc logikę, skupiasz się na ścieżce happy path, czyli na tym, co typowe i co ma się wydarzyć. Pisząc testy, możesz wprowadzić kontrole przypadków brzegowych i określić, co ma się dziać, gdy wystąpi którykolwiek z nich. Dzięki temu Twój kod będzie odporniejszy na wszelkie nieoczekiwane scenariusze.

Upewnij się, że Twój kod składa się z jednostek

Podczas dodawania testów jednostkowych do kodu zobaczysz, co jest łatwe do przetestowania, a co przetestować jest trudniej. W miarę rozrastania się kodu i zwiększania jego poziomu skomplikowania korzystanie z testów zmusi Cię do dzielenia kodu na łatwe do zarządzania elementy. To świetna sytuacja – dzięki temu Twój kod osiągnie jeszcze lepszą jakość. Każdy segment, któremu przypisano zbyt dużo odpowiedzialności, będzie wymagał wykładniczo więcej testów jednostkowych. W takich przypadkach dobrze jest zatrzymać się na chwilę i przemyśleć, jak zorganizować logikę.

Interaktywna dokumentacja

Testy staną się dodatkowym zasobem dla osoby, która będzie pracować na kodzie po Tobie: dzięki nim dowie się, jaki jest cel kodu i jak ma on działać. To tak jakby dodatkowa dokumentacja z bonusami:

1. Testy są często bardziej precyzyjne niż opisy znajdujące się we właściwej dokumentacji.
2. Testy można przeprowadzać na kodzie w aktualnej wersji, aby upewnić się, że wszystkie instrukcje pozostają prawidłowe; w procesie czytania, rozumienia i sprawdzania kodu nie musisz polegać na człowieku.

Zabezpieczenie dla przyszłych zmian

Testy jednostkowe wykonują się tak szybko, że jedynym sensownym podejściem jest uruchamianie ich po każdej aktualizacji niezależnie od tego, jak mała się ona wydaje. Istnieje możliwość ustawienia w swoim repozytorium kodu ciągłej integracji (CI) tak, aby akceptował on tylko te zmiany, które przejdą wszystkie testy z wynikiem pozytywnym. Dzięki temu zapewnisz niczym nie zaburzoną integrację zmian bez względu na wprowadzane zmiany:

• drobne aktualizacje, które „nie powinny niczego zepsuć”,
• aktualizacje zewnętrznych bibliotek,
• szybkie i nie do końca precyzyjne próby wprowadzenia niewielkich zmian.

Testy jednostkowe chronią kod źródłowy przed wszelkimi niewielkimi regresjami, które objęte są ich zakresem.

Podsumowanie

Testy jednostkowe są kluczowym elementem utrzymywania kodu na wysokim poziomie. Można je traktować jak jedną z nóg metaforycznego stołu:

nogę tę można oczywiście wyjąć, ale przez to stół będzie mniej stabilny. Zajmij się ich pisaniem, a pomogą Ci otrzymać wysoką jakość kodu i zwiększą bezpieczeństwo Twoich aplikacji.