Kanał ATOM
Autor wpisu: matipl, dodany: 22.10.2014 17:53, tagi: php
Początkowo chciałem zrobić standardowe podsumowanie ostatniej konferencji PHPCon Poland. Po chwili zastanowienia uznałem, że tak naprawdę PHPCon Poland wyznacza trendy na następny rok na naszym polskim rynku PHP.
W moim mniemaniu liczą się obecnie tylko 2 frameworki – Symfony 2 oraz Zend Framework 2. Cała reszta nie jest warta uwagi. Jeśli Twoim zdaniem Sf2 lub ZF2 są za duże na Twój projekt – wykorzystaj tylko poszczególne komponenty jakich dostarczają, albo napisz coś własnego małego… i użyj komponentów od dużych braci.
Jednym z powodów przejścia GoldenLine na Symfony było wsparcie jakie daje firma, która stoi za frameworkiem, znajomość frameworku przez rynek (programistów) oraz jego dojrzałość rozumiana przez pryzmat mnogości komponentów, gotowych elementów. To prawda, że są to wielkie kobyły, bez włączonego opcache ani rusz, ale taki jest rynek…
Z powodu wejścia tak sporych frameworków między innymi zmienia się PHP jaki znamy. Do jądra nie tylko dochodzą nowe bajery, ale również trwa ciągła optymalizacja wydajności i zarządzania zasobami.
HHVM
Odważniejsi mogą spróbować HHVM, który „zastąpił” HipHopa i staje się coraz bardziej dojrzały. W tym momencie już 27 narzędzi/frameworków da się w pełni uruchomić z wykorzystaniem HHVM (m.in. laravel, doctrine2, composer, phpunit, twig). Wystarczy PHP w wywołaniu zastąpić HHVM i nic więcej nie trzeba robić co pokazał Mariusz Gil.
HHVM przyspiesza composera ponad 5x. Czas wywołań testów na standardowym bench.php są oszałamiające, HHVM potrzebuje tylko 0,26 s, gdzie te same operacje PHP (5.5.9) bez żadnego wsparcia wykonywał przez 1,44 s. Ale najważniejszą kwestią jest architektura aplikacji, pomyślenie w odpowiednim momencie o cache’u, bazie danych, zewnętrznych API, czy odpowiednim zastosowaniu Redisa. Dopiero w takim momencie możemy pomyśleć o HHVM, czy czekać na PHP-NG, które będzie domyślnym silnikiem w PHP 7.0.
xhprof i aktualizacje
Ale po co w ogóle coś usprawniać? Badania pokazały, że jeśli coś trwa mniej niż 100 ms nasz mózg uważa że jest to natychmiastowa operacja. Zacznijmy optymalizować, jeśli żądania trwają powyżej 100 ms.
Wtedy można skorzystać z xhprof, młodszego, lepszego brata xdebug’a, z którego naprawdę prosto się korzysta i równie prosto instaluje (np. w połączeniu z xhgui). Należy również pamiętać o aktualizacjach samego PHP. Przejścia na PHP 5.6 jeszcze nie zalecam z powodu zbyt młodego wieku, ale najnowsza wersja PHP 5.5 to obowiązek. To nie tylko nowe możliwości (np. generatory, finally, password_hash), ale również zwiększona szybkość.
Testy jednostkowe
Żeby móc rozpocząć jakiekolwiek optymalizacje czy refactoring kodu należy posiadać najpierw w aplikacji testy jednostkowe. Podstawowym problem zawsze wydaje się na początku brak czasu i brak budżetu, ale jak kolejny raz podkreślił Michelangelo van Dam tak nie jest. Testy jednostkowe to same plusy:
- natychmiastowy feedback w przypadku błędu
- test piszemy raz, korzystamy z niego przy każdym wdrożeniu
- o wiele prościej dokonać zmian w kodzie (refactoring)
- prościej analizować kod aplikacji (debug)
Pisząc unit tests należy tylko pamiętać, aby testować jak najmniejsze jednostki kodu (smallest unit-of-code). Powinniśmy testować warunek po warunku (condition by condition), a nie do końca skupiać się na liniach kodu w metodzie. Testy powinny nam przetestować przede wszystkim logikę aplikacji, a nie same dane. Jeśli posiadamy integrację z zewnętrznymi API (np. płatności), również powinniśmy przetestować punkty styku, ewentualnie wirtualizując odpowiedzi drugiej strony.
