25. prosince 2012

5 let na volné noze

Je konec roku a to je vždy dobrý čas se zastavit a popřemýšlet. Je to přibližně 5 pět, co jsem byl na procházce s kočárkem s malou a rozhodl se, že skončím v zaměstnání a začnu pracovat na volné noze. Do týdne jsem podal výpověď a vše se to rozjelo ...

Našel jsem svoje staré poznámky, kde jsem si před 5 lety začal malovat svoji budoucnost a své představy práce na volné noze a přijde mi celkem zajímavé se podívat na mé počáteční očekávání a srovnat ho se současnou realitou.

Na volnou nohu jsem šel z těchto důvodů (moje představa před 5 lety):

  1. chci být svým pánem, pánem svého času
  2. chci mít více dovolené než standardních 5 týdnů
  3. chci co nejvíce programovat a navrhovat aplikace
  4. chci zkusit co nejvíce projektů a tedy knihoven, technologií, postupů, metodik, lidí, firem ...
  5. chci vydělávat více než jako zaměstnanec


Taková byla moje dřívější představa a teď jak to bylo/je reálně:

ad 1) Tato představa je do jisté míry naivní, protože pořád má člověk nějaké vedoucí, někoho jiného, kdo mu určuje termíny, práci apod. Pokud někdo pracuje formou body shoppingu, pak je to možná ještě horší než když je někdo zaměstnán. Já ale naštěstí s tímto neměl nikdy problém, protože se mi vždy brzy podařilo získat důvěru, takže na většině projektů jsem dělal nebo dělám kde a kdy potřebuji, tj. nemusím dojíždět každý den do práce přímo k zaměstnavateli, práci si většinou řídím sám, zodpovídám se za odvedenou práci v dohodnutých termínech.
Pokud někdo dělá zakázkové projekty, pak je to samozřejmě lepší, ale stále není člověk zcela nezávislý. Já osobně absolutní většinu času věnoval a stále věnuji body shoppingu, kdy se nechávám najímat na konkrétní projekty. Projekt na zakázku jsem měl pouze jeden za celou dobu.

Nicméně je nutné říci, že pocitově je to mnohem lepší než být zaměstnanec - vyhovuje mi ten pocit volnosti, pocit, že já jsem svým pánem a já jsem zodpovědný za svá rozhodnutí. Samozřejmě musím plnit termíny, musím často dělat, co mi někdo řekne, ale pokud vyloženě něco dělat nechci, tak to nedělám. Ale i tak je pořád dost prostoru pro řízení svého času. Také mám rád, že jsem neomezený ve výběru počítače, mobilu, auta, firemních výhod atd.


ad 2) Rád a hodně cestuji, rád jezdím na dovolené a 5 týdnů dovolené mi přijde málo. V tomto bodě se mé očekávání splnilo, dovolené mám více než dříve jako zaměstnanec. Je ale také nutné říci, že pořád (bohužel) jsem ve stavu, že pokud nedělám, tak mi nikdo nic nedá, žádnou placenou dovolenou nemám a nikdo kromě mě mi peníze nevydělá. Toto beru jako největší nevýhodu současného stavu a již nějaký čas se to snažím změnit - vymyslet a zrealizovat nějaký svůj projekt, nechat jiné lidi na mě dělat. Zatím se mi toto moc nedaří, ale nechci zbytečně tlačit na pilu, věřím, že to někdy přijde.

Na začátku práce na volné noze jsem pořád byl myšlením zaměstnanec, který ale nebyl zaměstnán. Postupem času ale na sobě vidím, že člověk začíná být více podnikatelem než zaměstnancem, myšlení se postupně mění, začíná být více kreativní a z toho mám dobrý pocit.


ad 3) Když jsem končil po 6 letech jako zaměstnanec, tak jsem měl pocit, že čím dál více sedím na schůzkách, něco nebo někoho organizuji a čím dál méně programuji. Programování, návrh aplikací, obecně vývoj aplikací je svým způsobem řemeslo, kterému jsem věnoval několik let svého života, abych se to vše naučil, a proto mi bylo líto to najednou vše hodit za hlavu. Proto jsem si řekl, že bych si chtěl ještě pár let pěkně zaprogramovat. Navíc mám i ten pocit, že opravdu zkušených lidí na volné noze moc není a sám v tom tedy vidím výhodu.

V současné době mě pořád programování baví, mám rád, když vím, co mám dělat, mohu se někam zavřít a udělat kus kvalitního kódu. Ale už si nedokážu představit, že bych jen programoval celý týden. Mám rád, když je to pestré - programování a architektura aplikací, analýza aplikace, team leading, příprava obchodních nabídek, product management, školení a prezentace, analýza výkonnosti, konzultace přímo u zákazníků atd. Toto vše se mi daří střídat, mám to pestré, i když programování s návrhem aplikací a team leading jsou hlavní.

Před začátkem jsem měl obavy, že mě budou hodně direktivně řídit, když si mě budou najímat, že budu dělat podřadné práce, a že mě to nebude bavit. Toho jsem se bál asi nejvíce. Ale naštěstí k tomu nikdy nedošlo, ba naopak jsem byl překvapený, kolik volnosti jsem vždy dostal. Je to vše o důvěře.

