Najczęstsze błędy początkujących programistów PHP

Najczęstsze błędy początkujących
programistów PHP
Jak ich unikać?
Praktyczne wskazówki
oraz przykłady realnego kodu

Kilka słów o mnie
Wojciech Pilich
Junior PHP Developer
@ DocPlanner Tech
(znanylekarz.pl)

Wojciech Pilich | PHPstok 28.07.2020 | Najczęstsze błędy początkujących programistów PHP 3
Rozkład jazdy:
Przykłady najczęstszych błędów
- omówienie
Case study (refactor kodziku)
- krok po kroku
Garść praktycznych pro tipów
- dla Was ode mnie

Przykłady najczęstszych błędów
Kto ich nie popełnia, ten się nie rozwija
Najważniejsze, by wyciągać z błędów wnioski/naukę
...i nie popełniać w kółko tych samych ;)

Uwaga na zdradliwe porównania
Docelowo staramy się
używać gdzie się tylko
da ścisłych porównań
(identyczności) ===
Uważajmy zwłaszcza
przy porównaniach
wartości boolowskich
Czasami jednak, luźne
porównanie == może być
pożądane. Np. przy
ustalaniu wartości ﬁltrów
pobieranych z zapytania
GET (przychodzą jako
string, a nie integer).
W przykładzie powyżej
luźne porównanie ratuje
nam skórę ;)

Globalny kontekst cz. 1
● Używanie bezpośrednio w kodzie zmiennych typu superglobal
np. $_POST czy $_SERVER jest zdecydowanie niewskazane,
● Zwłaszcza jeśli używacie jakiegoś frameworka,
● Zwykle frameworki mają doskonale opracowane wrappery i metody
wykorzystujące “pod spodem” te zmienne i dlatego nie ma sensu
np. w projekcie pisanym w Symfony wyskakiwać nagle w kodzie
z superglobalem ;) (masz do tego gotowe klasy np. Response
i Request),
● Co innego używanie metod statycznych (public static…) oraz
wzorca Singleton (prywatny konstruktor i wyłącznie jedna instancja
klasy). Sam wzorzec mimo, że nie jest polecany, to może okazać się
przydatny np. do stworzenia połączenia do bazy danych.

Globalny kontekst cz. 2
● Warto również pamiętać o prawidłowym deklarowaniu stałych
(zwłaszcza jeśli piszemy obiektowo i poruszamy w obrębie klas).
Zamiast: Lepiej użyć:

Nazwy zmiennych/metod/klas…
Mają znaczenie! cz. 1
● Nazwy zmiennych piszemy wyłącznie po angielsku, broń boże nie
miksujemy i nie tworzymy tego typu tworów:
function pobierzUseraZBazy()
● Staramy się pisać możliwie najbardziej deskryptywne i
samo-wyjaśniające nazwy, aby czytanie kodu było jak czytanie książki,
● Nazwy metod (funkcji) najlepiej żeby były czasownikiem lub
przymiotnikiem, a zmienne rzeczownikiem,
● Nazwy powinny być również możliwie krótkie, ale na tyle żeby jasno
oddawać sens tego co reprezentują,
● Nazwy klas piszemy zawsze z dużej litery, a stałe dużymi literami,
● Używamy najczęściej konwencji camelCase, choć PascalCase
i snake_case są oczywiście dopuszczalne.

Nazwy zmiennych/metod/klas…
Mają znaczenie! cz. 2
Zamiast:
Lepiej użyć:

Im mniej If’ów tym lepiej
i żegnamy else’a cz.1
Mamy prostą metodę sprawdzającą czy lekarz nie
przekroczył swojego limitu adresów.

Im mniej If’ów tym lepiej
i żegnamy else’a cz.2
Zamiast: Lepiej użyć:

Co za dużo parametrów
w metodzie to nie zdrowo cz.1
Mamy prostą klasę kwestionariusza
z 8 parametrami konstruktora...

Stwórzmy dodatkowe klasy do przechowywania danych o mieście
-> City, danych adresowych -> Contact itd.

I od razu życie staje się prostsze, nie dość, że nie łamiemy SRP,
to jeszcze mamy porządek.
Przyjmuje się, że 2-3 parametry są ok, starajmy się więc nie
przekraczać tej liczby w naszych metodach i funkcjach.

Case study
Obliczanie wartości faktora
dla użytkownika (klasa User) oraz klienta (klasa Client)
Refactor kodu - krok po kroku
-> od chaosu do porządku

