Konečně máme svůj produkt ...

Je to už pár let (doslovně), co jsem zde psal naposledy, ale teď mě to nedá, abych se nepodělil o své pocity.

Začnu tím, co se nám povedlo – vytvořili jsme open source integrační framework vycházející z populárního řešení Apache Camel, jmenuje se OpenHub framework a vypouštíme ho do světa. Proč další ESB? Protože OpenHub framework je open source řešení, které přitom obsahuje „enterprise“ funkce, které jsou normálně dostupné pouze ve drahých řešeních od velkých firem nebo v placených verzích konkurenčních produktů.

Pokud vás zaujal OpenHub framework, pak se prosím podívejte na následující odkazy:

-       Web: www.openhub.cz

-       GitHub: https://github.com/OpenWiseSolutions/openhub-framework

-       Doc: https://openhubframework.atlassian.net

Já zde ale nechci psát o našem řešení, já se chci podělit o důvodech našeho počínání, co vše jsme museli po cestě řešit, co se nám povedlo, ale také nepovedlo ...

Integrační projekty jsem začal řešit někdy v roce 2014, mají svoje specifika, není to stejné jako vyvíjet „normální“ aplikace s GUI. Hned na prvním projektu se sešla super skupinka lidí, se kterou jsme po letech založili firmu OpenWise Solutions. Od začátku naším cílem bylo „vytvořit produkt, na který budeme hrdý“ (pro začátek aspoň nějaký produkt ...). Aspoň u mě osobně to vycházelo z toho, že přes deset let jsem dělal na projektech pro různé zákazníky a už mě trochu začalo vadit, jak je každý projekt „jednorázový“, jak skoro vždy je málo času udělat věci pořádně nebo jak musím spolupracovat s lidmi, se kterými ani nechci spolupracovat. Produktový vývoj (aspoň v mé představě) má vyšší cíle – vymyslet resp. vytvořit kvalitní aplikaci/řešení, které opakovaně bude moci někdo další používat a v ideálním případě za to ještě zaplatí. A přitom dělat s lidmi, se kterými člověk chce dělat, hrát si s kódem podle svých měřítek kvality atd. 

Postupně jak jsme dělali integrační projekty, tak se nám různé věci začali na projektech opakovat, a proto přišlo logické rozhodnutí, abychom tyto věci dali někam bokem, do vlastní knihovny, kterou budeme postupně rozšiřovat. Snahou bylo začít nový integrační projekt tam, kde jsme ten předchozí skončili, nemuseli zdlouhavě vše znovu nastavovat a připravovat. Tak vznikl zárodek OpenHub frameworku – nejdřívě interní knihovna, poté interní projekt, veřejný open source projekt a nyní produkt k veřejnému použití.

Asi nejzajímavější zkušenost máme s tím, jak „jednoduché“ je produkt dotáhnout po technické stránce ve srovnání s tím jak to dotáhnout úplně celé, tj. připravit nějakou obchodní strategii, vytvořit obchodní web, dokumentaci vyladit apod. Když člověk něco programuje, tak ví přesně co je nutné udělat, aby se dostal k cíli, ale při plánování obchodní strategie je sice možné se opřít o řadu analýz a dat, ale pořád je tam tak velká míra nejistoty, že jsem sám ve velkém očekávání jak to bude dále pokračovat.

Dotažení samotného (technického) produktu do finálního stavu je kapitola sama pro sebe. Člověk zvyklý na projektové zakázky je často překvapený co vše a do jaké míry detailu musí řešit. Nestačí pouze, že něco má fungovat dle požadavků zákazníka, ale musí to fungovat prostě pro všechny možné požadavky, které člověk ani nezná – správně navrhnout architekturu celého řešení, vydefinovat API s citem proto, aby bylo dostatečně flexibilní pro možné realizace, ale zase dostatečně omezující z pohledu interní implementace a dalšího rozvoje API nebo dotáhnout a vyladit dokumentaci, která nebude jen popisem funkčnosti, ale bude nabízet i pohled pro člověka, který řešení moc nezná a chce ho začít používat. Testování a kvalita kódu je při vývoji produktu něco tak samozřejmého, že o tom netřeba snad ani psát. Často to je jediná možnost jak si sám ověřit, že něco funguje před tím, než to někdo začně reálně používat na projektu. 