Kromě samotné práce se snažím být podnikatelem - uvědomuji si, že technické znalosti a zkušenosti je jedna (nezbytná) věc, ale bez schopnosti se prodat, bez schopnosti oslovit, komunikovat a zjistit potřeby zákazníka to prostě nikdy nepůjde. Navíc hodně rychle si člověk uvědomí, že bude mít takové podmínky a peníze, jaké si je schopný domluvit.


ad 4) I když jsem byl zaměstnancem, tak jsem měl tendence měnit často práci - sám na sobě vidím, že ideální čas projektu je tak jeden rok - vždy se do nových projektů vrhám po hlavě, makám a pak po roce začínám cítit nějakou únavu a potřebu změny.
Zase tolik projektů resp. zákazníků jsem neměl. Za celou dobu jsem dělal pro 4 zákazníky (když počítám pouze vývojové projekty) a projektů samotných bylo možná 10.  A díky dalším malým projektíkům (na týden vyrazím do firmy a dělám analýzu výkonnosti nebo nějaká školení nebo sem tam pomáhám s obchodními nabídkami) to mám hodně různorodé a stále mám možnost se učit nové a nové věci. Snažím se držet zákazníků, kde jsem spokojený, kde to funguje, než se bezhlavě pouštět někam, kde to neznám.


ad 5) Lhal bych, kdybych nenapsal, že toto byl jeden z hlavním důvodů, proč jsem to šel zkusit. A jsem jednoznačně spokojený, více než jsem čekal. Jsem typ člověka, který nerad šetří (možná to ani neumím) a nerad se omezuje a vždy když jsem něco potřeboval nebo chtěl, tak jsem se snažil na to vydělat, něco změnit, zlepšit, abych si to mohl koupit.

Je ovšem potřeba mít nějakou finanční disciplínu - zaměstnanec dostává každý měsíc svojí výplatu a může se víceméně na to spolehnout. Na volné noze tomu vždy takto být nemusí - je pravda, že většina plateb má měsíční periodu, ale neplatí to vždy a je nutné s tím počítat. Navíc se musí myslet na nejhorší - člověk onemocní, něco se mu stane a v ten moment mi nikdo nic nedá, musím se vždy umět postarat o mojí rodinku. Zjistil jsem, že úroveň klidu je úměrná velikosti mé finanční rezervy. Také je vhodné mít projektů více než vše sázet na jednu kartu.



A co nějaké nevýhody? Přiznám se, že jsem musel chvíli přemýšlet, abych nějaké uvedl.
Někdy mi vadí ta nejistota - bude projekt pokračovat? Co budu dělat potom? Naštěstí to není moc často a ještě se mi nestalo, že bych někdy neměl placenou práci pro zákazníka. I když já si často myslím, že je to jen iluze, že zaměstnanec má něco jistého, obzvláště v dnešní době.

Placené vzdělávání. Jako zaměstnanec jsem byl na pár konferencích (i v zahraničí), měl jsem placenou možnost se vzdělávat, udělat si certifikace. Dnes se vzdělávám hlavně v mém volném (= neplaceném) čase a pokud jdu na nějakou konferenci, tak musím být přesvědčený, že to k něčemu bude, když si to sám platím. To samé o certifikaci a vůbec o všech výdajích, které mám s podnikáním spojené.

Možná je nevýhodou i to, že se na čas koukám mnohdy přes peníze (nikdy ale ne na úkor rodiny nebo volného času). Jak někdo trefně napsal, každý má čas pouze jeden, a proto je nutné ho efektivně umět využívat.

Již si moc nedovedu představit, že se vrátím zpět a budu opět někde zaměstnaný. Naopak chci se posouvat dál a něco zajímavého vytvořit, nedělat jen cíleně pro někoho druhého.

21. prosince 2012

PF 2013





13. prosince 2012

Kolik je Java vývojářů v ČR?

Český statistický úřad nedávno vydal přehled Informační ekonomika v číslech 2012, kde lze vyčíst zajímavé statistické informace o našem oboru. Nejzajímavější je část o struktuře lidí v IT, kde je vidět, že počet lidí ve škatulce "Analytici a vývojáři softwaru a počítačových aplikací" je 34 200.

To mě přimělo se zamyslet, kolik z toho je tedy Java vývojářů, jak velká je u nás základna? Výpočet je to hodně přibližný, ale pro nějakou představu se to může hodit.

1. Analytiků a vývojářů je 34 200. Jaký je poměr mezi oběma profesemi? Snažil jsem se najít nějaké informace na internetu, ale nic moc. Můj odhad podle zkušeností je 1:3. Jeden analytik v průměru na tři vývojáře, tedy 25 650 vývojářů. Z pohledu uvedené statistiky lze ještě čekat, že ve škatulce vývojáři budou i testeři. Poměr vývojářů a "čistých" testerů vidím tak 7-10 : 1, tady vůbec netuším. Když vezmu ten horní poměr, tak to vychází na 23 318 vývojářů celkem.

