sobota 11. ledna 2014

Eclipse, IntelliJ IDEA a má cesta tam a zase zpět

Jsou dva způsoby, jak přitáhnout pozornost k článku, buďto použijete bulvární titulek a nebo uděláte bulvární tweet s odkazem na ten článek. Já jsem původně nechtěl ani jedno ani druhé, ale nakonec se mi podařilo obojí. Když k tomu připočítám téma, IntelliJ IDEA a Eclipse, které je mezi vývojáři podobně vyhrocené jako situace na Blízkém východě, jsem už na poměrně tenkém ledě a v situaci, do které jsem se nechtěl dostat. Po více než šesti měsících každodenního používání jsem se rozhodl opustit IntelliJ IDEA a vrátit se zpět k Eclipse a v tomhle článku vám vysvětlím proč.


Jak jsem se dostal k IntelliJ IDEA

K IntelliJ IDEA jsem se dostal dílem náhody a dílem okolí. Skoro všichni kolegové přešli z Eclipse na IntelliJ IDEA a ohromě si to pochvalovali. V určitou chvíli mi přestalo v Eclipse fungovat stahování zdrojových souborů k Maven artefaktům. Po jedné z těch security změn, které rozhodně nic nemůžou rozbít chlape, začalo HTTPS spojení do firemního Maven repa vyžadovat podporu SNI. Z tohoto důvodu bylo potřeba nahradit jednu knihovnu, kterou Maven používá pro HTTP komunikaci. To se jednoduše udělá pro Maven, který vám někde leží na disku, ale mnohem hůře se to děla v Mavenu, který je v Eclipse jako OSGi bundle. Strávil jsem tím nějaký čas a nepovedlo se mi to. Jenom podotýkám, že Eclipse je sice schopný používat externí Maven pro určité úlohy, ale pro resolving závislostí se vždy používá embednutý Maven.

Všichni kolegové s IntelliJ IDEA v mém okolí svorně tvrdili, že jim tenhle use case funguje. Řekl jsem si, že občas je potřeba opustit zónu komfortu, abyste se posunuli někam dál a něco nového se naučili. Když se sečetly všechny tyhle důvody - nefunkční stahování zdrojových souborů, výborné reference, touha naučit se něco nového - nebylo moc o čem přemýšlet. Rozhodl jsem se, že začnu IntelliJ IDEA používat. Přirozeně jsem se od prvních okamžiků neubránil pocitu porovnávání s Eclipse a proto jsem si dělal poznámky, které se staly základem pro tento článek.


Proč jsem se vrátil zpátky

IntelliJ IDEA i Eclipse jsou výborná vývojová prostředí s přibližně stejnou výbavou vlastností a udělátek, které tu více a tu méně vývojář upotřebí. Ve chvíli, kdy začnete tyhle IDE srovnávat, dopouštíte se nevědomky faulu na jednom nebo na druhém. Pochopil jsem to ve chvíli, když mi došlo proč mi IntelliJ IDEA nevyhovuje. Každý vývojář má v IDE svůj osobitý styl práce a buďto mu do něj IDE vyhovuje a nebo nikoliv. Můžete například říci - teď fábuluji - IntelliJ IDEA má lepší podporu práce s XML. To je ovšem nepodstatné pro vývojáře, který viděl XML naposledy během kurzu na J2EE před deseti lety a od té doby píše Java aplikace pro embedovaná zařízení. Vazba mezi stylem práce a IDE je ovšem obousměrná. Pokud začnete programovat s Eclipse, bude váš styl práce ovlivněný tím, na co si v Eclipse zvyknete. Při přechodu mezi IDE pak logicky srovnáváte, jestli váš styl práce funguje stejně komfortně. Někdy může a někdy nemusí.


Můj styl práce nefungoval v IntelliJ IDEA optimálně nebo řekněme komfortně. V následující části se podíváme na ty body, které mi konkrétně nevyhovovaly. Předesílám, že něco z toho chování, které mi vadilo, šlo možná překonfigurovat v samotném IDE, ale já jsem to buďto nedokázal a nebo se to nechovalo přesně tak, jak jsem si představoval.