Jak to tak bývá, tak jsme si na začátku dali do fronty spoustu nové funkčnosti do nové verze, kterou jsme nakonec museli škrtat, protože bychom takto žádnou verzi nikdy nevydali. Rozhodnutí o nové verzi padlo někdy v listopadu s cílem do konce března mít vývoj ukončený a jen ladit. Nicméně ještě v červenci jsme vyvíjeli, ladili a některé funkčnosti přesouvali do další (minor) verze. Už nám bylo jasné, že musíme být na sebe přísní, dělat jen opravdu ty nutné věci, které vedou k dokončení verze, nic jiného. Také jsme ke konci změnili strategii tím, že jsme vydali nejdříve beta verzi, protože jsme si uvědomili, že těch změn je tam opravdu hodně a bude chvíli žádoucí, aby si to sedlo, abychom dostali zpětnou vazbu od ostatních z reálných projektů. I když máme stále hodně práce před sebou, tak úleva z vydané verze byla opravdu znát.

Vývoj probíhal (většinou) po večerech v pěti lidech. To mělo jednu velkou výhodu i nevýhodu – výhodou bylo to, že nás to muselo bavit, protože jsme to dělali převážně ve svém volném čase. A to myslím, že je u těch nových věcí vidět, že každý se to snažil dělat dle svého nejlepšího přesvědčení, že jsme měli čas věci rozmýšlet, fungovalo vzájemné review návrhů i kódu, prostě žádný stress z termínu. Nevýhodou bylo, že už to bylo dlouhé a časem se nám po večerech už moc dělat nechtělo – dostavila se únava a nechuť. To jsme částěčně řešili tím, že někdo začal vyvíjet OpenHub během své denní pracovní náplně, někdo si dal přestávku a pak se do toho zase pustil.

Je to pár dní, co jsme spustili produktový web www.openhub.cz, odreleasovali beta verzi a jsme zvědaví jak se to bude vyvíjet dál. Rádi bychom, aby to někdo další začal používat, v lepším případě nám pomohl s vývojem a úplně v ideálním případě, aby si od nás někdo koupil support nebo vývojový balíček. Nicméně i bez toho, že bychom na tom začali vydělávat velké peníze, tak to pro nás má řadu výhod – otevírá nám to cestu k novým projektům, protože je to celkem velká konkurenční výhoda, když můžete říci, že používáte vlastní integrační řešení (navíc open source, rozšířitelné, žadný vendor lock-in, žadné licenční poplatky, s možností využití všech nástrojů, které běhají s Apache Camel atd.), které dle potřeb umíte rozšířit a rychle zafixovat v případě chyby. Navíc nikdo nebude efektivněji vývíjet než vy sám, když znáte každý šroubek celého řešení ...

Podařilo se nám dotáhnout jednu věc až do cíle a máme spoustu nových zkušeností a znalostí. A to se počítá! :)

Agilní vývoj a svoboda v práci

Jednoznačně souhlasím s agilním (přesněji řečeno lean) způsobem vývoje. Čím kratší kolečko zadání - vývoj - testování - nasazení - zákazník jsme schopni zrealizovat, tím lépe. Po 12 letech od agilního manifestu se agilní způsob vývoje začíná rozmáhat i v našich končinách - přesněji řečeno se o tom hodně píše, ale pochybuji, že realita je opravdu taková. Spíše bych řekl, že většina aplikuje iterační způsob vývoje, ale to je většinou vše - složení týmů a jejich fungování, tvorba zadání, zatažení zákazníka do vývoje zůstávají stále stejné jako když byl vodopádový model. Nejsem zastáncem toho, že vždy musí být 100% agilní přístup, ale je dobré si říci, jaká je realita a neplácat se často neprávem po zádech, že konečně máme agilní vývoj.

S rozmachem agilního způsobu vývoje (a zejména SCRUMu) často přemýšlím z pohledu vedení týmů, co je pro tým a pro mě lepší - zda 1) co největší (fyzická) sounáležitost k týmu, časté osobní setkávání, společná kancelář, kde to prostě "žije", kde informace "lítají" a nebo 2) dát přednost schopnostem jedinců, svobodě v práci, důvěře.

Pokud bych to měl brát čistě z mého osobního pohledu, tak já určitě upřednostňuji svobodu v práci - pracovat kdy a kde chci. Samozřejmě to nelze brát absolutně, ale čím větší svobodu v tomto ohledu mám, tím více se cítím spokojený.

Na druhé straně je tým, který často vedu. Úspěch projektu jednoznačně závisí na úspěchu celého týmu, takže pokud je to nutné, tak moje svoboda musí jít stranou (bohužel). Myslím si ale, že pokud si tým zvykne na vaši každodenní přítomnost a možnost zatahovat ptát se vás na cokoliv a kdykoliv, tak to není moc dobře - upřednostňuji důvěru v lidi a tým, v jejich schopnosti. Je potřeba se potkávat, komunikovat, sdílet informace, ale přesto si udržovat svobodný přístup k práci.