2. A kolik z toho je Java vývojářů? Tady už jsem našel podobnou úvahu, ale pro celosvětové měřítko a z té vychází, že Java vývojářů je cca 16% všech vývojářů, tedy pro nás 3 730.

Je to celé dost na vodě, ale řekněme, že nás je asi 3700 :).

Pokud máte někdo nějaká přesnější data, tak je prosím uveďte, ať to upřesníme.

13. listopadu 2012

Prezentace: profesionální programátor = nedostatkové zboží

Dnes jsem měl na Západočeské univerzitě přednášku pro studenty o realitě vývoje, o tom, proč je dobré být programátorem a jaké by takový programátor měl mít vlastnosti.
Přechody mezi slidy jsou vyplněny citáty od Roberta Dreslera


7. listopadu 2012

Jak snížit chybovost na projektu?

V dnešním článku se chci zamyslet nad tím, jak co nejlépe (= s minimem nákladů mít maximální užitek) snižovat chybovost během vývoje aplikace. Chyby dělá každý a kdo říká, že ne, tak nemluví pravdu.

Produkce chyb na softwarovém projektu je funkcí práce a velikosti projektu, takže je možné tuto produkci odhadnout. Jonesova data (Capers Jones) říkají, že typický projekt produkuje celkově asi 5 chyb (myšleno v celém vývojovém cyklu) na funkční celek, což znamená asi 50 chyb na 1000 řádků kódu. Čím větší projekt je, tím se výrazně zvyšuje i hustota chyb. (vybráno z knížky Odhadování softwarových projektů, Steve McConnell)
Existuje množství způsobů resp. postupů, jak ve všech fázích vývoje hledat a odstraňovat chyby. Následuje seznam těchto možností, který je seřazený sestupně podle efektivity, kterou definuji takto: nejefektivnější způsob detekce chyb je takový, který mi dokáže nalézt co nejvíce chyb s nejmenšími náklady - rychlým, jednoduchým způsobem, co nejdříve během vývoje.
  1. UML modelování - nejsem velkým zastáncem velkého modelování, ale na druhou stranu si nedovedu představit, že bych začal hned programovat aniž bych si cokoliv namodeloval. UML je standard, který usnadňuje komunikace uvnitř týmu i směrem k zákazníkovi. Obecně jakákoliv vizualizace usnadňuje komunikaci a vzájemné porozumění. Když modeluji, tak mi to umožňuje se na aplikaci dívat z různých pohledů a nutí mě to přemýšlet a tím eliminovat věci, na které zapomenu.
  2. prototypování - myslím zejména prototypování uživatelského rozhraní pomocí vhodných nástrojů, ale může být i třeba prototypování na úrovni serveru, modulu apod. ve smyslu proof-of-concept.
  3. revize návrhu - před samotným vývojem provést formální/neformální revizi návrhu celého řešení a výběru technologií
  4. jednotkové testování - nezbytná součást vývoje aplikace. Je nutné vhodně definovat úroveň testování, tak aby to bylo opravdu efektivní - vývoj produktu vs. vývoj jednorázové aplikace. V prvním případě bych se snažil o 70-80% pokrytí, u druhého případu by mi nevadily ani poloviční hodnoty.
  5. inspekce kódu během vývoje samotného vývoje - zde nepočítám jen týmové inspekce, ale často není od věci si projít a zkontrolovat svůj kód sám.
  6. integrační testování - "ověřování, že nově přidané funkcionality spolu nekolidují a pracují stejně jako během feature testů i po zaintegrování z jednotlivých vývojových větví do hlavního projektu" (viz wiki)
  7.  klasické lidské testování
Seznam možností není určitě úplný, uvedl jsem jen ty, které jsem někdy již použil nebo chci použít. Zajímalo by mě, jaký způsob preferujete vy?

4. října 2012

Nástroje pro prototypování GUI

Pokud dneska navrhuji novou aplikaci, tak si to bez prototypování uživatelských obrazovek vůbec nedokážu představit. O to více se divím, že byli dříve časy, kdy jsem byl schopný si vystačit pouze s textem. Což samozřejmě nikdy moc dobře nefungovalo.
Je nutné minimalizovat nejasnosti a nedorozumění mezi vývojovým týmem a zákazníkem, předcházet neočekávanému. Je potřeba mít "něco" nad čím se můžu se zákazníkem bavit ještě dříve než vývojový tým začne programovat, "něco" co mi umožní získat co nejdříve zpětnou vazbu na to, jak to celé má vypadat a fungovat.

Z tohoto pohledu se mi jeví jako ideální drátěné modely (wireframes). Používáme k velké spokojenosti Balsamiq Mockup. Je to nástroj postavený nad flashem, nabízí jak webovou, tak desktopovou verzi, dokonce i pěkný plugin do Confluence a JIRY. Mezi všemi verzemi funguje bezproblémový export/import.



Při výběru jsme prošli a vyzkoušeli hodně nástrojů, na některé z nich přikládám odkaz a krátký komentář.

