PHP służy nie tylko do tworzenia prostych stronek. Devdebata

Jak oceniasz bezpieczeństwo refaktorowania oraz innych głębokich modyfikacji kodu? Jakie są ograniczenia PHP? Jakie najczęściej pułapki czyhają na juniorów? To trzy z dziesięciu pytań w kolejnej odsłonie devdebaty, do której zapraszamy doświadczonych developerów. Tym razem postanowiliśmy porozmawiać z nimi o PHPie.

Odpowiedzi na pytania udzielili:

Łukasz Nowak. Programista PHP z zamiłowaniem do projektów ze skomplikowaną logiką biznesową. W PHP siedzi od 14 roku życia, od 5 lat realizuje z powodzeniem mniejsze i większe projekty dla szerokiej gamy firm. Obecnie w Assertis Ltd. pracuje nad specjalistycznymi rozwiązaniami sprzedaży biletów na rynku kolejowym w Wielkiej Brytanii. Oprócz PHP po rozpoczęciu pracy w Assertis swoje zainteresowania kieruje w NodeJS, a w wolnym czasie Golang.

Iwona JóźwiakPHP developer w Divante. Od 15 lat „żyje internetem” – pamięta erę IE 5. Ostatnie 5 lata ukierunkowała głównie na backend Magento. Za swoją najmocniejszą stronę uważa umiejętność łączenia technologii i biznesu. Ponadto należy do grupy certyfikowanych developerów „Magento Developer Plus„. Dziś bardziej reprezentuje grupę backend developerów, jednak wciąż, w miarę wolnego czasu lub ciekawych zadań w projekcie, stara się rozszerzać wiedzę frontendową.

Andrzej Precz. Back-end PHP Developer w Transparent Data. Odkąd półtora roku temu dołączył do zespołu Data&Services, każdy dzień zajmuje mu przyłączanie nowych źródeł i obmyślanie sposobów na pozyskanie danych nawet “zza zamkniętych drzwi”. Wcześniej, przez prawie dekadę, programował w serwisie Allegro.

 

1. Co najbardziej lubisz w PHPie?

Odpowiada Łukasz Nowak, PHP & NodeJS Developer w Assertis:

Bardzo dobra dokumentacja, duży wybór pakietów, prostota konfiguracji środowiska. A przede wszystkim to, że język ten pomimo dużej krytyki naprawdę daje radę. Miałem okazję widzieć aplikacje, które dźwigały naprawdę bardzo duży ruch od strony użytkowników i wcale nie jest tak, że język ten służy tylko do tworzenia prostych stronek, stawiania wordpressów itp. Można na nim zbudować pełnoprawnie działające aplikacje, przetwarzające nawet terabajty danych. Język to tylko narzędzie, a PHP to w rękach dobrego programisty bardzo potężne narzędzie.

Odpowiada Iwona Jóźwiak, Senior PHP & Magento Developer w Divante:

Szeroko pojęta różnorodność. Skłamałabym, gdybym powiedziała, że “internet” stoi na PHP, jednak ma on w nim swój spory udział. Można w nim realizować proste stronki, ale i portale, e-commerce i ogromny CRM-y i ERP-y. Z powodzeniem można też w nim tworzyć webservice’y.

Odpowiada Andrzej Precz, Senior PHP Developer w Transparent Data:

Da się w nim bardzo szybko napisać małe skrypty do prostych zadań. Da się szybko napisać serwis internetowy, zarówno na froncie, jak i w backendzie. PHP będzie “dawał radę” nawet gdy aplikacja rozrośnie się do bardzo dużych rozmiarów. Szybkość tworzenia i skalowalność — to właśnie najmocniejsze strony tego języka.

2. Z drugiej strony, co najbardziej wkurza Cię w PHPie? Jakie są jego ograniczenia?

Odpowiada Łukasz Nowak, PHP & NodeJS Developer w Assertis:

Pewnie jak wielu programistów uważam, że dużym problemem PHP jest to iż jest to język interpretowany, przez co często wiele błędów pomimo dobrych testów występuje w późniejszym etapie życia aplikacji. Są oczywiście na to rozwiązania w postaci choćby HHVM, powoli pojawiają się głosy, że do następnych wersji PHP zostanie wprowadzony tzw. JIT (Just in time compilation).

Dużym ograniczeniem jest też wielowątkowość, która niby istnieje jednak w wielu nowszych językach jak choćby w Golang przy pomocy goroutines jest rozwiązana w dużo lepszy sposób.

Odpowiada Iwona Jóźwiak, Senior PHP & Magento Developer w Divante:

Najbardziej smuci mnie fakt, że język ten wciąż jest wolniejszy od języków kompilowanych i to, że wybacza za dużo. Można wymusić typowanie danych, korzystanie z interface’ów. Jednak zawsze można to wszystko ominąć sprawnie “work around’em”. Bardzo łatwo też kod “wykraść”. Istnieją zabezpieczenia w postaci np. ioncube, jednak dostępne są również mechanizmy, które potrafią taki zabezpieczony kod odkodować, co sprawia, że można z niego korzystać w sposób nieautoryzowany.

Administratorzy także bardzo ubolewają nad koniecznością utrzymywania wielu wersji PHP, które są w trakcie rozwoju. Jeśli już o wersjach mowa to trzeba pamiętać, że skrypty wykonywane w CLI mogą korzystać z innej wersji PHP, jeśli hosting nie został poprawnie skonfigurowany. Wielu też chciałoby w CLI używać polecenia “php” i równolegle na hostingu mieć kilka wersji, z których każda ma inną konfigurację, co ostatecznie powoduje niezłe zamieszanie. Na to wszystko nakłada się krótki czas wsparcia każdej wersji.

ZOBACZ TEŻ:  Jak efektywnie pracować na home office? Devdebata

Odpowiada Andrzej Precz, Senior PHP Developer w Transparent Data:

Po pierwsze, szybkość języka w porównaniu z innymi dostępnymi obecnie na rynku, choć to znacznie się poprawiło od “siódemki”. Po drugie, luźne typowanie parametrów czy porównywanie za pomocą operatora equal (==) może wprowadzić wiele zamieszania i trudnych do zdebugowania błędów. Niektórzy się śmieją, że PHP i starą oponę przerobi na zero.

Po trzecie, zdarza się, że w nawet z pozoru banalnych sytuacjach i doświadczony programista PHP nie będzie wiedział jak zachowa się kod. Dla przykładu, sensowne i intuicyjne jest, że true zostanie zwrócone przez empty(“”) lub empty(0), ale że przez empty(“0”) już takie oczywiste nie jest i nigdy nie wiadomo kiedy i jak boleśnie się na czymś takim przewrócimy.

3. Jakbyś porównał wysiłek programowania do wysiłku debugowania aplikacji napisanej w PHPie?

Odpowiada Łukasz Nowak, PHP & NodeJS Developer w Assertis:

Wysiłek włożony w zaprogramowanie aplikacji zależy od poziomu skomplikowania logiki biznesowej, to samo dotyczy wysiłku włożonego w debugowanie. Bardzo skomplikowana logika biznesowa kosztuje programistę dużo wysiłku, bo zamiarem każdego programisty jest napisanie kodu tak, aby łatwo dało się go modyfikować. Debugowanie aplikacji w PHPie może być proste lub trudne, zależy to od takich czynników jak logika biznesowa oraz to w jaki sposób programista zaimplementował tę logikę. Łatwość debugowania zapewnia też dość czytelny stacktrace, oraz to że kod interpretowany można uruchomić dość szybko.

Wielu programistów nie korzysta z debuggerów tylko dość często linijka po linijce wstawia kod wyświetlający zawartość zmiennych i zatrzymujący aplikacje, a następnie uruchamiają samą aplikację żeby zobaczyć, co jest nie tak.

Odpowiada Iwona Jóźwiak, Senior PHP & Magento Developer w Divante:

Ze swojej strony dodam, że najżmudniejsze jest debugowanie integracji. Zdarza się bardzo często, że brakuje środowisk sandbox’owych, na które można wysyłać bez strachu kolejne requesty i w prosty sposób generować responsy. Problemem też jest integracja lokalnych środowisk developerskich z zewnętrznymi systemami. To wszystko bardzo wydłuża pracę, a w razie wystąpienia błędu, jego usunięcie staje się drogą przez mękę. Dlatego też developerzy mocno “ologowują” wszelkie integracje. Oprócz wspomnianych debugerów, przydaje się też umiejętność przeszukiwania logów, gdzie znajdują się często miliony informacji. Jeśli więc miałabym porównać wysiłek programowania do debugowania w tym obszarze to często, by napisać 5 linijek kodu, muszę spędzić niestety kilka dni w poszukiwaniu błędu.

Odpowiada Andrzej Precz, Senior PHP Developer w Transparent Data:

Stopień skomplikowania debugowania jest odwrotnie proporcjonalny do czytelności kodu i wybór języka programowania nie ma tutaj znaczenia. Jeżeli kod jest nieczytelny, splątany i pisany byle jak, to odnalezienie i poprawienie błędu będzie mało przyjemne. Błędy w oprogramowaniu są i będą, bo programista jest i będzie je popełniać. Wskaźnik liczby defektów do 1 tysiąca linijek kodu (ang. 1 kLOC) można i powinno się minimalizować przeglądem kodu, testami i innymi technikami.

Badania pokazują, że w oprogramowaniu występuje średnio od kilkudziesięciu do kilku błędów na 1 kLOC. Do bardziej celowego poszukiwania błędów polecam rozszerzenie do PHP — xDebug. Dzięki niemu można celowo poszukiwać błędów, zastawiać pułapki w konkretnych warunkach, tworzyć tzw. breakpointy na konkretne typy wyjątków, etc. Możliwości są naprawdę przeogromne i każdy programista PHP powinien wiedzieć jak z tego korzystać, żeby nie debugować poprzez wstawianie “var_dump/die” w kodzie.

4. Jak oceniasz bezpieczeństwo refaktorowania oraz innych głębokich modyfikacji kodu?

Odpowiada Łukasz Nowak, PHP & NodeJS Developer w Assertis:

To już niekoniecznie zależy od języka. Jeśli mamy dobre pokrycie kodu testami można uznać, że wszelka refaktoryzacja jest bezpieczna i nie powinna popsuć działania aplikacji. Każda głęboka modyfikacja kodu wiąże się z jakimś ryzykiem, w PHP-ie łatwo nie zauważyć jakiś błędów kodu właśnie z powodu tego iż jest to język interpretowany o czym wspomniałem wcześniej, języki kompilowane pozwalają uniknąć wielu różnych problemów w czym mają przewagę nad PHP-em.

Odpowiada Iwona Jóźwiak, Senior PHP & Magento Developer w Divante:

Jestem tego samego zdania co Łukasz, że wszystko zależy od pokrycia kodu testami. Niestety, ale w wielu przypadkach testów po prostu brak. PHP to nie tylko zaawansowane CMRy i e-commercy, ale też zwykłe strony www i autorskie silniki portali, to też cała masa wordpressów. Z przykrością muszę powiedzieć, że mało kto w takich miejscach dba o TDD.

Odpowiada Andrzej Precz, Senior PHP Developer w Transparent Data:

Tu się zgodzę z poprzednikami, że większy wpływ na bezpieczeństwo poprawnego refaktoringu kodu ma jakość tego kodu, niż sam język programowania. Testy jednostkowe, krótkie metody, proste rozwiązania, intuicyjne nazwy zmiennych, należyta ostrożność przy stosowanych typach zmiennych czy parametrów (np. używanie operatora identical (===) zamiast equal (==), assertSame() zamiast assertEqual() w testach jednostkowych) na pewno zmniejszą ryzyko popełnienia błędów.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
AI wygeneruje niesamowity spam. Czy boty Google’a są gotowe?