Strávil jsem tento týden v jedné nejmenované Slovenské bance (nemyslím si, že jiné banky jsou na tom výrazně jinak) a často jsem byl součástí projektového přístupu, který je mi absolutně nesympatický - ke každému dílčímu problému je nutné vyjádření spousty lidí, časté status meetingy, kde se neptají na nic jiného, než co teď zrovna člověk dělá a co bude dělat potom, neschopnost jednotlivce cokoliv rozhodnout, natož změnit. Přítomnost v práci od-do je pro většinu lidí nutností.

Mám rád vývoj, ale pokud bych začal být omezený ve své pracovní svobodě, tak bych vývoj už tak rád neměl :)

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.

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.

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. 

Profesionální programátor = nedostatkové zboží from Petr Juza

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?

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.

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?

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.

Completing the circle - Automated web tests as a team communication tool

View more presentations from Wakaleo Consulting

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.

Znáte SPL (Software Product Line)?

SPL je zkratka pro Software Product Line. Jedná se o styl vývoje podobný tomu, jak se vyrábí mobily nebo auta. Není to tedy vhodné pro jednorázové projekty, ale spíše pro produkty - firma má představu, jaký produkt nabízet na trhu, navrhne možné varianty a ty se pak snaží nabízet zákazníkům.

Je to opravdu hodně podobné výrobě aut. Výrobci znají segment cílových zákazníků, ví, že to například směřujeme na střední vrstvu, která si ráda připlatí za navigaci, tempomat, xenony, automatickou převodovku atd. Je tedy nutné navrhnout takový výrobní proces resp. architekturu auta, aby toto všechno šlo zákazníkovi dodat, ale klidně s určitými omezeními, např. pokud tempomat, tak ano, ale pouze s aut. převodovkou. I u aut může chtít někdo něco opravdu speciálního, co v nabídce automobilky není - pak osloví třeba nějaký specializovaný servis, který mu upraví motor dle jeho přání. To už ale je něco opravdu specifického a zákazník musí počítat s tím, že si to také pořádně zaplatí.
Automobilka nevidělá tím, že prodá jedno, dvě auta, ale třeba až tisíc, kdy se ty náklady na vývoj a implementaci vrátí.

Zpět k SPL. My nenavrhujeme auto, ale produkt, o kterým si myslíme, že ho máme komu nabídnout a nabídku opakovat. Musíme vědět možné variace a závislosti mezi nimi, tak abychom nenabízeli jeden uzavřený produkt, ale aby si zákazník mohl vybrat - chcete Oracle nebo MS SQL? Chcete zabezpečení přes HTTP, NTLM nebo OpenID? Chcete systém nasadit na vlastní server nebo na náš server nebo do cloudu? Naopak není třeba nutné, aby zákazník měl mít možnost vybrat jaký DMS systém chce - u auta si také nemůžete vybrat z více podvozků.

Asi nejvíce se mi ze SPL líbí přístup k vytváření interních megalomanských frameworků - budu citovat "Rather than put general software components into a library in the hope that opportunities for reuse will arise, software product lines only call for software artifacts to be created when reuse is predicted in one or more products in a well defined product line."

Pokud si o tom chcete přečíst více, pak doporučuji následující zdroje:

• Introduction to the Emerging Practice of Software Product Line Development
  
• A Framework for Software Product Line Practice
  

Přenositelnost zkušeností

Konečně jsem si opět našel chvilku a píši na můj blog. Poslední měsíce jsem byl extrémně vytížený, protože se mi stalo, že se mi sešlo několik termínů dokončení projektů a já nevěděl co mám dělat dříve. Samozřejmě jsem to takto vůbec neplánoval, bylo to způsobené standardně tím, jak se všechny projekty protahovaly až se to vše potkalo v jeden termín.

Práci na volné noze mám natolik rád, že to považuji za jednu velkou výhodu, nicméně zde se ukazuje jedna malá nevýhoda - nedokážu říci svým stálým a dlouhodobým zákazníkům NE, protože se bojím o ztrátu zákazníka. A proto se mi to pak někdy takto vyboulí. Sám ale cítím, že je to takto špatně, protože pokud je někdy hodně práce a nevíte co dříve, pak zákonitě musí trpět kvalita, i když si to člověk nepřipouští.

Dnes ale chci psát o něčem jiném - v poslední době stále více dostávám prostor v různých firmách radit s optimálním nastavením vývojového procesu. Musím se přiznat, že mě někdy překvapuje, jak některé zavedené firmy, které jsou maximálně profesionální ke svým zákazníkům, se snaží odpovědět na základní otázky týkající se interního procesu vývoje.

Často jsem se v této souvislosti zamýšlel, jak nejlépe v této oblasti předávat moje zkušenosti nabité z působení v řade firem, vždy by se dalo říci s unikátními a vlastními postupy vývoje aplikací. Pokud někomu předáváte ryze technické informace a zkušenosti, tak to každý většinou vezme a ani nepřemýšlí o tom, že by to mohlo být jinak. U předávání ryze praktických zkušeností to takto nefunguje a mám prostě pocit, když to trochu přeženu, že pokud si na to každý nepřijde sám, tak tomu neuvěří. Jen je potřeba správně určit mantinely, aby člověk znovu neobjevoval kolo.

