Přejít k navigační liště

Zdroják » PHP » Jak být produktivní v PHPStormu (část 3.)

Jak být produktivní v PHPStormu (část 3.)

Články PHP

V tomto díle si ukážeme, jak funguje propojení PhpStormu s Gitem. Podíváme se na to, jak debugovat, abychom se z toho nezbláznili. A opět si ušetříme trochu práce a času – tentokrát formou automatického formátování kódu.

V minulém díle jsme skončili trochu kontroverzním tématem – vypínáním panelů. Zkusili jste si na to zvyknout? A podařilo se? Doufám, že ano. Jestli se vám nedaří, tak dejte vědět v komentářích a zkusím vám pomoct s nastavením správného workflow. Tentokrát se zaměříme na trochu méně běžné věci a pokročilejší funkce.

Propojení s verzovacími systémy

Při vývoji v Gitu na Shopiu fungujeme v režimu tasků. Udělá se task pro konkrétní projekt s konkrétním číslem (#13: Kupon na dopravu zdarma). V něm se prodiskutuje a naspecifikuje nějaká funkcionalita a když je schváleno, tak se naprogramuje a commitne s názvem a číslem ticketu (demo.shopio.cz – 13: Kupon na dopravu), aby bylo možné dohledat, s jakým požadavkem commit souvisí. U dlouho běžících projektů se často stává, že v codebase objevíte něco, co nedává smysl a nefunguje tak, jak by si člověk myslel, že by mělo. V tu chvíli je důležité zjistit, proč se daný kus kódu změnil a jestli je to vlastnost, nebo chyba. K tomu používáme git blame, který zobrazí kdo, kdy a s jakou commit message změnu provedl. Díky důslednému popisování commitů pak snadno zjistíme číslo tasku a můžeme si najít celou diskusi, která k dotyčné změně probíhala.

Přesně k tomu je určeno Annotate – ve výchozím stavu nemá zkratku, ale nějakou si nastavte (např. Alt + G). Alternativně můžete Annotate otevřít po kliknutí pravým tlačítkem na čísla řádku vlevo v editoru (angl. gutter). V editoru se inline zobrazí git blame. U každého řádku máte označeno, kdo ho udělal a kdy. Z Annotate si můžete taky u každé revize zobrazit celý diff. Navíc můžete procházet historii dozadu (Annotate previous revision), což využíváme především pokud poslední revize je něco nesouvisejícího – typicky nějaká hromadná změna coding standards.

Mimo to se vám v sidebaru označují upravené řádky od posledního commitu (pokud použijete moje schéma Grenadine, tak jsou bílé). Každý blok se dá revertnout nebo porovnat s předchozí verzí.

Aby propojení s Gitem fungovalo, je třeba mít nastavené Git Roots – najdete je v Settings pod Version Control. Potom se vám také zpřístupní Git interface ve status baru. Tím můžete rychle přepínat branche, případně vytvářet nové. Navíc pokud máte projekt na GitHubu, tak funguje i přímá integrace. V kontextovém menu souboru máte Open on GitHub, které vám otevře momentálně otevřený soubor na GitHubu. Tam také najdete Create Gist, kterým můžete rychle komukoli nasdílet kus kódu. K tomu budete ještě potřebovat Github token.

Debugger

Instalace a zprovoznění

Co si pamatuju, tak debugování v PHP nikdy pořádně nefungovalo. Nastavil jsem to podle návodu a stejně to nejelo, jak mělo. PhpStorm je první IDE, kde se mi podařilo debugování rozjet. A ukážu vám, jak na to.

První krok je stažení Xdebugu. Naštěstí už dávno není potřeba zkoumat, jakou že přesně verzi PHP mám a jestli je thread-safe nebo ne. Na webu Xdebugu najdete stránku, kam jen vložíte výstup z phpinfo() nebo php -i, a dostanete přesný návod, kam co nakopírovat a kterou verzi stáhnout.

Na konec php.ini ještě vložte pod řádek Xdebugu následující:

; vypne profiler
xdebug.profiler_enable = 0
; povoli zapnuti, kdyz date do URL ?XDEBUG_PROFILE
xdebug.profiler_enable_trigger = 1
; povoli debugger + nastaveni
xdebug.remote_enable = 1
xdebug.remote_handler = "dbgp"
xdebug.remote_host = "localhost"
xdebug.remote_port = 9000
; vypne stack trace on error (typicky resi treba Tracy)
xdebug.default_enable = "Off"
; nepokousi se pripojit samo, jen pokud nekdo posloucha
; dulezite, protoze jinak, pokud nebezi debug client, kazdy request zamrzne tak na 5s
xdebug.remote_autostart = 0

Po nakonfigurování Xdebugu nezapomeňtě PHP restartovat. Do záložek prohlížeče si uložte debugovací bookmarklety.

Debugujeme

Teď je potřeba zapnout debugování bookmarkletem Start debugger a pak v PHPStomu začít poslouchat příchozí spojení. To najdete pod Run | Start Listening for PHP Debug Connections. Zkuste si někam do kódu přidat breakpoint, tedy kliknout do prostoru mezi číslo řádku a kód (angl. gutter). Objeví se červená tečka a celý řádek se podbarví červeně. Pak stačí obnovit stránku v prohlížeči a spouštění by se mělo zastavit na místě breakpointu. Může se stát, že se vám zastaví na prvním řádku skriptu – je to způsobeno nastavením Force break at first line (najdete v Settings) a můžete to vypnout. A tím je hotovo. Pomocí Step Over (F6) můžete krokovat nebo pomocí Run (F9) necháte skript provést až k breakpointu. Když krokujete, tak se občas hodí  možnost vlézt „dovnitř“ volání, to uděláte pomocí Step Into (F5). Když se dostanete moc hluboko, „ven“ můžete vylézt pomocí Step Out (F7).

Skvělá věc je také Run to Cursor (Ctrl+R), která nechá skript běžet až k aktuální pozici kurzoru. Celkově je debugování neuvěřitelně návykové a jak jednou začnete, tak si budete s die(var_dump($var)) připadat jak v době kamenné. Jestli ho budete chtít i přesto stále používat, tak si pořiďte alespoň enhanced-dump :) Jediná nevýhoda Xdebugu je, že poměrně dost zpomaluje spouštění skriptů. Záleží hodně na codebase, ale u některých projektů to může být až 4×! Pokud je to i váš případ, tak si ho můžete vypnout nastavením xdebug.remote_enable = 0 v php.ini. a zapínat ho, jen když chcete debugovat.

