Jedna z ostatnich prelekcji na jakiej zjawiłem się podczas zeszłorocznego PHPCon była poświęcona statycznej analizie kodu. Bardzo lubię ten temat ponieważ odpowiedni zestaw narzędzi zarówno na komputerze jak i na serwerze CI jest bardzo pomocny w utrzymywaniu kodu aplikacji w dobrej kondycji. Często okazuje się jednak, że nawet doświadczeni programiści nie stosują albo nawet nie wiedzą co to jest statyczna analiza kodu.

W tym poście mam zamiar opisać te najprostsze wg mnie narzędzia do statycznej analizy kodu PHP bezpośrednio wspomagające sam proces programowania. W drugiej części opiszę narzędzie zwane PHP_CodeSniffer, w trzeciej PHP Mess Detector. Ostatnią czwartą części tego postu opiszę narzędzia, które służą do analizy całych projektów lub wspomagają np. migrację projektu na inną wersję PHP. Zanim jednak zajmę się samymi narzędziami warto było by odpowiedzieć sobie na podstawowe pytanie…

… czym w zasadzie jest ta „statyczna analiza kodu”

Najprościej rzecz ujmując jest to analiza kodu bez jego uruchamiania. Statyczna analiza kodu jest przeciwieństwem dynamicznej analizy kodu. Przykładowo jeśli używasz Xdebug lub podobnego narzędzia stosujesz właśnie analizę dynamiczną. Dzięki (dynamicznej analizie kodu) można np zerknąć co znajduje się w konkretnej zmiennej, sprawdzić lub zdiagnozować, w którym miejscu aplikacja zużywa najwiecej pamięci.

Analiza statyczna koncentruje się przede wszystkim na samym kodzie, na stylu kodowania, na utrzymaniu porządku w kodzie etc.

Linter

Jako pierwsze opiszę linter w PHP – czyli narzędzie, które mamy dostępne od razu po instalacji PHP. Jeśli nie wiecie dokładnie, czym zajmuje się linter możecie uzupełnić swoją wiedzę w tym miejscu. W skrócie jest to narzędzie, które oznacza podejrzane lub błędne fragmenty kodu.

W PHP aby uzyskać dostęp do lintera należy w CLI wpisać php -l a zaraz po tym ścieżkę do pliku, który chcemy poddać analizie. Oczywiście wpisywanie za każdym razem polecenia w CLI dla pliku, w którym wykonaliśmy jakąś zmianę byłoby bardzo męczące dlatego też istnieje szereg rozszerzeń różnych edytorów dla programistów takich jak Atom czy Sublime Text 3. Oczywiście nie tylko PHP posiada linter – odpowiednie rozszerzenia istnieją także dla JavaScript i innych języków.

PHP Copy/Paste Detector (phpcpd)

Kolejne narzędzie jest bardzo pomocne przy wykrywaniu powtarzających się fragmentów kodu czyli tzw copy/paste programming. Autorem PHPcpd jest Sebastian Bergmann najbardziej znany chyba z PHP Unit.

Samo narzędzie można zainstalować Composerem lokalnie w projekcie:

composer require "sebastian/phpcpd=*"

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Pierwsza edycja warsztatów cieszyła się bardzo dużą popularnością, dlatego podjeliśmy decyzję o kontynuacji warsztatów z podstaw programowania w PHP. Tym razem warsztaty będą przede wszystkim dotyczyły zagadnień związanych z programowaniem obiektowym w PHP 5.X,

Warsztaty odbędą sie 11 lutego (sobota) 2017 r. w godzinach 9:00 – 12.30 w sali komputerowej Wyższej Szkoły Przedsiębiorczości i Administracji w Lublinie przy ul. Bursaki 12. Udział w warsztatach jest bezpłatny, a liczba miejsc ograniczona. Wymagana jest wcześniejsza rejestracja na wydarzenie poprzez formularz znajdujący się na fanpagu wydarzenia. Krótki plan warsztatów znajduje się poniżej.

Warto wiedzieć, że:

Mimo że wydarzenie jest kierowane do kobiet, mężczyźni również są mile widziani, jeśli interesują ich tematy prezentacji. Choć wśród organizatorek są wyłącznie kobiety, nie znaczy to, że zamykamy się na panów. Publiczność na naszych warsztatach i spotkaniach jest zawsze mieszana, a panowie często występują u nas także w roli prelegentów.

Co w wolnym tłumaczeniu oznacza, że warsztaty są otwarte dla wszystkich – nie tylko dla kobiet (po więcej informacji odsyłam na stronę WiT ).

Zakres zagadnień, które będę poruszał na warsztatach:

• obiektowy elementarz;
• programowanie zorientowane obiektowo;
• wielokrotne wykorzystywanie kodu;
• obsługa wyjątków;

Wszystkich zainteresowanych serdecznie zapraszam!

Artykuł Warsztaty z programowania obiektowego w PHP – WiT Lublin pochodzi z serwisu Notatki Programisty.