Celkem se mi zdá rozumné, když si firma na tyto konzultace a rady najímá někoho externího, protože jeho slovo má "větší" váhu, není zasažen interními vztahy, historií firmy a má celkový nadhled nad celým procesem.

Snad v každé firmě, ve které jsem byl, tak byl specifický proces vývoje, nějak specificky upravená metodika. Jsou určitě rozdílné nároky na vývoj jednorázových aplikací nebo produktů, ale proč to musí být všude jinak, když existuje opravdu jen několik rozumných metodik, které má cenu zvažovat a nasadit?

Je také zajímavé vidět, kdo v jaké firmě je ten "nejdůležitější" - jednou to jsou obchodníci, podruhé konzultanti a někdy dokonce vývojáři jsou ti, kteří mají největší hlas v tom, jak se co bude dělat. Myslím, že toto je většinou dáno tím, jak firma vznikala - pokud firma začínala s několika programátory, tak i nyní, když má přes sto lidí, má vývoj největší slovo.

Přijímací pohovory jsou vizitkou firmy

Z povahy mého stylu práce se často účastním různých přijímacích pohovorů či výběrových řízení. Přijde mi, že mnoho firem si neuvědomuje, že i takový přijímací pohovor je vizitkou resp. reklamou dané firmy. Přeci to není jen o tom, že někdo hledá nějakou práci, ale i o tom, že nějaká firma chce najít toho nejlepšího spolupracovníka.

Hlavním důvodem k napsání tohoto příspěvku je časté překvapení z průběhu náboru nových spolupracovníků. Překvapuje mě toho více:

• o smyslu vstupních testů zde nechci polemizovat, ale spíše nejsem jejich zastánce, protože si myslím, že mají malou vypovídající hodnotu. Teď neřeším, zda se mi to libí nebo nelíbí z pozice uchazeče, ale někdy i stojím na druhé straně barikády a mám možnost si vybírat spolupracovníky či rozhodovat o přijetí nových zaměstnanců.
  
  
• pokud tedy vstupní testy ano, pak bych očekával, že budou nějak relevantní k mým odborným zkušenostem a k práci pro firmu. Co si mám myslet o otázkách typu "K čemu jsou dobré anotace?", "Kdy je vhodné použít databázový trigger?", "Porovnání rozhraní a tříd z pohledu dědičnosti" nebo otázky na Swing, když mě firma žádá o spolupráci na webovém projektu? Nikdy jsem takové testy neodmítl, vždy to beru jako takovou výzvu, ale ještě jsem se pro žádnou takovou firmu nerozhodl.
  
  
• čekání na pohovor, odbíhání od pohovoru, vyřizování telefonátů apod. jsou věci, které mi vadí při jakémkoliv jednání a zde dvojnásob.
  
  
• role pracovních agentur je pro mě často velmi záhadná, ale je víceméně jasné, že je jim jde jen o peníze. Z mého pohledu žadatele o práci jsem ještě nepřišel na žádnou výhodu, kterou mi agentury poskytují - ozvou se vždy jen tehdy, když něco potřebují, když mě chtějí poslat na nějaký pohovor, ale když já občas něco potřebuji nebo hledám, tak většinou bez výrazného zájmu. Také mi vadí, že je v agenturách velmi velká fluktuace lidí. Pak mi každý půlrok volá někdo jiný, neexistuje žádné osobnější pouto.
  

Naštěstí převládají příjemné pohovory, kdy se cítím spíše jako možný budoucí partner než někdo, kdo žádá o práci. Nejednou se mi stalo, že jsme přeskočili technickou část pohovoru z důvodu přečtení mého blogu - to pak jsem vždy velmi potěšen.

Většina věcí je o lidech samotných, takže těžko soudit celou firmu podle pár lidí, se kterými se člověk potká, ale na druhou stranu také vím, že "špatní" mají tendenci spolupracovat se "špatnýma" a "dobří" s "dobrýma".

Ještě přidávám odkaz na dva pěkné články k tématu - Getting Hired, první a druhý díl.

Bude Oracle pro Javu přínosem? - výsledky

I'm back :-). Mám za sebou na dovolené a práci bohaté léto, takže jsem neměl moc času na psaní. Také se ale musím přiznat, že na mě padla tak trochu "autorská krize", a že jsem rád, že jsem za těch pár měsíců mohl nabrat novou energii a nová témata. I když práce na podzim bude hodně, tak i přesto bych rád sem tam něco napsal ...


Před pár měsíci skončila poslední anketa na tomto blogu s těmito výsledky (celkem hlasovalo 59 lidí):

