Backend, Język programowania to tylko narzędzie

Odczarowujemy PHP – fakty, mity i plotki

kod php wyświetlony na ekranie

Skoro skusił Cię ten tytuł to znaczy, że albo jesteś zagorzałym fanem Javy, albo będziesz szukał tutaj argumentów, które przekonają Twojego szefa i kolegów, że to wcale nie jest taki zły język.

Programuję w PHP (i w Rubym, Pythonie, JSie, Lua) od 13 lat. Pamiętam czasy zamierzchłe – architekturę spaghetti, a nawet lasagne – warstwowy monolit oraz ravioli – mikroserwisy. Wracając myślami do przeszłości mogę z pełnym przekonaniem powiedzieć, że robiliśmy to wiele lat źle. Właściwie to nie wiedzieliśmy jak to robić, a informacje z Zachodu docierały rzadko lub wcale. Genezą tego problemu jest fakt, że nigdy nie braliśmy PHP na poważnie. “Przecież to język do robienia stronek” – grzmieli Javowcy, Pythonowcy i wszyscy, którzy nie napisali nawet linijki kodu w PHP.

Język tylko do “robienia stronek”?

Mówisz “PHP” i być może myślisz “Wordpress, Drupal, Joomla”, tymczasem nie jest to jego jedyne zastosowanie. Zanim przejdziemy do szczegółów i analizy tego, co potrafił PHP kiedyś i co potrafi teraz, skupmy się na krótkim przedstawieniu, kto używa PHP.

Chyba największą firmą, która używa PHP w 2022 r. jest Facebook. Mieli oni ogromny wkład w rozwój wydajnościowy języka. Zaczęli od swojej implementacji – HipHop for PHP. Był to translator PHP do C++ kompilowany przez GCC. Projekt został zastąpiony przez HHVM, czyli HipHop Virtual Machine, a z niego ewoluował nowy język – Hack, którego składnia opiera się o PHP. W czasie, gdy HHVM przeżywał swojego rodzaju hype, Symfony Framework było w pełni kompatybilne z tą implementacją interpretera. Jednak świat stanął na głowie wraz z wydaniem PHP 7.0 – różnice wydajności były praktycznie niezauważalne, porzucono więc utrzymywanie kompatybilności z HHVM w Symfony. Jedna firma to nie powód, by przestać hejtować “pehapa”? Skarbnica wiedzy o wszystkim – Wikipedia również go używa.

Zanim rozprawimy się z faktami i mitami na temat PHP, pomyśl też o progu wejścia “w technologię”. W PHP bierzesz interpreter (albo jakiś zintegrowany “one-click” serwer typu XAMPP), możesz napisać kod w notatniku, nic nie kompilujesz, otwierasz Firefoxa, wpisujesz “http://localhost/” i BANG! – działa. Każdy dzieciak jest w stanie napisać swoją niebezpieczną stronę WWW.

PHP jest niebezpieczny

A czy którykolwiek język jest? Problem nie tkwi w języku, a w nieumiejętnym jego używaniu. Faktem jest, że wiele internetowych poradników powinno zniknąć z Internetu. Jednak, czy w Javie nie da się zrobić SQL Injection? Oczywiście, że się da. W każdym języku się da.

Wiedziałeś, że 75% publicznie dostępnych stron w internecie jest obsługiwanych przez PHP (tak, tak – język do stronek). Są to miliardy wektorów ataku i różnych podatności wygenerowanych przez samych programistów. Ciężko zatem porównywać jabłka do gruszek, ponieważ język sam w sobie w ciągu ostatnich kilku lat nie zaliczył poważnej wpadki. Nie można tego oczywiście powiedzieć o popularnych paczkach 🙂

Sporą wpadkę, biorąc pod uwagę reputację i popularność, zaliczył pakiet PHPUnit służący do testów jednostkowych, gdzie możliwe było (przy złej konfiguracji serwera WWW) uruchomienie zdalnego kodu. Dla chętnych wrażeń: klik.

Nie martwcie się jednak wszyscy zatroskani – pakiety dla Javy również zaliczają spektakularne wpadki!

Osobnym wątkiem bezpieczeństwa interpretera jest błędnie skonfigurowany serwer HTTP oraz interpreter PHP. Większość podatności wynika z tego, że proces interpreta był uruchomiony na użytkowniku z szerokim zakresem uprawnień (root? O zgrozo!) lub faktu, że serwer HTTP potrafił serwować pliki, których absolutnie nie powinien.

Werdykt: MIT.

W PHP o błędach mówi Ci klient, a w C++ kompilator

