kodowanie

2×5 zasad poprawnego tworzenia oraz rozwijania aplikacji w Laravelu

5 zasad by Rafał

Zanim wybierzesz paczkę, przeczytaj dokumentację oraz sprawdź jej jakość

W obecnych czasach programista nie musi tworzyć wszystkiego od samego początku. Dzięki GitHubowi i całej społeczności programistycznego środowiska interesujące nas rozwiązania problemów w danej technologii. Jednak wybór paczki nie jest taki oczywisty. Nie wszystkie rozszerzenia mogą być dobre dla rozwiązania Twojego problemu.

Przykład z życia wzięty: Jeśli w przeszłości w swoich aplikacjach pisanych na Laravelu korzystałeś z rozwiązań Spatie, zapewne wiesz, że zazwyczaj są one wysokiej jakości, repozytoria są zawsze aktualne, a wsparcie stoi na wysokim poziomie. To dobrze! Jednak niekiedy dane rozwiązanie może kompletnie nie pasować do rozwiązania konkretnego problemu.

I tak jak w naszym przypadku doskonale sprawdziła się paczka Laravel Permission, tak wybór paczki do obsługi mediów stał pod znakiem zapytania, bowiem Laravel Media Library nie do końca pasował do pomysłów, które mają zostać zrealizowane w pisanych przez nas aplikacjach.

Laravel Media Library, jak wskazuje dokumentacja i dyskusja na Github issues, nie oferuje przypisywania Mediów w relacji polimorficznej wiele do wielu. Taka relacja daje absolutną dowolność w przypisywaniu wgranych plików do modeli zdefiniowanych w naszej aplikacji, co było wymagane przez naszych klientów. Zdecydowaliśmy postawić na nieco mniej popularną paczkę, jednak wskazaną przez Spatie jako alternatywę, Laravel Mediable, dzięki czemu uniknęliśmy dość dużego refactoru.

To tylko jeden z przykładów, jak dobór paczki wpływa na cały proces rozwijania aplikacji. Czytaj dokumentację, nie uzależniaj swoich aplikacji od wątpliwych zależności, a pozwoli to uniknąć wielu problemów.

Tworząc komunikaty zwrotne, zawsze stosuj translacje

Zapewne zadajesz sobie pytanie: “Mam projekt tylko na angielski rynek, to po co mam sobie zaprzątać głowę translacjami?”. 

Otóż moja odpowiedź brzmi: warto to robić. Z jednego powodu – wszystkie komunikaty i treści, które są pisane z palca i leżą rozsiane po całym projekcie są trudne w utrzymaniu. Nie jesteśmy w stanie w łatwy i szybki sposób dostać się do nich, musimy szukać i liczyć na to, że nam się uda. Jeśli będziemy trzymać translacje i pliki językowe w jednym miejscu, w ciągu kilku minut dostarczymy klientowi wszystkie komunikaty zwrotne, których użyliśmy w naszym projekcie.

Warto to robić również dlatego, że klient czasem zmienia swoje zdanie, z różnych względów  decyduje się na ekspansję na rynki, na których używa się odmiennych języków niż ten pierwotny.

Korzystaj z dedykowanych rozwiązań Twojej technologii

Ekosystem w obrębie danej technologii sprawia, że chcemy z nią obcować jak najwięcej. I tak się dzieje w przypadku Laravela. Mamy do dyspozycji szereg dedykowanych rozwiązań – zarówno tych oferowanych przez autorów Laravela, jak np. Laravel Forge czy Envoyer.io, po te, które oferuje nam społeczność.

I tak pewnego dnia, gdy przeglądałem Laravel News, natrafiłem na całkiem nieźle zapowiadające się narzędzie do debugowania aplikacji Laravela (ale i nie tylko) RAY. Po szybkim teście tego narzędzia zdecydowałem się je kupić. W moim przypadku sprawdziło się doskonale. Debugując aplikację w Laravelu, nie zawsze chcemy poświęcać mnóstwo czasu na konfigurowanie xdebuga, aby działał w różnych warunkach (kolejki, testy, itp.). Z drugiej strony, “printowanie” tego, co zawiera zmienna za pomocą dd(), bywa czasem uciążliwe.

