Zkouším pro Flexový vývoj přejít z Flash Builderu (IDE postavené nad Eclipse) na IntelliJ IDEU, což je obecně nástroj vynášený do nebes a i kupa Flexařů přešla a přechod doporučuje. Tak to zkouším a je to hodně zajímavá zkušenost.

Na jednu stranu, a to o nástrojích JetBrains platilo vždy, jejich IDE je velmi inteligentní a dobře rozumí kódu. Flash Builder v tomto taky není úplně špatný a o vztahu různých symbolů v projektu má slušnou představu, ale IDEA je určitě dál. V praktické rovině je například daleko pohodlnější se z deklarace rozhraní prokliknout na jednotlivé implementace (ve Flash Builderu nutno neohrabaně přes Find References), lze udělat rychlý diagram závislostí mezi projekty atd. atd. Tohle je, hádám, hlavní důvod, proč tolik (nejen Flex-) vývojářů IDEU vynáší do nebes a fakt je příjemné v tom kódit, pokud všechno ostatní funguje.

Jenže v tom je ten háček. Už u JavaScriptového vývoje ve WebStormu u mě zhruba platilo, že co hodina práce v IDE, to jeden reportovaný bug. Trochu jsem doufal, že u silně typového Flexu, kde kompilátory i debugger jsou odladěnou součástí Flex SDK a IDE je tak vlastně jen malou slupkou nad nimi, to bude lepší, ale už jen import našeho projektu do IDEY byl docela dílem a dokonce se muselo čekat na opravný setinkový release, aby náš projekt vůbec bez změny kódu fungoval. A potom mám ohromný problém s použitelností toho IDE – ne se vzhledem, ale s fundamentální použitelností na mnoha místech.Uvedu tři příklady, každý na poněkud jiné úrovni.

1) Tooltipy (tohle je z kategorie obecného GUI; zdánlivě blbost, nicméně pokud je tam takovýchto problémů na každém kroku deset, prostě to otravuje). Defaultně se tooltipy zobrazují za nesmyslných 1200ms, a když přejíždím myší z tlačítka na tlačítko, tak se tento delay aplikuje znovu a znovu. Hrozně by mě zajímalo, jak takovéto chování vzniklo. Jestli v JetBrains nějakému programátorovi jen zadali “udělej podporu pro tooltipy” a nechali to na něm, nebo jestli se nad tím někdo přes UI skutečně zamyslel a výstupem bylo ignorovat běžné konvence a udělat zkoumání funkcí tlačítek záměrně nepříjemné. (Nemyslím to jako zesměšňování, u IDE si teoreticky dokážu představit, že to mohl být záměr.)

Do této kategorie problémů by toho z mého pohledu spadlo mnoho, od nekonzistentní terminologie, přes nepozornost k formátování, používání barev a tak dále a tak dále. Často je to skoro podprahové – dělám něco, co ve Flash Builderu bylo z nějakého důvodu příjemnější, a nedokážu hned říct, čím to je. Tak si ten samý projekt otevřu tam a pak mi to dojde – například formulář používá fieldsety, speciální značky v kódu jsou jinou barvou nebo nějaká podobná drobnost. Protože autorům Eclipse / FB na použitelnosti záleželo.

2) Zadávání cest. V týmových projektech je téměř vždy potřeba se vyhnout absolutním cestám a používat nějaké proměnné, například PROJECT_ROOT apod. IDEA toto podporuje skrze tzv. path variables, ale kromě toho, že někde v settings máte tyto proměnné nastavené, se IDEA tváří, že všude používáte absolutní cesty (při uložení a načtení projektu se tyto absolutní cesty na pozadí převedou na path variables a zpět). Technicky není co vyčítat, ale z pohledu GUI je to hrozně neintuitivní. Vy víte, že jste si nadeklarovali proměnnou PROJECT_ROOT, ale nemůžete tuto proměnnou nikde nijak použít. Ať zadáváte cestu kdekoliv, je to přes poměrně hloupý file system browser, který nemá žádnou “přidanou hodnotu” – prostě jen umí procházet FS a pracovat s absolutními cestami (a ještě se načítá dlouho). Pro srovnání, jak to funguje v Eclipse: jednak jde cesta vždy zadat bez otevírání otravného stromu filesystému, druhak Eclipse ví o path variables, které jste si nadefinovali, a nejen že vám je dovolí zadat, i je k dispozici autocomplete. Je to nejen uživatelsky přívětivé, ale hlavně to odpovídá realitě: v projektových souborech bude jak v Eclipse, tak v IDEE něco jako dependency=$PROJECT_ROOT/libs/xyz, rozdíl je v tom, že Eclipse tuto realitu reflektuje v GUI, zatímco IDEA to zakrývá.