Skoro napisałeś/aś kod bez testów jednostkowych, integracyjnych czy end-to-end to nie dziw się, że o problemach mówi Ci klient. Poza statyczną analizą kodu, która w PHP wykluczy problemy wychwytywane przez kompilator, w każdym innym języku, czy jest to C, C++ czy Java, możesz popełnić błąd i wprowadzić swoją aplikację w nieoczekiwany stan, doprowadzić do jej błędnego, a czasem katastrofalnego zachowania.

Czy w innych językach nie da się doprowadzić do stanu, w którym w aplikacji odwołujesz się do klucza w słowniku, który nie istnieje? Oczywiście, że tak.

Werdykt: MIT.

PHP jest wolny/niewydajny

Możliwe, ale do czego go porównujemy, mówiąc, że jest niewydajny? Starsze wersje języka faktycznie nie grzeszyły wydajnością. Jednak z czasem pojawiły się APC i Opcache – to był game changer’y dla PHP. Kod przyspieszył wielokrotnie przez cache’owanie kodu w pamięci operacyjnej. Oczywistym jest, że nie możemy porównywać PHP do C, bo PHP został napisany w C. Niemożliwym byłoby to, że PHP byłoby szybsze od C. Jednak na tle języków interpretowanych PHP nie wypada aż tak blado, jak większość sobie wyobraża. Zespół odpowiedzialny za Benchmarks Game zrobił interaktywne porównanie czasu wykonywania popularnych algorytmów w językach Java, JavaScript, PHP, Python i Ruby. Zainteresowanych odsyłam do porównania.

Werdykt: PLOTKA.

Próg wejścia w PHP jest niski, przez co większość kodu jest słabej jakości

Wystarczy kilkanaście minut, by napisać swoje pierwsze hello world i uruchomić je w przeglądarce. Takie było również założenie samego autora PHP – ma być prosty i zastępujący skrypty Perla do budowy stron WWW. Pierwsza wersja PHP nazywała się PHP/FI – Personal Home Page/Forms Interpreter. Biorąc ten fakt pod uwagę i niesamowitą popularność języka, trudno się nie zgodzić z tym zarzutem.

Werdykt: FAKT.

Kod wygląda nieciekawie

Bardzo często spotykam się z taką opinią, jest ona ściśle połączona z punktem wyżej – progiem wejścia i doświadczeniami oceniających. Załóżmy hipotetyczną sytuację, w której programista dostaje od swojego kuzyna zlecenie dołożenia jakiegoś komponentu w stronie napisanej przez studenta za równowartość marketowej whisky. Nie wróży to kodu z testami jednostkowymi, architekturą heksagonalną i stosowaniem się do dobrych praktyk.

PHP już od bardzo dawna wspiera przestrzenie nazw, zaawansowaną obsługę wyjątków, funkcje anonimowe, statyczne typowanie i wymuszanie go na poziomie kodu. Faktem jest, że programiści, którzy znają C++ czy Javę będą narzekać na braki w języku – brakuje tu szablonów, wielodziedziczenia, przeciążania metod i operatorów.

Osobnym tematem, którym należałoby się zająć, jest jednowątkowość. W ramach obsługi żądania użytkownika jest jeden wątek, w którym obsługujemy klienta. Istnieją dwa rozszerzenia do PHP, które pozwalają na obsługę wątków, jednak najbardziej popularnym sposobem zrównoleglania i wysyłania zadań w tło jest używanie kolejek, co jest popularne również w językach, które wątki natywnie obsługują.

Zainteresowanych tematem standardów kodowania odsyłam do PHP Standard Recomendations, które jasno określają zbiór dobrych praktyk w trakcie programowania. Najpopularniejsze narzędzie do statycznej analizy kodu – PHPStan oczywiście implementuje wszystkie z tych standardów.

Werdykt: PLOTKA.

Podsumowując, programiści PHP są poszkodowani przez przyklejoną łatkę “klepacza stronek” i słabego kodu. Mam nadzieję, że choć w niewielkim stopniu zmieniłem to spojrzenie. Na uwagę zasługuje ogromna i aktywna społeczność PHP, która rozwija frameworki i sam kod interpretera. Wsparcie społeczności międzynarodowej jest na bardzo wysokim poziomie. Jako wzorowo prowadzony projekt można wskazać Symfony Framework – niedowiarków zapraszam do przejrzenia kodu i sposobu prowadzenia samego projektu.

PS Jeżeli chcecie przeczytać “deep dive into PHP” – dajcie znać w komentarzu!

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

Software Architect w Tpay

W Tpay od ponad 3 lat, od początku swojej drogi zawodowej związany z e-commerce, płatnościami i wszystkim co kręci się dookoła handlu w internecie. Prywatnie - niecodziennej natury programista - golfista, motocyklista, stolarz i podróżnik.

Podobne artykuły

[wpdevart_facebook_comment curent_url="https://justjoin.it/blog/odczarowujemy-php-fakty-mity-i-plotki" order_type="social" width="100%" count_of_comments="8" ]