Balsamiq Mockup
  • Nástroj pro rychlý návrh mockup a drátových modelů.
  • Desktop aplikace, web aplikace, plugin do dalších systémů (Google Drive, Confluence, JIRA, XWIKI, …)
  • Desktop aplikace - 79$ na jednoho uživatele, Web aplikace – od 12$/měsíčně 
    Pluginy – ceny se liší v závislosti na použitém systému a způsobu licencování
  • Desktop aplikace – Windows, OS X, Linux, ostatní platformy s podporou Adobe AIR.
    Web aplikace a pluginy – Internetový prohlížeč + Flash 
  • Komplexní nástroj pro designéry.
  • Web aplikace - Internetový prohlížeč
  • Předplatné od 7$/měsíčně
Inpreso Screens
  • Nástroj pro vytváření kvalitních mockup modelů.
  • Desktop aplikace – pro chod aplikace je nutný Adobe AIR
    Web aplikace - Internetový prohlížeč + Flash
  • Omezená verze zdarma, předplatné 29$/rok na jednoho uživatele
  • Nástroj pro vytváření prototypů. Lze jít nad rámec vytváření drátových modelů a prototypů přidáváním událostí.
  • Web aplikace - Internetový prohlížeč
  • Zdarma
 GUI Design Studio
  • Nástroj pro vytváření návrhů pro prostředí Windows. Lze ho použít k rychlému vytvoření prototypů kreslením obrazovek s využitím standardních Windows prvků a jejich propojením, aby bylo možné následně simulovat chování.
  • Desktop aplikace – Windows
  • Od 129$ za jednu licenci
  • Silný nástroj pro vytváření drátových modelů aplikací.
  • Desktop aplikace – Windows, OS X
  • Desktop aplikace - Omezená verze zdarma
    Pro verze 495$ za licenci

  • Webový nástroj pro rychlé vytváření drátových modelů a prototypů GUI pro web, mobilních a podnikových aplikací. Umožňuje pohodlné testování použitelnosti a inteligentní spolupráci.
  • Web aplikace - Internetový prohlížeč
  • Předplatné od 9$/měsíčně
Další nástroje a odkazy bez komentářů:

3. září 2012

Odhadování projektů

Přečetl jsem nedávno knížku Odhadování softwarových projektů a protože mi knížka přišla povedená, tak bych rád publikoval pár faktů/myšlenek, které mě zaujaly:

  • Dobrý odhad je odhad, který poskytuje dostatečně jasný pohled na realitu projektu, aby vedení projektu mohlo dělat dobrá rozhodnutí, jak projekt vést, aby bylo dosaženo cíle. (pozn. text označený kurzívou je citací z uvedené knihy)
  • správný/špatný odhad pracnosti projektu má často zásadní vliv na celkový výsledek projektu. Je proto pro mě překvapivé, jak málo se ve firmách věnuje správnému odhadování. Přitom podle odhadu se stanovují termíny, alokují zdroje, vytváří se rozvrh, ...
  • odhady budou vždy tak přesné, jak budou přesné informace, podle kterých se odhaduje. Odhad nemůže být přesnější, než je na dané pozici projektu podél kužele možné (viz obrázek). Odhady je nutné postupně zpřesňovat.
  •  je velké množství způsobů, algoritmů a postupů, jak odhadovat, ale jeden ze všech mi přijde nejvěrohodnější a přitom jednoduchý - odhady nového projektu na základě historických dat. Každá firma, které má za sebou realizaci nějakých projektů, může s velkou pravděpodobností očekávat, že další projekty budou podobné, že se pracnost významně nezmění. Přitom by stačilo tyto historická data ve firmě shromažďovat a za každou realizací se na chvíli otočit a říci si, co se povedlo a co ne a hlavně se z toho poučit.
  • Záměrně nepodhodnocujte. Cena za podhodnocení je vyšší než za nadhodnocení. Problémy s nadhodnocením řešte plánováním a řízením, ne posuny odhadu. 
  • vývojáři mají často příliš optimistické odhady
  • Technickým pracovníkům patří odhady, netechnickým pracovníkům (obchod, marketing) pak cíle. Techničtí pracovníci mají udělat co nejlepší odhady a být schopni je zdůvodnit, netechničtí pracovníci pak musejí být schopni rozhodnout. Obě skupiny lidí by měli být schopni se na výsledných závazcích společně domluvit.
  • často se odhady mění pod tíhou jednání s vedením, což je špatně - odhady nelze měnit, pouze lze měnit závazky, ke kterým se zavazujeme (verze aplikace bude bez určitých funkcí, termín vydání verze se posune atd.).
  • vyhněte se uspěchaným odhadům, později toho budete litovat
  • pokud je potřeba provést kvalifikovaný odhad, pak je nutné použít více metod odhadování. Pro různé fáze projektu (viz kužel) se hodí různé metody odhadování. Výsledky různých metod by se neměly lišit o více než 5%. Jinak hledejte důvody, proč tomu tak je.
  • Rozložte velké odhady na malé části, abyste využili zákona velkých čísel: chyby na dolní stráně se do určité míry vyruší s chybami na straně horní. Tím lze do jisté míry eliminovat různé předsudky a subjektivní myšlení lidí, kteří odhady provádějí.
  • Neřešte nejistotu v odhadu posunem. Vypořádejte se s ní tak, že odhad vyjádříte s jistou neurčitostí. 
  • Je chybou vyjadřovat odhad právě jedním číslem, protože je to hodně zavádějící. Buď zvolit interval odhadu (odhad 50-70MD vyjadřuje jiný vztah k riziku než 60MD) a nebo prezentovat jeden odhad, ale spolu s pravděpodobností jeho dosažení (projekt zrealizujeme za 50MD s 50% pravděpodobností). Závazek ale již musí být jasný a konkrétní.
  • Různé studie ukázaly, že většinou není problém v samotném odhadu, ale v tom, že se na spoustu věcí zapomene a ty pak v odhadu nejsou zohledněny. Proto je dobré mít nějaký standardizovaný postup, nějakou šablonu všech opakujících se funkčních/nefunkčních požadavků a z té vycházet.  
  • Soustřeďte se nejprve na odhad velikosti. Pak z něj vypočtěte práci, rozvrh, cenu a vlastnosti.
  • Nezkracujte odhad rozvrhu projektu bez navýšení odhadu práce.

