kodowanie

2×5 zasad poprawnego tworzenia oraz rozwijania aplikacji w Laravelu

Nie jest tajemnicą, iż każdą aplikację można napisać na wiele sposobów… i w sumie to bardzo dobrze. Gdyby było inaczej, to proces tworzenia oprogramowania straciłby na przyjemności, ciekawości, a czasem też i tajemniczości. Ale po drodze często przydarzają się błędy. Jak się ich ustrzec? Opowiadają Karol Pietruszka i Rafał Migda z Webchefs.

Karol PietruszkaKarol Pietruszka. Urodzony dokładnie ćwierć wieku temu. Programista, pasjonat, początkujący prelegent oraz blogger. Współorganizator krakowskiego meet-upu o Laravelu – Web Artisans. Obecnie oddaje się jednemu ze swoich hobby w Webchefs w Krakowie. Wielki fan technologii oraz ekosystemu Apple. Chociaż jego konikiem jest PHP i Laravel to aktualnie ma na tapecie Typescript, Vue, troszkę Angular, a nawet Swift. Wyznawca twierdzenia “jeżeli nie idziesz do przodu to się cofasz”.

Rafał Migda

Rafał Migda. Senior Full-Stack Developer w firmie Webchefs. Pasjonat relacyjnych baz danych i rozszerzeń wspierających zapis danych geograficznych, takich jak PostGIS. Współorganizator krakowskiego meet-upu o Laravelu – Web Artisans. Od kilku lat silnie związany z technologiami Laravel i Vue.js. Prywatnie szczęśliwy mąż i świeżo upieczony tata. 


Mnogość dróg prowadzących do rozwiązania problemów lub realizowania zadań często może stwarzać zagrożenie. Może być tak, że jedna z nich (lub z więcej) wyprowadzi nas w pole i utrudni powrót na właściwą ścieżkę lub – co gorsza – całkowicie ją uniemożliwi. Jako że oboje już z niejednego pieca chleb jedliśmy i niejeden feature poczyniliśmy, to możemy się poszczycić (a czasem i powstydzić) dokonanych wyborów, które z całą pewnością ułatwiły i przyspieszyły proces podejmowania coraz lepszych decyzji. Postanowiliśmy więc zebrać po pięć zasad, które – według naszych spostrzeżeń – były najczęściej naginane, jeśli chodzi o nasz bądź odziedziczony kod korzystający z frameworka Laravel.

5 zasad by Karol

Staraj się ponownie używać swojego kodu

Zacznę może od dość trywialnego zagadnienia, który doczekał się swojego akronimu w świecie twórców oprogramowania, tj. DRY (Don’t Repeat Yourself). Założę się, że gdy czytacie o rzekomej oczywistości rozpatrywanego problemu, na twarzach wielu z was maluje się uśmiech lub grymas. Tak, ja też należę do tego grona – bowiem DRY uważam za jedną z najświętszych zasad wytwarzania kodu.

Przyjmijmy, że dowiedzieliśmy się od naszego PM-a o nowym projekcie. Zatem nadchodzi dzień rozpoczęcia prac nad nim i okazuje się, że nowy to on jest tylko z nazwy… Ale to nic, bo do zrobienia jest mała poprawka wysyłki powiadomień o rejestracji nowych gości do dodatkowej grupy pracowników, aby mogli oni rzeczonych nowych gości obsłużyć. Siadamy więc do ulubionego IDE, odnajdujemy kawałek kodu, modyfikujemy go, a następnie testujemy. Wszystko gra i tańczy, zatem git commit i poszło!

Następnego dnia okazuje się, że jednak nie do końca zagrało i zatańczyło, bowiem powiadomienia dotarły do nowej grupy ludzi… ale w wyniku jednego ze zdarzeń, jakim jest rejestracja standardowa, natomiast powiadomienia nie zostały rozesłane w wyniku rejestracji za pomocą social mediów. Zatem wybieramy się ponownie do edytora kodu, tym razem domyślając się pogwałcenia zasady DRY. Okazuje się, że zgodnie z naszymi obawami dodaliśmy kod rozszerzający grupę odbiorców tylko do jednego z dwóch bliźniaczo podobnych miejsc w aplikacji. Mając już na uwadze rodzaj napotkanego problemu, dokładamy i refaktoryzujemy w odpowiedni sposób brakującą w tym wypadku logikę, testujemy ponownie – i jest git, a zatem git commit i poszło!

Wydaje mi się, że przytoczony przykład brzmi znajomo dla wielu z was. Zatem powtórzmy: staraj się używać swój kod ponownie – honorując zasadę DRY 🙂

Korzystaj ze zmiennych środowiskowych wyłącznie wewnątrz katalogu z konfiguracją

Temat z pozoru prosty, bo w dokumentacji zawarty jest raptem w kilku zdaniach. Uważam jednak, że warto na niego dodatkowo uczulić, biorąc pod uwagę moje doświadczenia, a w nich wszystkie te env(..) radośnie umieszczane to w kontrolerach, to w serwisach lub jeszcze gdzie indziej. Wydaje mi się, że powodem popełniania tego błędu jest nieznajomość działania komendy cache-ującej konfigurację korzystającą ze zmiennych środowiskowych do pliku .php. Po odpaleniu takowej aplikacja w odpowiedzi na env(…) spoza katalogu konfiguracji zacznie raczyć nas null-ami.