Założenia biznesowe
Klasa User oraz Client reprezentują dwa obiekty
w naszej domenie.
Każdy z nich ma dwa podstawowe pola (cechy):
-> isPremium - informuje czy obiekt jest premium
(zwraca true lub false)
-> premiumType - informacja o rodzaju typu premium
(zwraca string)

Był sobie użytkownik i jego skromna,
modelowa klasa...

Był sobie również klient i jego skromna,
modelowa klasa...

Niby wszystko ładnie, ale...
kodzik jednak trochę “śmierdzi”.
Grzechy główne:
1. Hardkodowane stringi z typami premium
-> konieczność wprowadzania zmian w kilku miejscach w przypadku aktualizacji
wartości faktora i rozbudowania obliczeń
2. Cała logika obliczeniowa w jednej metodzie
-> problemy z czytelnością, zwłaszcza jeśli dojdą kolejne obliczenia, instrukcje
warunkowe itd.
3. Obliczanie faktora w modelu (kontekście klasy) samej siebie
-> klasa modelu zaczyna “puchnąć” i zawierać coraz więcej logiki biznesowej,
przez co wykracza poza swoją odpowiedzialność i staje się nieczytelny
oraz trudny w utrzymaniu.

To co, do dzieła!

Oddzielny serwis do obliczania
wartości faktora
Zamiast gromadzić logikę obliczania faktora
wewnątrz modelu, stwórzmy oddzielny
i odpowiedzialny wyłącznie
za obliczanie faktora serwis, czyli np. klasę
PremiumUserResolver

Ale zanim… połączmy najpierw nasze
klasy domenowe wspólnym interfejsem
Skoro wynieśliśmy metody obliczające wartość
faktora z klas User oraz Client i dodatkowo klasy te
posiadają identyczne pola: isPremium oraz
premiumType nic nie stoi na przeszkodzie, aby
obydwie implementowały interfejs obligujący je
do tych właśnie dwóch metod.

Tak może wyglądać
wspólny interfejs

A tak wyglądają odchudzone klasy
User i Client po spięciu ich interfejsem

To teraz stwórzmy odpowiednie
resolvery!

Docelowo resolver dla
klasy User mógłby
wyglądać tak:

A resolver dla klasy
Client np. tak:

Ok, wszystko fajnie, a co właściwie
się zmieniło?

Dzięki stworzeniu PersonInterface w łatwy
i bezpieczny sposób będziemy mogli obliczać
wartość faktora w “resolverach” dedykowanych
klasie User oraz Client.

Podobnie jak w przypadku klas
domenowych stworzyliśmy też interfejs
dla resolverów
Czemu nie, skoro obydwa resolvery
korzystają od teraz z nowej metody
factorFor()

Obliczamy wartość faktora
dla podanego w parametrze obiektu
zgodnego z PersonInterface
Dzięki temu mamy pewność, że wartość faktora
będzie obliczana wyłącznie dla jednego z dwóch
obiektów User bądź Client. To właśnie zapewnia
nam PersonInterface i dlatego korzystamy z niego
w metodzie factorFor()

Wydzielamy prywatną metodę
userHasGoldPremiumType()
Dzięki temu porządkujemy kod wydzielając
z głównej metody factorFor() logikę
odpowiedzialną za typ gold

Wydzielamy również prywatną metodę
userHasSilverOrNonePremiumType()
Dzięki temu porządkujemy kod wydzielając
z głównej metody factorFor() logikę
odpowiedzialną za typ silver oraz none

Prywatne metody pomocnicze
używamy potem głównej metodzie
obliczającej factorFor()

Przed Po
Bestia i piękna, czyli...

Dodatkowe smaczki
● Klasy resolverów są klasami final
-> skoro nie potrzebujemy tych klas potem rozszerzać
(bo i po co), to bezpieczniej jeśli będą klasami final
● Używamy declare(strict_types=1)
-> skoro używamy return typów (bardzo dobrze), to aby
mieć pełną kontrolę nad przepływem typów, lepiej dodać
ten parametr by czuć się w pełni bezpiecznie
i kontrolować co wchodzi/wychodzi z naszego resolvera.

Garść praktycznych pro tipów
ode mnie
Sam popełniałem i dalej popełniam błędy
Ale uczę się na nich i dlatego chciałbym powiedzieć Wam...
...o kilku fajnych rzeczach, które odkryłem pisząc kod ;)