1. Ne (37%)
   
2. Ano (30%)
   
3. Nevím (20%)
   
4. Nic se nezmění (11%)

Já osobně jsem hlasovalo pro "Ne" a myslím, že události v posledních měsících tomu jednoznačně napovídají. Oracle byla, je a bude firma primárně zaměřená na peníze. To je asi většina firem, jinak by bylo asi něco špatně, ale u jiných firem to není tak okaté, není to tak na první pohled vidět. Co jiného si mám myslet o žalobách na Android? Co si mám myslet o posledním vývoji JDK a Javy samotné? (pozn. do teď si pamatuji, jak se Sun dušoval po vydání Javy 5, že nyní budou každé dva roky nová verze JDK ...)

Je pravda, že se na celou věc koukám z pohledu normálního programátora, kterého asi nejvíce zajímá samotná Java a co s ní bude do budoucna. Kdybych se na to koukal jako nějaký manažer nebo obchodník, tak bych to asi viděl zase jinak. A nebo prostě má Oracle špatný marketing a pověst ve srovnání s ostatními podobnými hráči.

Na druhou stranu se musím přiznat, že od samotné Javy už toho moc neočekávám. Dnes samotná Java nic není. Javovská platforma je dnes takový ekosystém všech možných knihoven, frameworků a dynamických jazyků, které mají to společné, že mohou běžet v JVM. Proto nemá cenu do jazyka Java přebírat všechny možné vychytávky z jiných jazyků, ale spíše se snažit o udržení přehlednosti a jednoduchosti jazyka. Když se podívám na seznam plánovaných vlastností, tak já osobně bych nejvíce uvítal nativní podporu modularizace přímo na úrovni JVM a integraci knihovny JODA pro lepší práci s datumem a časem. Některé zbylé věci mi přijdou jako "nice to have" (např. strings in switch, Automatic resource management, The fork/join framework), ale jiné bych prostě do Javy už nedával (např. closures, Diamond operator, Annotations in more places).

Jsem toho názoru, že Java jako jazyk má nejlepší léta za sebou a nemá nyní cenu se snažit dohánět ostatní nové moderní jazyky. Já programuji v Javě skoro deset let a vždy jsem nejvíce oceňoval jednoduchost, přehlednost a stabilitu jazyka, širokou komunitu, velké množství informací a možnost volby a výběru a nikdy jsem si moc nestěžoval, že by se mi něco psalo nějak špatně, že by se to mohlo psát lépe.

Co ale vidím pozitivně je to, že Java tu bude ještě hodně dlouho, protože Oracle je na Javě výsostně závislý, a proto se nebojím toho, že by během pár let padla v zapomnění. Takže ještě pár let budu programovat a pak už snad budu rentiér :-).

Programátorské konvence

Při procházení cizího kódu určitě každý ocení, když kód vypadá tak, jako kdybychom ho psali sami - stejné formátování kódu, stejná jmenná konvence pro pojmenování tříd a metod, stejná adresářová struktura projektu apod.

Proto jsem často překvapen, že na tyto "pravidla" se neklade potřebný důraz, i s ohledem na to, že údržba aplikace je mnohdy náročnější (časově, nákladově) než samotná realizace. Když už jsem někde pravidla viděl, tak mě zase překvapilo, jak jsou mnohdy složitá.

Pro mě je hlavním dokumentem "Code Conventions for the JavaTM Programming Language", který popisuje základní formátovací a syntaktická pravidla pro programování v jazyce Java. Nevidím tedy žádný důvod, proč vytvářet vlastní (nová) pravidla. Je určitě možné některé detaily změnit nebo upřesnit (např. délka řádky, kódování souborů, hlavičky tříd a metod, ...), ale nemá smysl měnit základní myšlenky dokumentu.

Kromě tohoto dokumentu považuji za programátorské konvence i další dokumenty jako např.:

• Adresářová struktura projektů
  
• Best practices - popis často řešených problémů
  
• Názvosloví objektů a vzorů
  
• Standardní architektura
  

Při návrhu těchto konvencí je potřeba myslet na to, že není snahou vytvořit 100 stránkový podrobný manuál, ale vytvořit nějaké rozumné mantinely a pravidla pro vývoj aplikace, které budou všem srozumitelná. Je na každém, jaké oblasti bude chtít pokrýt nějakými pravidly.

Já osobně vidím třeba velký přínos v tom, pokud názvy tříd a metod splňují nějaká pravidla, např. že metoda, která hledá data začíná find nebo že názvy perzistentních tříd končí na DAO. Pak mohu mnohem jednodušeji z jednoho místa nastavit transakce nebo zabezpečení aplikace.

Výhody spolupráce s externisty