3) Chybějící Problems view. Pro mě asi největší šok, ale IDEA nemá společný panel problémů, něco jako Problems view v Eclipse nebo Error List ve Visual Studiu. Chyby detekované kompilátorem se zobrazují v panelu Messages, který je spíš takovou chytřejší konzolí (jsou tam zbytečně zobrazené info messages, je to strom místo listu, občas panel Messages vůbec není přístupný atd.) a především zobrazuje až chyby zjištěné samotných kompilátorem, ne IDEOU samotnou. Pokud chce člověk zobrazit problémy vzešlé z live analýzy kódu, může zkusit třeba v Project exploreru přepnout na filtr Problems, ale i to má své problémy: zaprvé se tím schová strom projektu, dále se pak opět jedná o otravný strom namísto listu, no a potom se zde zobrazují jen chyby v otevřených souborech, ne všechny chyby v projektu. Pak je v IDEE ještě jakýsi panel výsledků statické analýzy, kterou je ale potřeba spustit explicitně, a pro Javovské projekty jsem viděl ještě jakýsi jiný panel, který už jako Error List vypadá, ale pro Flexové projekty není ničím naplněný.

Není to absurdní? IDEA ví o mém kódu hrozně moc, ale nemá rozumné GUI, ve kterém by mi to zobrazila. Má jen kupu různě více nebo méně vhodných panelů, přitom řešení je tak hrozně prosté: mít tabulku ale Eclipse nebo Visual Studio, kam se sypou všechny errory a warningy. Není mi jasné, proč se vyhýbají řešení, které nejen že je všude jinde obvyklé, ale navíc je velmi jednoduché na implementaci a uživatelsky intuitivní.

Při vývoji v IDEE jsem tedy na každém kroku narážel na různé nedomyšlenosti. Jak je to možné? Dovolím si zaspekulovat.

Když mám s IDEOU problém, jdu jim to hned nahlásit do bug trackeru. (Tady jde JetBrains hodně k plusu, že vůbec něco takového mají a že se člověk zaručeně dočká reakce v řádu hodin.) Píšu tam klidně i obecné usability věci, jako že ty path variables / absolutní cesty se chovají neintuitivně, kde mi to způsobilo problémy a jak bych si představoval řešení. Takový ticket je většinou přiřazen na někoho, kdo, tipuji, je rovnou vývojář, ne žádný project manažer nebo něco takového. To je na jednu krásně přímočaré a agilní, a nejednou se mi stalo, že nějakou drobnost ten člověk hnedka fixnul a za pár dní byla nová verze na světě (to je u jiných IDE skoro nemyslitelné), na druhou stranu pokud máte problém s něčím, co je IDEOU prolezlé a potřebovalo by koncepční změnu, dá se celkem spolehnout na to, že běžný-franta-JetBrains-vývojář to uzavře jako wontfix nebo prostě na implementaci nikdy nedojde. Současně, pokud vám skutečně jde o to, aby IDEA byla lepším nástrojem (děláte to konec konců kvůli sobě, že jo), je trochu frustrující s lidmi s JetBrains v bug trackeru diskutovat – je tam hodně cítit vývojářský mindset, který se na problém dívá pohledem “půjde to nějak rychle udělat?”, resp. “dokud má bug nějaký workaround, není to bug”. O nějakých větších změnách není moc ochota diskutovat.

IDEA je jako vlak v módu “nezastavujeme, máme zpoždění”, který neskutečným tempem valí nové verze, fičury, podporu nových jazyků, testovacích frameworků atd. atd., ale nikdy není čas zastavit a opravit něco na podvozku, co se kdysi dávno nenavrhlo úplně dobře. IDEA působí jako nástroj, na kterém maká tlupa vývojářů, kteří procházejí YouTrack a fixují jednotlivé bugy / tasky. Koncepčnost toho IDE není cítit, stejně jako bych si tipnul, že nemají moc velké QA – prostě verzi vydají, a když tam je nějaký problém, v příští setinkové verzi to bude fixnuté. Toto má své ohromné výhody i nevýhody, a tipnul bych si, že se to JetBrains vyplácí, ale občas tím teda docela trpím. Ve Flash Builderu když Adobe řeklo, že tam je nějaká fičura, tak ta věc prostě fungovala. V IDEE je to spíš takový příslib, který je naplněn, když má člověk štěstí. Když ho nemá, musí doufat, že je jeho problém dostatečně malý na to, aby byl fixnut v příštím (brzkém) releasu.

Ve výsledku jsem tak přešel zpět na Flash Builder, respektive používám ho na takové to běžné programování, zatímco IDEU startuji ve chvíli, kdy mám na stole nový projekt plný “zajímavého” (špatného) kódu a potřebuji se v něm vyznat. IDEA je chytrá, ale na mě moc kovbojská.