W pewnym momencie życia naszej aplikacji przychodzi taka chwila, że staje się dla nas ważna wydajność. Często jest to powiązane ze wzrostem ilości zapytań/użytkowników lub danych w bazie. Ale nie zawsze wiemy jak zabrać się do pomiarów naszej aplikacji (obciążenia procesora, zużycie pamięci, czasu przebiegu).

W odległych czasach często obudowywano fragmenty kodu PHP w taki sposób:

$start = microtime(true);
someFunction();
$end = microtime(true);
$executionTime = number_format($end - $start, 10);

Dzięki temu uzyskiwaliśmy pewną wiedzę na temat czasu wykonywania metod, funkcji, fragmentów kodu. W podobny sposób uzyskiwano informacje np. odnośnie pamięci. Następnie zapisywaliśmy dane do bazy, pliku etc. Całość jednak powodowała dość duży narzut prac, aby sprawdzić wydajność aplikacji, a jednocześnie w pewnych sytuacjach powodowała zwiększenie złożoności kodu (dodatkowe modele, biblioteki, klasy).

Xdebug

Jeśli ktoś znał Xdebuga i miał możliwość włączenia na serwerach developerskich/testowych rozszerzeń PECL bardzo szybko przenosił się na to rozwiązanie. Profilowanie w Xdebug jest bardziej uniwersalne, nie musimy osobno „badać” każdej metody, ale robi to sam Xdebug na poziomie wykonywania kodu PHP i zbiera naprawdę sporo informacji o wszelakim wykonanymi kodzie. Wystarczy tylko odpowiednio skonfigurować mechanizm profilowania w php.ini:

xdebug.profiler_enable = 1
xdebug.profiler_output_dir = /tmp/profiler

Po każdym request do aplikacji otrzymujemy plik cachegrind.out we wskazanym katalogu, który możemy przenalizować za pomocą narzędzi graficznych, np. takim jak KCachegrind. Jest to dobre rozwiązania na maszynie developerskiej, gdzie jest ograniczona ilość użytkowników, możemy kontrolować ilość requestów, ponieważ w innym wypadku bylibyśmy zawaleni przez pliki z proflowania. Poza tym narzędzie Xdebug nie jest zalecane do zastosowań produkcyjnych. Co w takim wypadku?

XHProf (Hierarchical Profiler) / XHGui

XHProf został stworzony przez developerów Facebooka i udostępniony publicznie w marcu 2009 roku. Tak jak Xdebug jest również napisane w C jako PHP Zend Extension (PECL). Ale zadaniem XHProf jest wyłącznie profilowanie naszej aplikacji (zbiera takie metryki jak czas, czas CPU czy użycie pamięci). Został stworzony z myślą, aby działać na środowiskach produkcyjnych (stabilność, mały narzut na zbieranie informacji). XHProf dostarcza również prosty mechanizm do tworzenia raportów HTML, w którym możemy przeglądać rezultaty profilowania, jak również zobaczyć graf przejścia. Rozszerzenia znajduje się w oficjalnym katalogu PECL, dlateg aby zainstalować XHProf wystarczy wydać komendę:

pecl install xhprof

Bazując wyłącznie na XHProf możemy wykorzystać dość toporny sposób na zbieranie informacji:

//operations, collecting
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
for ($i = 0; $i < = 1000; $i++) {
    $a = $i * $i;
}
$xhprof_data = xhprof_disable();

//writing
$XHPROF_ROOT = "/tools/xhprof/";
include_once $XHPROF_ROOT . "/xhprof_lib/utils/xhprof_lib.php";
include_once $XHPROF_ROOT . "/xhprof_lib/utils/xhprof_runs.php";

$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_testing");

//URI with data:
//http://127.0.0.1/xhprof/xhprof_html/index.php?run={$run_id}&source=xhprof_testing

Myślicie, że to skomplikowane i dużo nie ułatwia? Zgadzam się! Dlatego od razu polecam zapoznać się z XHGui, który cały proces upraszcza i niweluje tworzenie wielu małych plików dostępnych pod unikatowym ID, bez których nie jesteśmy w stanie szybko zapoznać się z analizą.

XHGui napisany jest w PHP i jest to forma nakładki na profiler. Cały kod XHGui umieszczamy w miejscu dostępnym tylko dla nas przez WWW i robimy zmianę w php.ini (lub przeciążamy zmienną w naszym kodzie):

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Pierwszy artykuł na blogu Hello World! pojawił się 14 września 2009 roku. Od tamtej pory popełniłem 630 artykułów (z dzisiejszym będzie 631) – jedne lepsze, inne gorsze. Część postów była celowo kontrowersyjna, część napisana na kolanie, pojawiło się kilka konkursów, w których rozdawałem książki, artykuły o Windows Azure pozwoliły mi pojechać do Las Vegas na konferencję Microsoftu, a dzięki podjęciu kilku tematów, otrzymałem wiele interesujących ofert współpracy. Później przyszła niemoc twórcza i na blogu pojawiały się luźne tematy, związane z muzyką, podróżami i innymi przyziemnymi... [[ This is a content summary only. Visit my website for full links, other content, and more! ]]