Rád bych dnešním příspěvkem navázal na předcházející článek, kde jsem psal o tom, jaké je to pracovat na volné noze. Dnes bych rád navázal a podívám se na výhody, které firmy mohou získat z najímání vývojářů na kontrakt, tzv. body-shopping.

(Pozn.: jen pro upřesnění - práci formou kontraktu si představuji tak, že veškeré náklady spojené s výkonem mé práce jsou čistě mojí záležitostí, neočekávám žádné zaměstnanecké výhody, pouze domluvenou finanční odměnu. Tedy žádný Švarc systém).

• flexibilní zdroje - vždycky se nedá vše naplánovat a ovlivnit na 100%, často se objevují nové požadavky během vývoje, ale termín zůstává, analýza se opozdila, je nutné řešit více projektů najednou atd. Podobné situace asi všichni dobře znáte, a proto může být výhodné pro firmy mít "někoho" v záloze, kdo může v těchto situacích pomoci. Pokud si navíc firma může vybrat lidi s přesně danými znalostmi a zkušenostmi, tak pak je to opravdu velká výhoda. Určitě nejčastější důvod využívání externích vývojářů.
  
  
• flexibilní náklady - pokud nemusím někoho vést jako zaměstnance, nemusím vést jeho mzdy, vydávat mu stravenky a řešit jeho zaměstnanecké výhody, nemusím mu dávat počítač, mobil, auto, tak budu schopen ušetřit nemalé náklady a hlavně to bude pro mě znamenat velkou flexibilitu z pohledů nákladů firmy - skončí projekt, skončí potřeba.
  
  
• získání know-how - lidi na volné noze mají často hodně co nabídnout, protože vidí jak to funguje v jiných firmách, pracovali na více projektech než standardní zaměstnanci a mohou tedy vnést do firmy nové myšlenky a znalosti. Bohužel tento přínos je hodně často opomíjen a zbytečně ze strany firem nevyužíván.
  
  
• dobře fungující firma - čím lépe bude mít firma nastaveny interní procesy vývoje (konvence psaní kódu, kvalitní analýza, odpovědnosti členů týmu, komunikace v týmu, ...), tím lépe dokáže využít externích spolupracovníků. Pro firmu to tedy může být hodnotná zpětná vazba, zda ve firmě vše funguje jak má.
  
  
• přidaná hodnota - není nutné mít vlastní vývojový tým složený ze všech profesí od analytika, přes architekta až po testera. Často může být pro firmy zajímavé držet know-know projektu a na dílčí "akce" si najímat externisty. Firma se bude soustředit na věci s největší přidanou hodnotou a ostatní potřebné profese si bude najímat.
  

Doplnili by jste ještě nějaké další výhody?

Samozřejmě, že vše může mít i své nevýhody (fluktuace lidí, problém s údržbou a opravou chyb na projektech, držení know-how, kvalita znalostí externistů, ...), ale myslím si, že vhodnou firemní strategií pro spolupráci s externisty lze mnohem více získat než ztratit.

Jaké je to pracovat na volné noze?

Často se mě kamarádi a kolegové ptají, jaké to vlastně je být na volné noze, jaké výhody či nevýhody mi to přináší. Tímto článkem bych rád zrekapituloval moje zkušenosti, které jsem za dobu jednoho a půl roku získal.

• Vždy jsem se hodně snažil učit nové věci, četl články, zkoušel nové knihovny. Ale bylo to takové "umělé". Nyní jsem za relativně krátkou dobu získal spoustu praktických zkušeností, které bych normálně získával mnohem déle. Nemyslím teď jen technické znalosti (různé projekty, různé přístupy k řešení problémů, nové knihovny, atd.), ale zejména jsem měl možnost nahlédnout do mnoha různorodých firem, vidět různé styly komunikace a řízení, různé přístupy k vývoji, přemýšlet o tom, co kde funguje a nefunguje atd. Připadám si jak houba, která se v každé nové firmě pořádně nasákne.
  
  
• Práce na volné noze mě drží v neustálé pohotovosti. Musel jsem si zvyknout na to, že nic není jisté, a že jediný důvod, proč si mě někdo bude chtít najmout bude ten, že budu "dobrý", že budu nabízet něco více než ostatní - znalosti, zkušenosti, profesionální přístup. To mě pořád nutí přemýšlet o sobě, o mých znalostech a to mě tedy žene dopředu. Samozřejmě to je zároveň i nevýhoda, protože vždy není jednoduché se prosadit a není vždy jednoduché přijít do nové firmy a začínat od začátku.
  
  
• Vždy jsem byl placen od hodiny a je to tedy jen o vzájemné důvěře, že opravdu odpracuji uvedený počet hodin, který na konci měsíce vykážu, a který chci zaplatit. Jako zaměstnanec jsem takový tlak nikdy necítil, ale teď si prostě nemohu dovolit číst hodinu články na internetu a pak to vykázat jako nějakou práci. Samozřejmě člověk není robot a někdy se mi pracovat nechce nebo to prostě ani moc nejde - pak to ale musím zohlednit ve výkazu, bohužel.
  
  
• Jsem sám a nikam vlastně nepatřím. Musím tedy zapomenout na jakékoliv zaměstnanecké výhody - tím nemyslím jen stravenky, připojištění, služební auto, atd., ale i to, že se mě netýkají školení, výuka angličtiny, společné výjezdní zasedání apod. To cítím asi jako největší nevýhodu, někdy jsem prostě sám. Na druhou stranu jsem oproštěn od interních dohadování a problémů, což je zase mnohdy výhoda.
  
  
• Jsem sám svým pánem, ale stejně vždy šéfa mám. Spíše se tedy cítím volněji, ale i tak musím plnit termíny, pořád mi někdo zadává práci a pak ji kontroluje, takže v tomto změna není. Mohu si ale vybrat počítač, mobil, auto jaký chci aniž bych porušoval firemní předpisy a jsem větším pánem svého času. Také se dívám na věci více z nadhledu, protože vím, že nikde nebudu napořád.
  
  
• Člověk pozná spoustu nových kolegů, známých, což je určitě také příjemná výhoda.