8. června 2012

Pár zkušeností z code review

Již je to nějaký pátek co jsem ve firmě zavedl code review a za tu dobu mám zapsaných pár poznámek, které bych rád publikoval:

  • úplně na začátku jsem měl snahu o čisté code review, ale s postupem času se více začalo jednat o pravidelnou programátorskou schůzku, kde je sem tam i "veřejné" code review. Důvody jsou asi dva - kvalitní code review vyžaduje přípravu a řekl bych, že délka přípravy celkem odpovídá výslednému efektu code review. Bohužel jsem vždy neměl pocit, že code review mělo ten výsledný efekt, který jsem očekával, takže postupně jsem i já sám do toho přestal dávat tolik času a energie. Dalším důvodem je pak nástroj Crucible, který jsme začali používat.
  • současná podoba programátorské schůzky je asi tato: každý týden půl hodiny, kde probíráme změny v API, jaké koncepční změny se udály nebo teprve přijdou a samozřejmě probíráme i kód, který v pozitivním/negativním smyslu má cenu ukázat veřejně a nějak ho zhodnotit.
  • všechny důležité a odsouhlasené věci je nutné vždy někde evidovat, protože hned druhý den si to nikdo nepamatuje. Navíc sem tam někdo chybí na schůzce, takže je potřeba toto publikovat pro všechny.
  • schůzka má vždy jednoho moderátora
  • procházení, komentování a veřejné ukazování zdrojových kódů je hodně o "sociálním cítění", o komunikaci, protože spoustu programátorů bere "svůj" kód za čistě svojí věc, navíc dost lidí není připraveno na veřejnou kritiku své práce. Vždy se tedy snažím před code review odmazat jakékoliv jména osob, aby hned na první pohled nebylo zjevné, komu daný kód patří. A musím prostě volit velice opatrný přístup, když něco/někoho chci kritizovat. Cílem těchto schůzek není někomu ukázat, že je špatný, ale ukázat možné chyby, problémy, které může dělat úplně každý. Tento bod hodně souvisí se složením týmu - dělal jsem v týmu, kde člověk mohl říci jakoukoliv kritiku, všichni to brali úplně v pohodě a všichni věděli, že jde hlavně o tým. Jiné týmy mají více individualistů, introvertů apod. a tyto věci tak dobře nefungují. To tak prostě je a zde je vidět, že vývoj není jen o technických znalostech, ale vůbec o schopnosti komunikace.
  • programátorské schůzky mám často spojené se zaváděním nových věcí - nové konvence psaní kódu, nové API k použití apod. Pokud chci aplikovat nějaké nové pravidlo, tak musí být jasné a definované (ideálně bez výjimek) v jedné, dvou větách. Obrázky vše mnohem lépe vysvětlují. Jakmile je cokoliv složitějšího, úspěch je předem nemožný.
  • pokud objevím nějakou chybu v mém kódu, která stojí za ukázání ostatním, tak ji vždy ukazuji - pokud se já snažím ostatním říkat, že něco mají špatně nebo mohli by mít lépe, pak musí všichni cítit, že každý dělá chyby (i já), a že je to naprosto normální. Jen je potřeba se toho vyvarovat do budoucna.
  • pokud chci něco změnit v aplikaci resp. zavést nějaké nové pravidlo, tak se mi často vyplatilo, že jsem to sám v celé aplikaci upravil. Programátoři často bez přemýšlení kopírují kód a díky tomu  se špatný kód šíří mnohem rychleji než ten dobrý. 
Jaké jsou vaše zkušenosti s code review nebo obecně s programátorskými schůzkami?

25. dubna 2012

Crucible - nástroj na code review

Crucible je další z nástrojů od Atlassianu (kromě již známých nástrojů JIRA a Confluence).  Crucible je nástroj na code review. Umožňuje prohlížení zdrojových kódů a vytváření jeho review včetně workflow kolem. Crucible slouží jako komunikační kanál mezi vývojáři nad zdrojovým kódem - vše na jednom místě, vše sledovatelné a dohledatelné.