ZOBACZ TEŻ: Czego słuchają programiści podczas kodowania? TOP 10 playlist

ZOBACZ TEŻ:  Kod zamknięty na modyfikację, a otwarty na zmiany. Jak zbudować okno ustawień?

Aplikacja RAY oferuje dużo więcej aniżeli dd(). W przypadku Laravela mamy do dyspozycji skorzystanie z wielu dedykowanych funkcji, dzięki czemu debugowanie stało się dużo przyjemniejsze. Nieco więcej o aplikacji RAY opowiem już niedługo podczas krakowskiego meet-upu związanego z Laravelem – Web Artisans, który to mam okazję współorganizować wraz z Karolem i Agnieszką, odpowiedzialną za koordynowanie całego wydarzenia. Dzięki nim oraz wsparciu inicjatywy przez firmę Webchefs, w której obecnie pracuję, już teraz wiem, że event będzie stał na wysokim poziomie merytorycznym i organizacyjnym. Serdecznie zapraszam wszystkich zainteresowanych!

Testuj automatycznie i mądrze

Testy automatyczne są niezwykle pomocne w procesie wytwarzania oprogramowania. Dzięki nim możemy w przyjemny sposób najpierw rozwijać kod aplikacji, a później go utrzymywać. 

Jeśli nasza aplikacja jest dobrze otestowana, to dzień deploymentu aplikacji staje się praktycznie bezstresowy, bowiem większość złych rzeczy, która miałaby się wydarzyć, pojawiła się już na etapie testów automatycznych.

Jednak testy, które są nieprzemyślane i napisane błędnie, niosą pewne zagrożenie. Przykładowo: mamy za zadanie przetestować listę stron statycznych zawierających unikalny tytuł strony oraz treść strony. Korzystając z laravelowskich faktorek i Faker’a, w naszym teście możemy zamockować wiele stron statycznych. Jeśli w naszym teście “zamockujemy” na raz 100 stron statycznych i błędnie zdefiniujemy naszą faktorkę, zapominając o unikalności tytułu, test raz na jakiś czas będzie błędny ze względu na niemożność dodania takiego samego wpisu do naszej bazy danych. Nie chcemy tego w naszych aplikacjach – test musi być napisany dobrze, nie może być zależny od tego typu czynników.

Uważaj na nadmierny eager loading

Eager loading jest fantastyczny. Jednak czasami nie jest wskazany, bowiem nieprzemyślany może być trudny w utrzymaniu i może spowolnić naszą aplikację.

Uważaj zwłaszcza na domyślny eager loading, który w eloquentowym modelu można zrealizować bardzo szybko za pomocą propetki $with. Dzięki tak zdefiniowanemu eager loadingowi przy każdym zaciągnięciu danych o danej encji pociągniemy także jego relację. Czy aby na pewno zawsze chcemy, by tak było? Zastanów się dwa razy, nim to zrobisz.

W niektórych przypadkach zastosowanie eager loadingu może być zdecydowanie mniej mniej wydajne od innych rozwiązań. Przetestuj alternatywne możliwości i zdecyduj.

Reasumując

Należy pamiętać, że powyższe porady stanowią jedynie wierzchołek góry lodowej problemów napotkanych w naszych karierach. W Webchefs stawiamy duży nacisk na jakość i optymalizację aplikacji. Więc jeśli zrozumieliście istotę powyższych błędów, problemów czy złych praktyk i zgadzacie się z wnioskami to czekamy na wasze CV.

Chcesz dowiedzieć się więcej? Zapraszamy na meetup Web Artisans Kraków Laravel Group, na którym to można będzie porozmawiać bezpośrednio zarówno z autorami artykułu, jak i pozostałą załogą Webchefs Software House. 

Zdjęcie główne pochodzi z unsplash.com.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
tomasz nowakowski fullstack
Szybki wzrost umiejętności zawdzięczam głównie pracy „po godzinach”. Wywiad z Tomaszem Nowakowskim