Siedzisz godzinami nad kodem i w końcu następuje ten moment - logika zaczyna działać…Ale…kod wygląda, grzecznie mówiąc, źle. Co masz w tym momencie zrobić? Z pomocą przychodzi optymalizacja kodu. Jeśli nie jesteś fanem tej czynności, to zachęcam jednak tego się nauczyć, bo pracując w zespole zaoszczędzisz sobie sporo czasu oraz nerwów. Przy odpowiedniej optymalizacji kodu o niebo łatwiej jest wprowadzać zmiany, tworzyć nowe funkcje bądź zwyczajnie zrozumieć cele projektu.

Dziś podzielę się z Tobą dwoma przypadkami, które pokazują, że nawet przy wydawałoby się ładnym kodzie, zawsze znajdzie się miejsce na optymalizację.

Case 1.

Pewnie kojarzysz sytuację z poniższego screena. Stworzyliśmy sobie jakiś szkielet w HTML’u i musimy się do niego jakoś się dostać z poziomu JS-a. Na pierwszy rzut oka nie ma nic złego w przedstawionym podejściu. Jednak po głębszym zastanowieniu, można zauważyć, że ciągle mamy pole do optymalizacji.

Po pierwsze, najpierw wyciągamy z HTML-a kontener, zawierający inne elementy (w naszym przypadku form). Po co więc kazać JS-owi jeszcze raz przeczesywać cały dokument w poszukiwaniu tych elementów skoro wiemy, że one będą dokładnie w tym kontenerze? Wprowadzamy zatem odpowiednie zmiany do kodu:

Dzięki temu otrzymujemy dwa bonusy:

• Lepszy performance;
• Mniejsze ryzyko złapania elementu o takim samym selektorze z innego miejsca w dokumencie;

Idąc dalej, na ten moment doskonale wiemy, że wybrane przez nas selektory są obecne w DOM-ie, przecież przed chwilą sami je tam dodawaliśmy. To prawda, ale musimy pamiętać o tym, że kod się zmienia i za parę miesięcy ktoś może zmienić lub usunąć te elementy. Z tego powodu powinniśmy zwalidować, czy pobrane elementy nie są nullem. Jeśli tak, powinniśmy jak najszybciej to wyłapać czyli wykorzystać zasadę ‘fail fast’, która polega na tym, że błąd poprawiamy od razu. W tym przypadku pisanie 4 if-ów nie wchodzi w grę, dlatego stworzymy sobie małą funkcje walidującą.

Już prawie jesteśmy w domu, tylko jak teraz zastosować się do pierwszej rady? Dodajemy sobie kolejny argument z domyślną wartością wskazująca na ‘document’ (można też się zastanowić nad zamianą dwóch argumentów w jeden obiekt). Zabezpieczamy się walidacją, dodajemy szczyptę TS’a i viola!

Oczywiście moglibyśmy to ulepszać dalej, wyciągnąć if-y do osobnych funkcji lub klasy z metodami statycznymi, ale zatrzymajmy się w tym miejscu i przejdziemy do kolejnego przykładu 🙂

Case 2.

Mamy sobie 3 różne buttony, z których każdy wykonuje inną akcję. Jeden dodaje artykuł, drugi usuwa, trzeci edytuje. Skorzystaliśmy z poprzedniej funkcji, żeby ułatwić sobie życie.

Pewnie myślisz, co znowu jest źle? Otóż zauważ, że wszędzie robimy to samo: znajdź element, dodaj nasłuch. Nic nie stoi na przeszkodzie, żeby wyciągnąć esencję naszego zadanka. Stworzymy sobie tablicę ze wszystkimi potrzebnymi danymi, a dalej to już GG easy.

‍

Teraz, gdy będziemy musieli dodać kolejny przycisk, wystarczy stworzyć kolejny obiekt, a reszta wykona się sama! Co więcej, nazwaliśmy nasze funkcje i przez to czytelność kodu się poprawiła (pamiętaj funkcja musi mieć czasownik w nazwie!).

Oczywiście do wyciągania takich wniosków potrzeba trochę doświadczenia i czasu. Na początku nauki skup się głównie na tym, żeby coś po prostu "działało", ale z biegiem czasu warto wejść na bardziej zaawansowany level “działa, wygląda i jest zoptymalizowane”.

Dzięki i zachęcam do zadawania pytań na fan-page’u Akademii.

Chcesz wejść na wyższy level i skorzystać z wsparcia mentora, który naprowadzi Cię na odpowiednie rozwiązanie? Zacznij od wypełnienia ankiety. Skontaktuje się z Tobą odpowiednia osoba. Podczas niezobowiązującej konsultacji wytłumaczy, jak dokładnie przebiega nauka w Akademii, odpowie na Twoje pytania i pomoże w podjęciu decyzji :)

‍