PHP fejlesztéshez PHPStorm-ot mindenkinek

Megtaláltam az ideális PHP fejlesztő környezetet. Rettentő okos, jól használható, remekül testre szabható. Mindent tud, amit elvárunk tőle. És nem csak a mesében létezik.

A JetBrains fejlesztette PHPStorm egy több hónapos tesztsorozat eredményeképpen került a listánk élére. A bemutató után a csapat egyöntetűen tette fel a kezét arra, hogy akár már holnaptól használná. Az egyetlen rossz hír az egészben az, hogy a PHPStorm pénzbe kerül. Ugyanakkor akadémiai oktatásban 80% engedményt, startupok 50%-ot, oktatási használatra, open source projektet számára ingyenes.

A kiválasztás

A kiválasztás folyamatában számos szempontot figyelembe vettünk, például azt, hogy jelenleg a projektjeinkben NetBeanst, Zend Studiot (Eclipse), Emacs-ot és Vim-et is használunk fejlesztésre. A kollégák meggyőzhetőségét nagyban elősegítette, ha az átállás a lehető legegyszerűbben történik, valamint ha minél több előnyt az új fejlesztő környezet oldalára tudunk állítani. Egyértelmű volt, hogy az Emacs és a Vim nem alternatíva azoknak, akik már „rendes” IDE-t használtak. A listába első körben bekerült több fejlesztő környezet is, mint pl. az Eclipse PHP pluginokkal, vagy az Aptana, de ezek elég gyorsan „kiszórodtak” a listán.

A projektet felépítése alapján a következő listát állítottuk fel:

Feature	Weight	PHPStorm	NetBeans	Zend Studio
PHP Editor	10	10	9	10
SVN	10	7	5	8
SFTP	10	9	7	8
Refactoring	9	10	3	5
SQL Editor	7	9		9
Zend debug	7	6	0	6
Unit test	6	10	9	7
JIRA	5	7	7*	7
XML Editor	5	8		7
Shell script editor	4	10	10	10
C++ editor	3	5	7	10
DocBook WYSIWYG	3	1*	7	7
File encoding settings / file	3	10	1	10

A legfontosabb feature-ök az igényeinket teljesen kielégítő editor felület volt. Ezeket szinte mindegyik eszköz azonos minőségben nyújtotta. A verziókövetés és a fejlesztő szerverre történő deployment (SFTP) ugyanígy fontos volt. Mivel egy 10 éves projektet örököltünk meg, annak minden bajával, ezért a „refactoring” támogatása szintén létszükség. A PHPStorm ebben kiemelkedően jól szerepelt, míg a NetBeans támogatása kvázi semmit se ért. Egy nagyon alap SQL Editor (quick and dirty, egyszerűbb sql selectek eredményének megjelenítése) már a „nice to have” kategóriába esett, de miért kelljen egy több száz megányi memóriát igénylő SQL Editort indítanom, ha megoldható az egész egy GUI-ból is. Mivel az egyik projektnél Zend Servert használunk, ezért természetes elvárás volt a Zend debugger támogatása is – ezt igazából egyik IDE sem oldotta meg jól, még a Zend Studio sem, ahol azért itt egy 10/10 elvárható lett volna. A unit test szinte mindenütt jól szerepelt, a JIRA viszont a NetBeans-nél egy rettentő rosszul kódolt pluginnel volt jelen – létezett, user szempontból jól használható volt, de a JIRA szervert üzemeltetők lekapcsoltatták, mert vagy 1000 szálat tartott folyamatosan nyitva. Az egyetlen szempont, aminél azt mondhatjuk, hogy a PHPStorm elvérzett a többi eszközzel szemben, az a DocBook integrált WYSIWYG felülete, ehhez ugyanis nem találtunk plugint.

Tesztelés

A tesztelést empirikus módon végeztük, azaz feltettük az adott eszközt, és elkezdtük használni. Ezzel ráadásul azt is megtudtuk, hogy az adott eszköz tanulási görbéje hogyan néz ki. Ketten teszteltük, míg én Eclipse IDE-t használtam az elmúlt 10 évben, addig a kolléga a NetBeans-es környezetből jött. Ebből adódóan más és más tanulási görbét valamint kényelmetlenségi listát állítottunk fel.

Számomra az egyik legnagyobb gondot a perspektívák eltűnése okozta. Még emlékszem, mennyire nehéz volt megszokni, hogy váltogatni kell a nézetek között, most ugyanennyire nehéz megszokni, hogy nem tudom annyira kényelmesen berendezni a felületemet, valamint hogy mindent egyszerre látok a képernyőn. A PHPStorm-ban egyetlen egy (közös) szerkesztő terület van. Ide nyílnak meg a PHP file-ok, és az SQL Script editor is.  Az Eclipse-nél „view területként” definiált rész jóval kevésbé testre szabható, mint az Eclipse-nél, illetve a drag-and-drop – bár működik, nem annyira egyértelmű. Mi több, nekem elsőre úgy tűnt, hogy nincs is rá lehetőség.

Bár az SVN beállítása és a hozzászokás sokkal macerásabb, mint amit az Eclipse-nél tapasztaltam, ha egyszer sikerült tisztességgel beállítani, akkor a manual merge feature annyival jobban lett megírva, mint bármelyik más IDE-nél, hogy feledteti az egyéb hiányosságokat.

Szintén macerás volt az automatikus upload (SFTP) beállítása, de amióta beállítottam, remekül működik anélkül, hogy hozzá kellene nyúlni.

Onnantól kezdve, hogy ezt a két relatív macerás dolgot beállítottam, gyönyörűen muzsikált az egész felület.

Pozitívumok

Az előbb már említettem, hogy az SVN (manual) merge feature-je messze a legjobb mindazok közül, amit láttam. Mivel elég sokat mergelünk trunk és a branchok között, ez egy elég fontos érv volt a PHPStorm mellett.

A másik, hihetetlenül jól megoldott dolog az a refactoringot és az egész kód supportot érinti. PHP-ban ugye nincsenek tipizálások, de a PHPDoc-ból értelmezi a változó típusát, ha ott megadod, és az objektumoknál megfelelően lekezeli, hogy egy adott függvény létezik-e vagy sem. Persze ha az ember nem OOP-t használ, vagy ha egy változót legelső alkalommal „null” értékkel inicializál, akkor ott lehetnek bibik.

A kód analízis is remek, a „find usage” a kedvenc shortcode-om (Ctrl-G) lett a globál változók eltüntetéséért folytatott harcban. Sajnos nem teljesen tökéletes, de csak azért, mert az egész PHP include-ostól, require-edestül nem tökéletes.

A legfontosabb érvem a fejlesztő környezet használata mellett mégis az, hogy kvázi vakon, csak és kizárólag az IDE funkcióira hagyatkozva tudtam olyan komoly refactoringot (alkönyvtárak {namespace lenne, ha új PHP verziónk lenne…} bevezetése, spagetti kódból OOP-t, változók kidobálását illetve funkciók mögé történő elrejtését) eszközölni, hogy a feltöltés után szinte teljesen hibamentesen működött (volt egy két required_once hiba a sok egymásra hivatkozás miatt, amit meg kellett tisztességgel oldani).

Eredmény

Jelenleg a PHPStorm licencek beszerzése zajlik, én viszont egész biztos, hogy addig használom a teszt verziót, amíg meg nem kapom a végleges licencet. Az azonban biztos, ha valaha saját vállalkozás keretein belül kell(ene) PHP-ban kódolnom, az első dolgom az lenne, hogy megvegyem.