Přínos efektivního code review je zřejmý, ale často je problém, jak vlastně code review dělat, aby bylo opravdu efektivní. Efektivní code review musí z mého pohledu splňovat tyto podmínky:

  • šíření informací všem členům týmu
  • vše zpětně dohledatelné
  • minimální časová náročnost resp. čím méně času, tím lépe
  • nesmí nabourávat vztahy v týmu (není vždy jednoduché být kritický a nikoho se tím osobně nedotknout)
Když jsme s code review začínali,  tak to vypadalo přibližně tak, že jsme se každý týden na půl hodiny až hodinu potkali osobně, kde jsme procházeli části kódu, upozorňovali na časté nedostatky nebo informovali se o změnách v našich interních API. Toto nejčastěji prováděl team leader. Tento přístup má řadu nevýhod:
  • každý nemůže vždy přijít na osobní setkání, takže se k němu dané informace nedostanou (je pravda, že důležité věci, případně nějaká rozhodnutí jsme zapisovali do interní wiki, ale i tak spoustu informací ze samotného code review nikde zaznamenána nebyla)
  • chybí jedno místo, kde lze informace z code review hledat. Něco se řekne na schůzce, něco se pošle mailem a pak je problém se k některým tématům vracet, dohledávat je
  • samotná kontrola zdrojového kódu probíhá ručně, často náhodným výběrem několika tříd. Chybí nástroj, který vás v tomto podpoří, přidá do toho trochu nějaký systém.
  • vždy bylo nutné mít zdrojový kód v repository, aby si ho někdo další mohl prohlížet
Kvůli těmto nedostatkům jsme začali hledat vhodný nástroj a Crucible nám je pomohlo odstranit.  Crucible nabízí integraci s dalšími svými sourozenci, zejména s JIROU - není tedy problém vytvořit nové review přímo z JIRY k souborům napojených k danému tásků. I na podporu v IDE se nezapomnělo - mohu přímo v IDE vybrat soubory a vytvořit k nim nové review v Crucible (podpora je zatím jen pro IDEU, pro Eclipse zatím chybí). 

Máme teď tedy v týmu nástroj, který umožňuje komukoliv a kdykoliv založit požadavek na review vybrané části kódu a tím získat zpětnou vazbu. Když si člověk uvědomí, že žádné API není hned v první verzi dokonalé, že je potřeba získávat zpětnou vazbu na svoje návrhy a svoji práci, tak máme nástroj, který nám s tím dokáže pomoci.

Standardně součástí Crucible je i FishEye, což je taková hodně komfortní prohlížečka zdrojových kódů v repositářích. Za FishEye je ale nutné platit nemalé peníze navíc, tak zatím používáme samotné Crucible - chybí několik zajímavých pohledů do repositářů, ale z pohledu samotných review se nic nezměnilo.

5. dubna 2012

Zkušenosti s Bootstrap

Znáte Bootstrap, řešení pro prezentační vrstvu od Twitteru? My jsme ho měli možnost vyzkoušet na menším projektu pro administrační část a rád bych se podělil o naše zkušenosti:

  • Bootstrap jsem objevil někdy minulý rok na podzim a od té doby ho sleduji a je vidět, že se rozvijí, že žije. Množí se také informace na internetu, začíná se to používat. Např. článek To Bootstrap or Not?
  • nám se hodně libí jednotnost a jednoduchost celého řešení, nemusíme řešit jednotlivé prohlížeče, celkem rychlý vývoj. Úvodní konfigurátor je pak jen taková třešnička na dortu.
  • od začátku jsme měli jasno, že chceme Bootstrap použít jen na admin část a pro tento účel jsme byli spokojeni. Nicméně si nemyslím, že by to bylo vhodné řešení pro jakékoliv webové řešení, zejména pro ty složitější (např. naše snaha o výběr technologie na klienta).
  • náš technologický stack byl následující: Spring MVC, Freemarker, Sitemesh, Bootstrap, jQuery
  • jako nedostatek bereme nepřítomnost komponenty pro výběr datumu. Museli jsme tedy vzít tu z jQuery - nebyl to žádný velký problém, ale už jsme museli trochu řešit jednotnost vzhledu a upravovat to
  • další výtka míří k dokumentaci - na první pohled je moc pěkná, vše hezky vizuálně zdokumentované, ale pokud pak člověk jde do detailu, tak ty informace sem tam prostě chybí. V lepším případě je člověk dohledá na internetu a nebo nejsou. Vzhledem k tomu, že se jedná o firemní framework publikovaný ven, tak oni ve firmě to know-how zřejmě mají, jen se všechno nepodařilo zdokumentovat pro ostatní. Diskuzní fórum jsme nenašli.
  • kolegům se nepodařilo vůbec rozchodit dvě věci - Transitions (jQuery plugins) a hover popover.
 Máte vy nějaké zkušenosti z Bootstrap?

26. března 2012

Acceptance test driven development

