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?

neděle 4. února 2007

6 nástrojů pro úspěšně fungující vývoj

Vývoj to je především souhra procesů a nástrojů. V tomto článku se podíváme na pět základních nástrojů, které musí mít každý softwárový tým, který chce úspěšně fungovat. Všechny tyto nástroje fungují ve vzájemné kooperaci a proto se jejich přínos zároveň násobí.

Overview

Source repository

Repositoř zdrojových souborů a správa, plus jejich verzování je dneska základ. Kdo by také dnes neznal značky jako, CVS či SVN. Při výběru repositoře pro zdrojáky doporučuji zohlednit jeden velice důležitý faktor a to podporu v IDE. Command line klient sice není k zahození, ale komfort poskytovaný v IDE je k nezaplacení.

Buildovací systém

Buildování projektu je to, co chceme mít maximálně automatické, protože automatické rovná se bezbolestné. Co by měl být schopný buildovací systém udělat?

  • checkout zdrojových souborů včetně závislostí mezi jednotlivými komponentami
  • checkout knihoven třetích stran z centrálního úložiště
  • vlastní buildování do finální podoby (JAR, WAR, EAR atd.)
  • build API dokumentace (JavaDoc)

Z těch obecnějších požadavků je to určitě možnost integrace s nástroji třetích stran jako jsou například různé analyzátory kódu. Velice užitečnou vlastnost představuje možnost vygenerování projektových souborů do IDE. Jako prověřená dvojice v mnoha open source projektech se jeví Maven 2 a Ant.

Continuous Integration systém

Dedikovaná mašina se speciálním softwarem jehož jediným úkolem je kontinuálně volat buildovací systém a jeho výsledky podstupovat automatickým testům. Výsledky testů, problémy při buildu a další užitečné statistiky reportovat vývojářskému týmu. Co bychom měli od CI systému vyžadovat.

  • možnost integrace se zvoleným buildovacím systémem
  • distribuovatelný build (vlastní úlohu je možné distribuovat na jiný stroj)
  • spolupráce se zvoleným soruce repostiory sytémem (tagování zvolených buildů např. milestone, RC, final build)
  • integrace s IDE (možnost spouštět buildy, sledovat průběh, zobrazovat logy)
  • možnost reportování skrze mail či instant messanging (ICQ, Jabber)
  • plánovač (scheduler) buildů, ruční pouštění buildu
  • webové rozhraní pro správu

Issue tracker

Nástroj pro reportování a správu problémů a vylepšení. Klasickým příkladem budiž Bugzilla. Mezi základní vlastnosti musí patřit issue management, což znamená stavy s kterých přechází issue v průběhu času. Další neméně důležité vlastností jsou notifikace při změnách, snadná obsluha přes webové rozhraní a silné vyhledávání.

K nadstavbám, které se ocení postupem času musím zmínit opět integraci s IDE a se source repoitory systémem. Při integraci se source repository systémem je užitečné vidět jaká revize souvisí s jakým bugfixem.

Správa dokumentů

Pro správu dokumentů všeho ražení, od analýz až po zápisy z jednotlivých porad je potřeba systém, který bude nenáročný na údržbu a bude v něm možné jednoduše vytvářet dokumenty a ty mezi sebou vzájemně odkazovat. Základní požadavky.

  • snadná tvorba i pro BFU (Běžný Franta Uživatel) bez nutnosti vlastni speciální program, nejlépe přes prohlížeč
  • distribuovatelné s otevřeným formátem (žádné dokumenty proprietárního ražení WORD sdílené pře síť)
  • správa historie verzí (diff, logování změn)

Ideálním řešením je použití libovolné implementace WIKI.

Statické analyzátory kódu

Statické analyzátory kódu slouží k odhalování potenciálních problémů dříve než mohou nastat a k počítání statistik, které poskytují užitečné informace o zdrojovém kódu. Z informacím, které mohou poskytnout bych jmenoval, pokrytí API testy (takzvaný code coverage), často se opakující kód a nebo nevyužitý (mrtvý) kód, dodržování code convention atd.

Opět platí, že tyto nástroje by měly být integrovatelné s IDE a buildovacím systémem a o jejich spouštění by se měl starat CI server, který by měl zároveň jejich výsledky reportovat.

Související články