Z doświadczenia wyniesionego z poprzednich firm oraz opowieści znajomych deweloperów wiem, że wiele systemów wdrażanych jest często po przysłowiowych łebkach na serwery staging-owe lub nawet produkcyjne. Nie stosuje się tam np. komendy optymalizującej działanie aplikacji, czego wynikiem jest uśpienie powyższego błędu. Uśpienie to słowo-klucz, bo bombka cały czas tyka, czekając na bardziej rozgarniętego programistę, który prawidłowo zaktualizuje deploy script o cache i tym samym zupełnie nieświadomie pozbawi jakąś usługę np. klucza do łączenia się z API, co będzie skutkowało błędem serwera i zdenerwowaniem użytkowników tej aplikacji.

ZOBACZ TEŻ: Gdy zauważam wątpliwe praktyki, włącza mi się czerwona lampka. Historia Bartosza Doszczaka

Używaj Form Requestów do walidacji

Tutaj krótko. Moim zdaniem jest to kwestia, która stała się niepisaną tradycją, szczególnie w gronie młodszych (stażem i doświadczeniem) programistów Laravela. Gdy przeglądam całkiem fajnie zapowiadające się repozytorium równie dobrze zapowiadającego się juniora, często trafiam właśnie na przeprowadzanie procesu walidacji wszędzie, tylko nie w Form Request-ach. Czar wtedy pryska, bo przecież dokumentacja podaje w bardzo przejrzysty sposób, co jest prawidłowym miejscem dla takiego kodu.

Więc drogi Czytelniku, jeśli uskuteczniasz sprawdzanie danych w kontrolerze bądź serwisie, to polecam udać się do ulubionej wyszukiwarki, wpisać tam “Laravel validation”, kliknąć najprawdopodobniej pierwszy link i delektować się nową i bardzo przydatną wiedzą.

Unikaj jak ognia mutowania danych w akcesorach

Na samą tylko myśl o podobnych “kwiatkach” włos się człowiekowi jeży na głowie. Chodzi tutaj o taką sytuację: wewnątrz metody pewnego modelu, która jest akcesorem, zmodyfikujemy (zmutujemy) dane w jakiejkolwiek innej części aplikacji (np. odwołując się do klasy serwisu celem pobrania danych, która to z kolei może zmienić stan odrębnego modelu). Praktyka taka wywołuje z czasem szereg problemów, czy to z debugowaniem, czy ogólnym utrzymaniem i rozwijaniem aplikacji. Bo przecież nikt z nas nie chce, aby program robił coś, czego mu nie każemy, pisząc kod. Jak to zwykle w życiu bywa, problem dostrzegamy dopiero wtedy, gdy sami go doświadczymy.

Pamiętam, jak kiedyś dostałem informację, że coś niepożądanego się dzieje w paru miejscach w apce. Usiadłem więc do debugowania kodu i siedziałem tak bite pół dnia, starając się powstrzymywać negatywne emocje, które towarzyszyły mi, gdy próbowałem wytypować winowajcę. Ale udało się – bug został namierzony i zabity. Znajdował się na piątym poziomie zagnieżdżenia wywołania rzeczonych akcesorów… To właśnie tego dnia nabrałem uprzedzenia do wszędobylskiego ich stosowania. 

Reasumując: jeśli modyfikujemy jakieś dane, zmieniamy stan modelów bądź je usuwamy to róbmy to w sposób możliwie jak najbardziej jawny i widoczny w wyraźnie wyznaczonych do tego miejscach 🙂

Nie dopuść do problemu n+1

Problem ten polega na wykonywaniu wielu zapytań o małe zbiory danych potrzebnych do zapytania nadrzędnego. Na przykład mamy użytkownika, który posiada relację do wielu swoich kont. Potrzebujemy pobrać 10 ostatnich użytkowników wraz z tymi relacjami. Wykonujemy więc proste query pobierające wspomniane dane. Następnie w resource odwołujemy się do nich dla każdego pobranego wcześniej użytkownika. Jak się okazuje, wykonaliśmy 20 zapytań zamiast dwóch lub trzech. Niby to niewiele więcej, ale przyjdzie czas, że będziemy potrzebować 100, 200 lub jeszcze więcej ostatnich użytkowników.

Teraz zapewne u wielu z was zapaliła się czerwona lampka pod tytułem “brak” lub “niedobór eager loading-u”, no i brawo, bo tym to w istocie jest. Zatem gdy będziemy poprawnie stosować eager loading, wyleczymy się z nadmiernej ilości zapytań. Należy też uważać, aby nie przesadzić, Rafał pisze o tej drugiej stronie medalu, jaką jest nadmierność eager loadingu.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Facebook wytoczy proces Stanom Zjednoczonym? Prasówka Technologiczna: 5.10.2019 r.