Hlavní překážky

Na co jsem si i přes velkou snahu nedokázal nikdy zvyknout. Tato část se nese v duchu toho co mě to v tom lepším případě iritovalo a v tom horším mě to nadzvedlo ze židle. Pojmu to s trochou nadsázky, aby to nebyla nuda. Autoři IntelliJ IDEA se za trochu humoru snad neurazí a pohoršeným fanatickým uživatelům tohoto jinak skvostného IDE se omlouvám.


Můj styl práce v IDE má několik stěžejních bodů. Většinu času jsem pouze v Java editoru, pracuji v rychlých iteracích - compile, test, refactor. Často kusy kódu vytvářím jako prototypy, které postupně obrušuje podle toho, jak se mi to hodí. Často pouštím testy a hlavně dost často mám jednotlivé části projektu v nekompilovatelném stavu, protože když pracuji na jedné třídě a jejím testu, nepotřebuji aby se mi kompilovaly i další části prototypového kódu. Hodně často používám code completion, aby pochopil API nějaké třídy a k tomu potřebuji instantně zobrazit její dokumentaci.


Kompilátor

Při prvním použití kompilátoru jsem měl pocit, že je zpět rok 2002 a já jako elév pracuji s JBuilderem - nechť odpočívá v pokoji. Kompilátor a jeho bezešvou integraci do zbytku IDE považuji za něco esenciálního. Dokážu se přenést prakticky přes cokoliv, ale pokud mám při použití kompilátoru pocit, že jsem se vrátil o dekádu zpátky - a to nikoliv u jedné z jeho vlastností - je něco špatně. Kdyby se takhle choval textový editor za 15$, zvedl bych obočí, ale u softwaru za 500$ mi to hlava nebere.

  • Compile on save. IntelliJ IDEA zdrojový kód kompiluje až když je to opravdu potřeba. Když v debug modu editujete třídu, uložíte jí a čekáte, že se s dalším průchodem kód v běžící JVM zaktualizuje, tak se nic nestane. Teprve potom, co si uvědomíte, že musíte třídu explicitně zkompilovat, vám IntelliJ IDEA milostivě nabídne reload třídy v běžící JVM.
  • Compile Proceed on error. Pokud máte v projektu kompilační chybu, a chcete pustit například test,pak máte smůlu. IntelliJ IDEA se snaží celý projekt nejdříve zkompilovat a to přestože ten test vůbec s kompilační chybou nesouvisí. Jak mi nějaká dobrá duše poradila na Twitteru, můžete z testovací fáze vyjmout závislost na kompilační fázi. To jsem s nadšením provedl, a pak jsem si hodinu drbal hlavu s tím, proč se mi nepoužívá aktuální verze třídy. Odpověď: chybí Compile on save - čili změněné třídy jsem musel vždy kompilovat explicitně. Pokud máte styl práce založený na tom, že refaktorujete částečně odladěné kousky kódu, je tenhle přístup vývoje předem odsouzený k záhubě.
  • Performance. Díky tomu, že se kompilace odkládá až na chvíli kdy jí opravdu potřebujete např. puštění testů, trvá logicky delší dobu, protože se musí zkompilovat všechny změn. Pokud kompilace jedné třídy o sedmi řádcích kódu s chybou trvá 2s - podle toho co hlásí samotné IDE - začne vás to dříve nebo později dost obtěžovat.

Kontextová nápověda