IDE to Twój najlepszy przyjaciel cz.1
● Wykorzystanie dobrodziejstw środowiska i edytora potrafi
niesamowicie ułatwić i przyspieszyć pisanie kodu,
● Osobiście cały czas korzystam z PHP Storma - sprawdza się
świetnie, ma wszystko czego mi potrzeba (da się przeboleć to
że jest płatny),
● Warto poświęcić nawet kilka godzin/dni na zapoznanie się ze
swoim ulubionym edytorem i opanowanie jego funkcjonalności,
● W sieci znajdziecie bardzo wiele tutoriali na ten temat.
Naprawdę warto zainwestować w to czas.

IDE to Twój najlepszy przyjaciel cz.2
● Jeśli korzystacie z dockera/vagranta warto skonfigurować je
w swoim IDE,
● Wykorzystujcie skróty klawiszowe np. szybkie wyszukiwanie
(klasy, pliki, akcje), zastępowanie wyrażeń, multikursor itp.
● Bardzo przydaje się szukanie użyć i miejsca występowania danej
metody/klasy,
● Jeśli macie duży ekran, to warto również korzystać w IDE z
terminala (mega wygodne) a w przypadku PHP Storma z obsługi
bazy danych. Konfiguracja połączenia jest mega prosta. Dzięki
temu zyskacie podpowiedzi przy pisaniu sql-ek,
● Instalujcie i aktualizujcie często pluginy/dodatki oraz samo IDE.

Spersonalizowane wyjątki cz.1
● Nie bójcie się korzystać z bloków try/catch zwłaszcza
w newralgicznych miejscach aplikacji, gdzie w przypadku
niepowodzenia trzeba wyjść z twarzą ;)
● Nie zapominajcie o rzucaniu wyjątków, a żeby robić to jeszcze
lepiej stwórzcie własne klasy rozszerzające php-ową klasę
Exception lub inne bardziej generyczne klasy wyjątków np.
RuntimeException
● Własna i spersonalizowana klasa wyjątku powinna możliwie
najdokładniej opisywać zaistniałą sytuację błędu.

Bardzo fajna, własna klasa wyjątku może wyglądać mniej więcej tak:

A jej przykład użycia:
● W przypadku takiej klasy wyjątku, rzucamy ją bez użycia słowa
kluczowego new jak w przypadku ogólnej klasy wyjątku w PHP,
● Możemy też dodać do niej więcej publicznych metod statycznych
do obsługi innych przypadków np. dla innego rodzaju obiektu itp.

Jeszcze lepsze testy cz.1
● Pisanie testów jest cenne jak złoto, dzięki nim nie dość, że lepiej
zrozumiecie działanie kodu, to jeszcze poprawicie swoje skille
programistyczne,
● Warto pisać testy do każdego większego bloku kodu, który oddajecie,
a zwłaszcza tam gdzie występuje bardziej skomplikowana logika
biznesowa,
● Polecam używać po prostu PHPUnit albo Codeception (kombo
framework do testowania, pod spodem bazuje i tak na PHPUnicie).
Codeception jest genialne do testów API.

Używajcie data providerów
Dzięki nim oszczędzicie sobie pisania oddzielnych testów dla
każdej wartości testowanego argumentu.

Używajcie konwencji nazewniczej metod testowych:
given -> when -> then

Używajcie mądrze metody setUp()
Dzięki niej macie pewność, że przed wykonaniem każdego testu zainicjują
się niezbędne do testu klasy (trochę jak taki testowy konstruktor) :)

Używajcie gotowych klas
szablonowych typu mother
Dzięki nim unikacie powielania
w kółko w wielu testach kodu
tworzącego dany obiekt.
Od teraz możecie tworzyć obiekty
testowe dzięki publicznej metodzie
create() z dowolnego miejsca
Waszej aplikacji

Jeśli testujecie (tworzycie mocka) klasy typu final to
testujecie tak naprawdę jej interfejs. Jeśli go nie ma,
wówczas PHPUnit krzyknie na Was błędem.
Niezbyt dobrym wyjściem będzie zdjęcie z klasy słowa
final, w końcu świadomie (mam nadzieję) podjęliście
decyzję o nadaniu jej tego typu ;)
Dobra architektura oparta na przemyślanych
abstrakcjach powinna bez problemu dać się
przetestować.