Pro většinu z nás jsou unit testy naprostou samozřejmostí a pokud budu mluvit sám za sebe, tak si to bez unit testů už nedovedu představit. Nejvíce to vidím, když opravuji starý kód, jak jsem nervózní, abych jednou úpravou neudělal další chyby.

Osobně unit testy (nebo i integrační testy, myšleno testy nad databází) píšu po napsaní produkčního kódu. Již během psaní produkčního kódu si dělám poznámky, jaké možné cestičky je potřeba ověřit a podle toho potom píši testy. Testy tedy hlavně beru jako mého pomocníka (=pomocníka programátora), abych byl schopen dodat práci co v nejlepší kvalitě a byl co nejlépe připravený na budoucí úpravy a opravy. Z pohledu samotného vývoje je asi tento pohled v pořádku, ale pokud se na proces vývoje ve firmě podívám z pohledu celé firmy, tak už tam vidím nějaké mezery.

Proces vývoje většinou začíná u konzultantů, kteří tvoří zadání, kteří definují akceptační kritéria, kteří nesou zodpovědnost za to, že zákazníkovi se dodá to, co opravdu chtěl a navíc v požadované kvalitě. Od začátku jsou tedy zřejmé požadavky, které je nutné splnit a tyto požadavky by se měly co nejvíce přenést do samotného vývoje. Je tedy žádoucí, aby programátoři se během vývoje a testování zaměřili právě na tyto důležité požadavky. Často programátor testuje věci dle svého uvážení, kde on sám vidí možné slabiny, ale to je často v rozporu s tím, co musí testovat konzultant/tester.

Právě při těchto úvahách jsem hledal možné řešení, jak co nejvíce propojit obě části vývoje, jak najít společnou řeč. Nejblíže mojí představě je Acceptance test driven development a konkrétně projekt Thucydides, který celému přístupu dává jasné obrysy.

Advanced practices of test-driven development can lead to Acceptance Test-driven development (ATDD) where the criteria specified by the customer are automated into acceptance tests, which then drive the traditional unit test-driven development (UTDD) process. This process ensures the customer has an automated mechanism to decide whether the software meets their requirements. With ATDD, the development team now has a specific target to satisfy, the acceptance tests, which keeps them continuously focused on what the customer really wants from that user story.
Místo vysvětlování ATDD a Thucydides se doporučuji podívat na prezentaci pod článkem, kde je vše pěkně ukázané. Pro další informace pak ještě doporučuji článek z JavaWorldu - Acceptance test driven development for web applications.
Ještě bych zmínil knihovnu jBehave, která je představitelem přístupu zvaném Behaviour-Driven Development (BDD), který je velice podobný ATDD.

Rádi bychom šli v celém návrhu ještě dále a využili JIRU jako nástroj pro psaní a evidenci kritérií resp. stories. JIRA je pro většinu týmu centrálním bodem, kde se evidují požadavky na vývoj a je to i nástroj, který umí používat konzultanti. Tak proč neupravit JIRU i pro zadávání akceptačních kritérií v určitém formátu, ze kterých by se následně generovala kostra/šablona pro psaní testů v Groovy nebo jUnit? 

Nápadů a myšlenek je hodně, uvidíme v jaké podobě (a zda vůbec) se nám to podaří realizovat v praxi. Pokud máte někdo s uvedenými přístupy nějaké zkušenosti, budu rád když je uvedete v komentářích k článku.

27. února 2012

Vývoj JCA resource adapteru pro HttpClienta

V poslední době jsem vyvíjel JCA resource adapter a vzhledem k tomu, že není zrovna moc dostupných informací a hlavně zkušeností k dohledání, tak bych rád přidal pár zajímavých odkazů a informací.

Úkol k řešení byl celkem zajímavý - výsledná aplikace běží na Webpshere serveru, kde jsou nastaveny všechny možné pooly a vše je takto řízeno z jednoho místa (to se moc libí administrátorům). Až na jednu věc a tou jsou HTTP spojení spravované knihovnou HttpClient. Ta má vlastní implementaci ThreadSafeClientConnManager a konfiguraci na nastavení connection poolu. Cílem tedy bylo vytvořit resource adapter, který bude instalován a spravován serverem. Ve výsledné podobě vznikla vlastní implementace rozhraní ClientConnectionManager, která komunikovala s resource adaptérem přes JNDI, který spravoval a poskytoval HTTP připojení z pooleru na serveru.

Jak na to? Nejdříve uvedu odkazy na vybrané články o resource adapterech:
Představa, že budu vyvíjet resource adapter oproti ostrému serveru mě na začátku hodně frustrovala, naštěstí existují zajímavé projekty ShrinkWrap a IronJacamar, díky kterým je možné vše testovat pomocí jUnit testů. Zejména projekt IronJacamar je pro vývoj resource adapterů skoro nezbytný - součástí projektu je i command line code generator, pomocí kterého je možné si v interaktivním průvodci navolit základní parametry resource adapteru a následně vygenerovat kostru Java tříd včetně XML konfigurace a testů. Pro úplný začátek úplně super - já jsem nějaký čas s JCA bojoval sám (dokonce jsem začal číst i specifikaci JCA jak jsem byl na tom špatně :) ) a tento nástroj mi hodně pomohl.