IntelliJ IDEA si dala za cíl, že se díky ní nejenom naučíte znát nazpaměť pořadí a význam parametrů v metodách, ale dokonce i jejich dokumentaci. Píšu System.out. dám ctrl+space v marné naději, že uvidím dokumentaci k jednotlivým metodám. Když najdu konečně tu kýženou metodu s pěti parametry a u třetího zapomenu jeho význam, očekávám, že to samé ctrl+space mi napoví minimálně jeho jméno. Bohužel první klávesovou zkratku, kterou se musíte naučit, je cmd+P pro zobrazení parametrů. Druhou neméně důležitou zkratkou je ctrl+J, kterou IDE přesvědčíte, aby vám ukázalo/obnovilo okno s Javadocem v závislosti na kontextu. Pro uživatele, který je zvyklý dostat celý kontext jedním a tím samým způsobem - code completion - je to dost frustrující. Obzvláště vás to štve při práci s API, které neznáte.


Drobnosti

Nic zásadního, co by nešlo vyřešit jinak, přesto drobnosti, které mě tu více tu méně rozčilovaly.

Favorizované statické importy

Pokud často píšete testy víte, že většina API jsou statické metody doslova na pár třídách (Assert, CoreMatchers, Mockito). V Eclipse si tyhle třídy můžete nastavit do code completion. IDE je potom automaticky nabízí a udělá statický import. Příklad - pokud v Eclipse napíšu v jakémkoliv místě kódu mock a vyvolám code completion IDE mi nabídne odpovídající metody z třídy org.mockito.Mockito, a pokud si nějakou vyberu, provede její statický import. Oproti tomu v IntelliJ IDEA jsem musel nejdříve tu třídu naimportovat a potom nechat danou statickou metodu staticky importovat.


Klávesové zkratky

Nevím z jakého důvodu, ale měl jsem pocit, že klávesové zkratky jsou z nějakého důvodu Windows centric a nerespektují zvyklosti operačního systému. Například zavření editoru pomocí cmd+F4, když v celém zbytku MacOS se používá cmd+W, je mírně řečeno zvláštní. Navíc některé klávesové zkratky jsou spíše cvičení na roztažení prstů než užitečným pomocníkem - ctrl+J (klávesnice MacBooku nemá pravý ctrl) pro refresh dokumentačního okna.


Chybějící Display okno v debugu

V Eclipse jsem si při debugovaní zvykl používat Display okno. To mi umožňuje psát kód, který potom provádím v debugovacím kontextu ve chvíli kdy mi debugger stojí na nějakém break pointu. V IntelliJ IDEA jsem měl něco podobného jenom s tím rozdílem, že to okno bylo vždy popup. To vás začne rozčilovat ve chvíli, kdy ten kód chcete provést s každým průchodem cyklu a vždy musíte ten popup vyvolat.


Celkové dojmy

IntelliJ IDEA je dobré IDE a dokázal jsem v něm i s těmi výhradami fungovat půl roku. Všechny zkušenosti v tomhle článku jsou ryze subjektivní. Umím si představit, že někomu jinému vadí/nevadí jiné chování a vlastnosti ať již jednoho nebo druhého IDE. IntelliJ IDEA mi přišla trochu více přeplácaná všemi možnými UI prvky než by bylo potřeba a trochu méně svižná. Navíc někdy se snažila být papežtější než papež, při rename rafactoru mi například přejmenovala nějaké nesouvisející výskyty řetězce, čehož jsem si vůbec nevšiml. Těch šest měsíců bylo dobrých v tom, že jsem se naučil nové IDE a zjistil, že v něm můžu bez velkých problému fungovat. Na druhou stranu, čím déle jsem v tom IDE trávil, tím více jsem měl dojem, že mi toho oproti Eclipse tolik nepřináší. Chtěl bych dodat, že jsem se poctivě učil klávesové zkratky, které by mi mohly práci urychlit. Později jsem si uvědomil, že to není chybou IDE, ale stylem mojí práce, který byl formován v Eclipse a v IntelliJ IDEA prostě nefunguje stejně efektivně.


V celém článku se odkazuji na zkušenosti s IntelliJ IDEA 13, kterou jsem používal v rámci Early Access Programu. Jenom pro pořádek dodávám, že stahování artefaktů z Maven repa vyžadujícího SNI v rámci HTTPS nefunguje ani v IntelliJ IDEA.