To mock or not to mock? Czyli kiedy i które klasy
mockować, a które po prostu instancjonalizować?
● Najprostsza zasada mówi, że jeśli piszecie testy np. dla klasy User
wówczas testowany obiekt tworzycie “normalnie” przez słowo new
czyli np. new User(...) a jego metody używacie bezpośrednio na
nim np. user->getName()
● Natomiast pozostałe klasy od których Wasza klasa zależy np.
obiekty których wymaga w konstruktorze mockujecie np. tak:
$this->createMock(...)

I na koniec jeszcze jeden testowy tip
-> odpalajcie testy bezpośrednio z IDE (PHPStorm ma do
tego świetne narzędzie).

Przed wypchnięciem zmian do repo
warto pamiętać o...
● Odpaleniu testów Waszego kodu (jeśli je napisaliście) lub testów z
katalogu, w którym dokonaliście zmian (serio, czasem ratuje życie) ;)
● Domergowaniu (zrobieniu rebase) aktualnego brancha
developerskiego do Waszego brancha - zwłaszcza jeśli pisaliście
kodzik przez kilka dni lub jakiś czas czekał nieaktualizowany.
● Puszczeniu narzędzia sprawdzającego formatowanie Waszego
kodu (można to ogarnąć skrótem z poziomu IDE) - zwłaszcza jeśli
sprawdzane jest to podczas budowania w ramach CI/CD.

Trzymaj się dobrych manier
nowszego PHP
● Nie bój się używać declare(strict_types=1) oraz deklarować
możliwie wszystkie klasy jako final. Te dwa zabezpieczenia pozwolą
Ci od razu pisać bezpieczniejszy i bardziej przemyślany kod,
● Tam gdzie się da zastępuj ternary operator tzw. null coalesce
operatorem $x = $a ?? $b; znacznie lepiej się to czyta,
● Unikaj rozszerzania klas (extends), a używaj raczej abstrakcję
(implementacja interfejsów),
● Określaj typy zwracane metod oraz nadawaj typ ich argumentom
co w połączeniu ze strict_types=1 daje niesamowite kombo w kwestii
kontroli nad tym co dzieje się Waszej aplikacji.

Nie bój się i używaj Xdebug’a
● Dla wielu programistów PHP czasy wszechobecnych dump-ów,
a tym gorzej var_dump-ów przeminęły, a nastał Xdebug’a i jego
dobrodziejstw,
● Sam bardzo długo broniłem się przed tym narzędziem, głównie dlatego,
że przerażała mnie jego dosyć skomplikowana konfiguracja (nawet w IDE
mi to nie szło),
● To narzędzie znacznie ułatwia zrozumienie tego co się dzieje w kodzie,
możliwość zatrzymania się w dowolnym miejscu, obejrzenia kontekstu,
a zwłaszcza ewaluacji dowolnego wyrażenia w locie jest bezcenna.
● Obecnie nie wyobrażam sobie poruszania się po - zwłaszcza nieznanym -
kodzie bez Xdebug’a, choć czasem jeszcze zdarza mi się użyć starego
dobrego var_dump’a ;)

Chcesz porozmawiać lub omówić kod?
A może masz pytania?
Napisz do mnie:
wojciech.pilich@docplanner.com

Wojciech Pilich | PHPstok 28.07.2020 | Najczęstsze błędy początkujących programistów PHP
★ Artykuł “What does recruitment at Docplanner Tech really look like”
https://medium.com/docplanner-tech/what-does-recruitment-at-docplanner-tech-real
ly-look-like-6fe5a7ced14b
★ Artykuł “Rozprawiam się z największymi mitami o branży IT”
https://geek.justjoin.it/mity-it/
★ Zbiór ciekawych i praktycznych rad jak pisać dobry kod PHP
https://github.com/jupeter/clean-code-php
★ Świetny tutorial PHPStorma
https://laracasts.com/series/how-to-be-awesome-in-phpstorm
★ Aktualna rekrutacja na PHP developera w Docplanner Tech
https://apply.workable.com/docplanner/j/6F24AFA343/
55
Ciekawe linki:

Wojciech Pilich | PHPstok 28.07.2020 | Najczęstsze błędy początkujących programistów PHP
Q&A
56

Dziękuję :)

Najczęstsze błędy początkujących programistów PHP

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Najczęstsze błędy początkujących programistów PHP

Ähnlich wie Najczęstsze błędy początkujących programistów PHP (20)

Mehr von PHPstokPHPstok

Mehr von PHPstokPHPstok (13)

Najczęstsze błędy początkujących programistów PHP