Svého rozhodnutí přejít na volnou nohu jsem nikdy nelitoval a jsem za něj moc rád. Pokud to jen půjde, tak v nejbližších letech bych rád neměnil.

A jaké jsou vaše zkušenosti? Zkoušeli jste pracovat na volné noze? Myslíte, že pro firmy i do budoucna bude zajímavé si najímat lidi na kontrakt?

Programátoři vs. kodeři

Při své práci na volné noze jsem již pár firem navštívil a všude mi to přijde stejné - část vývojářů jsou programátoři a část kodeři.

Programátor

Schopnost myslet - asi to zní úsměvně, ale toto je největší schopnost (a tedy rozdíl oproti koderovi) programátora. O své práci přemýšlí, přemýšlí, zda to co dělá dává smysl, zda zadání, které dostal neobsahuje nějaké nesmysly, nesrovnalosti. Programátorovi jde také často o "dobrý pocit" z práce - nejde vždy jen o to udělat nějaký úkol co nejrychleji, něco narychlo zbastlit, ale dělat věci tak, aby s nimi byl člověk sám spokojený.
Programátor bude obecně asi také více nespokojený člověk, protože mu záleží na tom, aby dělal v "prostředí", které dává smysl, které ho někam posouvá dále.

Kodér

Kodéra ze všeho nejvíce zajímá zdrojový kód - rád kód vytváří, ale nebaví ho si vymýšlet zadání, přemýšlet nad ním, diskutovat o něm. Ideálně dostane zadání, které obsahuje úplně vše - od informace, jaké metody má udělat a kam je umístit, přes informaci, že je nutné přidat tlačítko "Odeslat" k formuláři (toto je realita, jeden kolega udělal webový formulář bez tlačítek na odeslání). Díky velké orientaci na samotný kód dokáží psát velice efektivně a kvalitně.


To, zda je vývojář programátorem nebo kodérem nesouvisí ani tak s tím, jak kdo je dobrý v Javě, jak moc zná různé knihovny, frameworky, ale asi spíše s tím, jaký má přístup k práci, co ho baví více. Někdo je od přírody přemýšlivý, zkoumavý, zodpovědný, pečlivý, ...

Z pohledu sestavení vývojového týmu je zřejmé, že každý tým potřebuje oba dva typy vývojářů - někoho, kdo bude udávat směr a přemýšlet o aplikaci a někdo, kdo bude dělat (kvalitní) kód. Jen je otázka v jakém poměru to namíchat - má zkušenost je zatím taková, že poměr programátorů vs. koderů je přibližně 1:2.

Srozumitelnost zdrojového kódu

K dnešnímu psaní mě inspirovat článek s názvem "Four harmful Java idioms, and how to fix them" na serveru JavaWorld. Nedalo mi to, abych k tomu nenapsat něco svého.

Pro ty, kdo to nechtějí číst celé mám zde krátké resumé. Autor článku navrhuje čtyři následující řešení (lépe řečeno reaguje na čtyři celkem rozšířené idiomy) pro lepší čitelnost zdrojového kódu resp. pro jeho lepší použitelnost, pochopení, údržbu:

1. Konvence pro rozlišení lokálních proměnných, argumentů metod a proměnných tříd. Autor navrhuje použít a jako prefix pro argumenty metod, f pro proměnné třídy a lokální proměnné nechat bez prefixu.
   
   
2. Sdružovat třídy do balíků podle funkcionality a ne podle vrstev. Hlavní myšlenkou je co nejvíce využít zapouzdřenosti jednotlivých balíků (packages) tak, aby balíky sdružovali všechny třídy (entitu, DAO, kontroller, atd.) pro jednu funkcionalitu. Oproti tomu staví běžný přístup, kdy balíky jsou členěny dle vrstev, tj. balík pro všechny entity, pro všechny DAO objekty atd.
   
   
3. Využívat neměnitelné (immutable) objekty jak je to jen možné. Autor uvádí rozpor v tom, že dnes je všechno JavaBean, což je pravý opak.
   
   
4. Proměnné a metody třídy řadit od nejvíce obecných k nejvíce detailním. Na místo klasického začátku s definicí proměnných začít uvedením veřejných metod, poté soukromé metody a až na konec uvést proměnné.
   

Tak to máme za sebou krátké resumé a teď konečně má reakce k jednotlivým bodům:

1. Toto se mi zdá celkem přínosné, i když mě trochu odrazuje moje zkušenost s "Maďarskou konvencí" z časů, kdy jsem ještě programoval v C++. Hodně lidí bude argumentovat tím, že v IDE to každý hned pozná, ale ne vždy mohu IDE používat.
   
   
2. K tomuto bodu mám asi největší výhrady. Sice čitelnost super (mám vše na jednom místě, nemusím skákat mezi balíkama), ale to je tak asi všechno. Další velký argument zapouzdřenost má určitě něco do sebe, ale nevidím v tom takový problém. Já se spíše snažím o zapouzdřenost na úrovni modulů, tj. několika balíků, uvnitř modulů mi to tolik nevadí. A nakonec v přístupu "package-by-feature" vidím nevýhodu při používání AOP - když mám strukturu "package-by-layer" tak mohu pěkně využívat AOP přes různé vrstvy, protože mi tomu odpovídá struktura balíků. Také se mi bude určitě lépe "řezat" aplikace, když budu potřebovat škálovat.
   
   
3. K tomuto není co dodat, výhody jsou zřejmé. Spíše je obecný problém v tom, že JavaBeany jsou natolik rozšířené, až je to problém. Každý "nepřemýšlející" programátor sází jeden JavaBean za druhým. Polehčující okolností může být to, že často používané knihovny, např. JSF, ORM knihovny, Spring MVC ho k tomu víceméně tlačí.
   
   
4. Autor argumentuje tím, jak člověk efektivně řeší problémy - nejdříve ho zajímají vysokoúrovňové věci a postupně jde do detailů. Zajímavé, nikdy jsem o tom takto nepřemýšlel. Zde mě ale hlavně zarazilo to, že je to vlastně v rozporu s Java konvencí od Sunu. K tomu prý Joshua Bloch říká: "I wouldn't take that document [Sun's Coding Conventions] too seriously. It is not actively maintained or used at Sun.". Co dodat :).
   

A jaký styl programování máte vy? Používáte třeba některý z těchto přístupů?

Komentovat? Určitě ano.

Opět jsem se setkal s názorem, že komentovat zdrojové kódy není potřeba, že kód sám o sobě je dokumentace. K tomu můžu říci jen jedno - to je naprostá blbost.

Stačí nepracovat s vlastním kódem několik týdnů a už člověk ztrácí přehled o jemných detailech algoritmů, které sám psal. Nemluvě pak o tom, když je potřeba opravit chybu v rok staré aplikaci a nebo pracovat v kódu svých kolegů.

Také jsem slyšel "Jsem orientovaný na výkon a psaní komentářů mě brzdí". To je hodně krátkozraké, protože možná je člověk o pár minut rychlejší, když implementuje algoritmus, ale z dlouhodobějšího pohledu je to samozřejmě krátkozraké - čas strávený nad zjišťováním, jak jsem to já nebo můj kolega vlastně tehdy mysleli, je mnohem větší než kolik se dá ušetřit na jednom algoritmu bez komentářů. Ale já bych se vůbec do těchto polemik nepouštěl, protože dle mého názoru zdrojový kód se automaticky rovná kód plus komentáře.

Při psaní komentářů je potřeba nezapomínat, že zdrojové kódy nejsou Java soubory, ale také třeba konfigurační soubory, soubory prezentační vrstvy atd. To jsou také zdrojáky a ty je potřeba také komentovat.

Opačný extrém je takový, že na jeden řádek kódu připadají dva řádky komentáře. Není potřeba komentovat to, co je zřejmé z vlastního kódu. Zdrojový kód je jako dobrodružná knížka, kde jazyk Java popisuje vlastní děj příběhu. Komentáře jsou pak dějová vysvětlení, aby se čtenář v jednotlivých zápletkách neztratil. Pokud je toho vysvětlování příliš na úkor vlastního děje, tak pak to asi moc záživná knížka nebude.