Nakonec ještě přikládám dva UML diagramy, které lépe vystihují výslednou implementaci:

Resource adapter architektura


HttpClient architektura

26. ledna 2012

Programátoři jsou největší lháři

V nadpise dnešního článku cituji mého kamaráda, který začal pracovat jako project manager v softwarové společnosti, a který hlavně dosud většinu svého profesního života pracoval mimo jakýkoliv softwarový vývoj. Zřejmě zvyklý z jiných oborů, kde člověk na první pohled vidí, v jakém stavu je projekt, tak zde asi celkem narazil, protože dost často se během vývoje musí člověk spoléhat na to, co řeknou programátoři. A ze své zkušenosti vím, že odpověď na stav řešeného problému vždy vypadá hodně podobně - "Mám to už skoro hotové, jen musím ještě něco dodělat". Smutné je, že tato odpověď má většinou několik pokračování, kdy zní skoro stejně, jen se přidávají další přídavná jména a příslovce, aby to vypadalo, že už se konec opravdu blíží - "Myslím, že teď už budu mít skutečně většinu hotovou, jen ještě dopsat testy, ale to už je opravdu drobnost a neměl by to být žádný problém".

Je pravda, že každý project manager chce mít pocit, že má vše pod kontrolou, a že projekt postupuje podle plánu. Co ale určitě nemá rád, když dostává špatné a nepřesné informace - pak je nejistý, neví, zvláště když to není project manager, který si sám prošel vývojem. Nejhorší úplně je, když se programátor celou dobu tváří, že "žádný problém" a pár dní před koncem se zjistí, že se to nestihne.

Programátor má často mylný pocit, že bude "špatný" programátor, když řekne přesně stav věci, když snad přizná, že něco nejde podle plánu. Pokud programátor pracuje jak má a vždy říká věci jak jsou, tak se nikdy nemusí bát, že by on byl snad ten špatný. Programování je hodně o přemýšlení, o nalézání nových cestiček, o zkoušení nepoznaného, proto se prostě musí počítat s tím, že vždy vše nepůjde podle plánu. Ale je potřeba to říkát, komunikovat! Jeden kamarád hezky vyjádřil vývoj softwaru jako "interaktivní hru mezi vývojovým týmem a zákazníkem", kde komunikace a přímé jednání jsou nezbytností pro úspěch projektu.

Programátoři (zejména ti mladší) se hodně ženou po technologiích se snahou mít co nejvíce "buzzwords" ve svém životopise. Je pravda, že toto určitě zaujme, ale z pohledu vedení týmu bych často preferoval zcela základní lidské vlastnosti:

  • přímé jednání, snažím se říkat přesně jak se věci mají
  • když řeknu nějaký termín, tak udělám maximum pro jeho dosažení a pokud něco nestíhám, tak na to včas upozorním
  • komunikativnost
  • být otevřený, mít ochotu se učit novým věcem

Došel jsem k přesvědčení, že si mě firmy najímají kvůli tomu, že jim dokážu pomoci (což neznamená, že to musím vždy dělat já sám). Firmy jsou ochotny nadstandardně zaplatit, pokud mají problém a vy jim dokážete pomoci, ale vždy za předpokladu, že "co řeknete, tak to platí". Firma má často problémy se svými zaměstnanci a nemá vůbec potřebu využívat externistu, který jí nepřináší maximální užitek.

23. ledna 2012

Vybrat JasperReports nebo BIRT reports?

Potřebuji se rozhodnout, jaké řešení na reporty vybrat a pořád nevím. Nějaké porovnání těchto nástrojů jsem již uváděl na mém blogu, ale již je to skoro tři roky zpátky a od té doby se mnoho věcí určitě změnilo.

Pořád si myslím, že volba je mezi JasperReports a BIRT reports. Našel jsem další možnosti jako Pentaho Reporting, Crystal Reports nebo NextReports, ale žádné z těchto řešení mě moc nezaujalo.

Já osobně žádné pokročilé funkce od nástroje neočekávám, spíše ty základní:

  • reporty budou primárně zobrazeny na webové stránce
  • export do PDF, XLS je nutností
  • absolutní většina reportů bude statických, tedy uživatel klikne na odkaz a zobrazí se mu určitý report. Žádná velká interakce uživatele při zobrazování reportu nebude.
Můj favorit je JasperReports, ale asi jen díky nějakým subjektivním důvodům:
  • JaspeReports je tu už dlouho a již od nějaké 1.x verze Springu je součástí standardní podpory. Takže Spring nabízí podporu na podobné úrovni jako jiné prezentační frameworky jako Freemarker, Velocity atd.
  • velká komunita a rozsáhlá dokumentace (z uvedených nástrojů nejlepší)
  • myšlenka kolem JasperReports Serveru mi přijde zajímavá a bez většího úsilí nabízí velkou přidanou hodnotu
Moc pěkné srovnání je v článku BIRT, Jasper, Pentaho - Comparison Matrix nebo v článcích JasperReports, případně BIRT Vs Jasper Report A Comparitive Study.

Jaké máte prosím zkušenosti vy?