Formátování kódu

PhpStorm umí automaticky formátovat kód, který píšete. V nastavení to najdete jako Code Style a samotný kód naformátujete pomocí Reformat Code (Ctrl + Shift + F)

Pokud máte zavedený coding standard, které vynucujete nějakým nástrojem (třeba phpcs), tak určitě znáte následující situaci. Něco napíšete, commitnete, pushnete a za chvíli vám přijde mail od Jenkinse, že jste rozbili build. To naštve! Kdyby tak IDE umělo kontrolovat standard rovnou. Oh wait! PhpStorm to samozřejmě umí. První krok je nastavení binárky phpcs (v Settings jako Code Sniffer). Pod Configuration si nastavte binárku, kterou chcete, a nastavení zkontrolujte tlačítkem Validate tamtéž. Potom stačí nastavit odpovídající Inspection. Pokud si v Settings vyhledáte “Sniff”, tak se vám odpovídající položka vysvítí v rámci nastavení Inspections. Tam doporučuji Severity nastavit na Error a Warning na Warning. A Coding Standard nastavte podle toho, co používáte. Objeví se tam ty standardy, které má váš phpcs v sobě, a kliknutím na tři tečky můžete PhpStorm nasměrovat do libovolné složky, kde je definice v souboru ruleset.xml. Od té chvíle se vám budou v souborech chyby formátování červeně podtrhávat.

Další zajímavé drobnosti

Několik zajímavých drobností, které by vás možná ani nenapadlo hledat, na vás čeká v menu Tools. Pojďme se na ně podívat.

Integrovaný REST client

Určitě jste už někdy potřebovali použít nějaké REST API. Třeba to, které poskytuje ElasticSearch. Možná jste využili curl nebo Postman extensionu do Chromu. Možná ale nevíte, že PhpStorm má vlastní nástroj na práci s REST API. Najdete ho v menu Tools jako Test RESTful Web Service. Zadáte v něm server, adresu, parametry, hlavičky a můžete testovat požadavky na server. Odpověď si pak můžete zobrazit jako formátovaný kód. Poradí si dokonce i s cookies nebo vám vygeneruje hlavičky pro HTTP autentizaci. Navíc jdou requesty ukládat do XML pro pozdější potřebu. Snad jediné, co mi chybí, je možnost nechat si vygenerovat curl request, který bych mohl poslat někomu, kdo nemá PhpStorm.

