středa 7. února 2007

IDE - inovace v mezích pokroku

V předchozím článku 6 nástrojů pro úspěšně fungující vývoj se táhla jedna myšlenka, kterou bych rád rozvinul. Inspiraci jsem také čerpal z dnešního rozhovoru s Dušanem Pavlicou (Sun) o inovacích a vizích pro budoucí verze IDE.

O IDE a jeho funkcích se dá uvažovat různými směry, otázkou je kam by měla směřovat jejich vývoj v oblasti inovace. Co by měly IDE přinášet, aby byly pro vývojáře dostatečné efektivním nástrojem. Cesta zapracovávání stále nových frameworků, které se vezou na aktuální vlně popularity, může sice přinést kýžený efekt, nicméně jeho trvání je pouze krátkodobé.

Základem je uvědomit si, s jakými dalšími nástroji krom IDE vývojář ještě pracuje. Ve zmíněném článku to je šest nástrojů: source repository, buildovací systém, continuos integration server, issue tracker, analyzátory kódu. Samozřejmě tato šestice není konečná, protože firmy si podle svých potřeb řídí využití dalších nástrojů.

V blízké budoucnosti bude pro IDE výzvou právě integrace s dalšími nástroji, které vývojář používá při svojí práci. Je samozřejmé, že některé nástroje budou pro integraci vhodnější a jiné nikoliv. Pěkným příkladem je podpora source repository, které ukázalo cestu jak na to.

Z vlastní zkušenosti mohu říci, že od doby integrované podpory source repository v IDE, nemám potřebu používat řádkového klienta. Podpora v IDE mi prostě na běžnou práci stačí, ba co více je velice komfortní. Pokud platí, že vývojář z 80% využije u daného nástroje 20% vlastností, tak není těžké si představit integraci například issue trackeru.

Nemyslím si, že by se integrace těchto nástrojů měla zaměřit pouze na integraci konkrétních produktů. IDE by mělo definovat rozhraní, pomocí kterého by bylo možné integrovat nástroje dodávané různými výrobci. Prostředník (konektor, zprostředkovatel - vlastní implementace dodávaná výrobci nástroje nebo IDE) by pak umožnila komunikaci komponent v IDE a daného systému přes předem definované rozhraní.

Na úrovni IDE by se pak daná část (issue tracker, continuos integration) chovala a vypadala úplně stejně ať již by se v pozadí používal produkt A nebo produkt B. IDE tedy implementuje typický případ užití daného typu nástroje, například vytvoření bug reportu, z pohledu práce ve vývojovém prostředí a zároveň definuje rozhraní, přes které se tato "událost" propaguje vnějšímu prostředí.

Z hlediska architektury by řešení mohlo vypadat následovně.

Pozn: Tool API definuje rozhrani z hlediska IDE. SPI connector je prostředník mezi produktem a IDE, implementuje produkt nebo vývojáři IDE.

Podobný model jaký je vidět na předchozím obrázku využívají všechny stávající IDE pro možnost jejich rozšíření. Rozdíl je v tom, že tool API je již konkrétní implementací pro dany typ produktu (issue trackeru, build systém CI server atd.), což již žádné IDE takhle do hloubky nedělá.

Výše předestřený koncept je zároveň výzvou nejen pro IDE, ale i pro vlastní produkty, o tom nemůže být pochyb.

Zajímá mě Váš názor. Jakým směrem by se měl vydat vývoj IDE?