Analýza stacktrace

Pokud používáte větší frameworky, tak jste si jistě všimli, jak mají složité stacktracy. Kolikrát se jedná třeba o deset postupně zanořených volání. Při běžném vývoji se o jejich zpracování při chybě postará framework (třeba Tracy). Ale číst stacktrace, který na vás vypadne třeba z textového logu na serveru, je peklo. Pokud ho ale předhodíte funkci Analyze Stacktrace, tak vám ho PhpStorm obarví a umožní vám proklikávat jednotlivé úrovně volání. A to se vyplatí!

Analýza výstupu profileru

Pokud použijete výše zmíněné nastavení Xdebugu, tak si pomocí parametru v URL (nebo v cookie, je to jedno) můžete vygenerovat výstup pro profilování. Ten v sobě obsahuje informace o tom, jak dlouho trvalo které volání a umožní vám najít úzká hrdla ve vaší aplikaci. Pomocí Analyze Xdebug Profiler Snapshot si ho můžete zobrazit v čitelné podobě. Na seriózní profilování doporučuji KCachegrind, respektive WinCachegrind, ale pokud třeba zrovna nejste v dosahu internetu, abyste je stáhli, tak se profiler v PhpStormu hodí.

Závěr

V omezeném prostoru, který série tří článků poskytovala, jsem vám ukázal jen část věcí, které PhpStorm umí. Doporučuji vám dál zkoumat nové možnosti a funkce, které s každou novou verzí přidává. Některé funkce zvýší vaši produktivitu, zatímco použití jiných je krokem k snazšímu a bezpečnějšímu refaktoringu. Doufám, že vám alespoň některé tipy uvízly v paměti a budete je používat.

Zabývám se zlepšováním efektivity práce už delší dobu, a to nejen v PhpStormu, ale i ostatních věcí, které s prací vývojáře souvisejí. Takže pokud máte pocit, že byste s tím potřebovali pomoct (ať už vy sami nebo ve firmě), tak se mi můžete ozvat třeba na Twitteru nebo LinkedIn a nějak se dohodneme :)

Komentáře

Subscribe
Upozornit na
guest
14 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Roman

Vďaka za spomenutie Code Sniffera. Už ho úspešne používam.

zajca

Jako náhradu pro var_dump bych doporučil ladybug https://github.com/raulfraile/Ladybug
(debugeru se, ale nevyrovná :) )

error414

neresil si Tome nekdy problemy s vykonosti PHPstormu, kdyz edituju soubor s cca 12000 radku tak IDE silene laguje a neda s tim poradne pracovat :(.

BTW: nereste pls je edituju soubor s 12K radku, tak to je, kdyby to slo jinak tak to neresim :)

error414

jak jsem psal, s tim souborem nemuzu nic delat :(. asi se s tim naucim zit.

error414

jj ale je to dvousecna zbran :(. s power save mode se to da editovat ale neda se v tom souboru pohybovat. Jedine pres hledani a to je trosku opruz :). vubec si nedokazu predstavit jak bych to delal na slabsim stroji. Ale za PHpStorm to stoji, nic lepsiho sem zatim nenasel.

error414

ook moc diky vyzkousim

Ja.

Páči sa mi váš spôsob fungovania popísaný v časti „Propojení s verzovacími systémy“. U nás to funguje asi tak, že niekto zavolá, že asi by niečo bolo dobré spraviť. Tak sa pokúsite niekoho spýtať, nikto nič nevie. Tak sa sami rozhodnete, či to spraviť. Spravíte si sami task (aj tak to nikto iný nečíta), spravíte zmenu, commitnete a po pol roku sa niekto spýta, prečo je tam niečo, čo tam predtým nebolo :) Takto vyzerá asi polovica taskov. Pri niektorých to je trochu lepšie, pri niektorých o moc horšie. Ale nikdy nie tak ideálne, ako je popísané tu.

satai

To by mozna stalo za to zapracovat na tom, aby se vam takovehle veci nestavaly ;)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.