sobota 31. května 2014

Malými krůčky ke zvládnutí velkých úkolů

Tento příspěvek je krátkou obhajobou dekompozice složitých problémů na malé koncové tasky. Práce s malými tasky totiž působí přímo blahodárně na často dost zatížené nervové soustavy členů projektového týmu. Pokud se váš projekt zasekává a dostává se do vážnějších problémů, zkuste se zamyslet nad tím, zda-li nebojujete s problémy, které jsou typické pro nezvládnutí správné dekompozice složitosti.

Malý task

Co je vlastně myšleno malým taskem? Pro mě je to task s dobou realizace do 4 hodin, ale ideálně kolem 2h. A nezávisle na tom, zda-li se jedná o práci analytickou, návrhovou, implementační, testování nebo úkoly spojené s podpůrnou infrastrukturou projektu a byrokracií (paper work). Velikost commitu v případě implementačního tasku by neměla překročit řádově desítky změněných řádků (počítáno jako LLOC). Na druhou stranu je počet změněných řádků kódu dost zavádějící metrika. Někdy můžeme půl dne hledat bug a výsledkem je změna na jednom řádku (+ nový původně padající test). Jindy děláme refaktoring a jeden rozsáhlejší rename vynutí změny na stovkách řádků.

Ne vždy se to podaří ...

Rozložení řešeného problému na malé postupné krůčky je efektivní a univerzální technika ve všech oborech lidské činnosti. Ve vývoji software je ale nutné mít vhodné podpůrné nástroje a efektivní postupy. Jinak se dobře míněná snaha o zvýšení efektivity práce změní ve znechucené trápení. Je nutné zajistit splnění několika základních podmínek:

  • Pracovní postupy by neměly být zatíženy přílišným formalismem. Čím méně restriktivních opatření, tím lépe. Příliš formální metodiky jsou účinnou antikoncepcí proti vytváření malých tasků. Předpokládám, že agilita si vybojovala místo i ve vašem vývojovém týmu a proto bude tato podmínka bude splněna.
  • Používejte nástroj, který vám usnadní správu a vizualizaci tasků. Protože jsou malé, je jich také mnoho. Nástroj musí být intuitivní, rychlý a dostupný bez omezení. My jsme se rychle spřátelili s YouTrackem, který pro naše potřeby maximálně vyhovuje.
  • Vytvoření tasku musí být rychlé. Vybrat umístění (projekt, feature nebo user story), zadat název, stručný popis, akceptační kritéria a estimaci. To by mělo ve většině případů stačit. Někdy se při vytváření tasku zasekneme, neboť napsat dobré zadání je pracné. Ale zdržovat by nás mělo pouze naše myšlení a ne použitý nástroj.
  • Používejte pouze atributy, které potřebujete. Šablona tasku, která má desítky atributů je dobrá obvykle jen pro někoho, komu potřeba projektové formalizace způsobila neléčitelnou ztrátu zdravého rozumu. V jednoduchosti je síla, proto nejdůležitější položky musí být dostupné rychle, bez nutnosti překlikávání. Méně využívané položky by pak měly být schované na detailových kartách. A nepoužívané bez milosti odstraněny. Dvakrát si rozmyslete, než přidáte nový atribut.
  • Workflow tasku musí být jednoduché. Čím méně stavů tím lépe. Na našem posledním projektu jsme zvolili tyto: Backlog, Ready for Dev, Dev in Progress, Ready for Review, Review in Progress, Finished (+ Waiting) s vizualizací pomocí Kanban boardu. Pokud bychom neměli interní politiku o revidování každého tasku, pak bychom ještě dva stavy ušetřili. Některé typy tasků ale jedou v jiném režimu, např. task typu Bug nahlášený od testerů nebo v horším případě z produkce.
  • Mělo by být možné integrovat systém pro evidenci tasků s dalšími články vývojové infrastruktury. A to se správou repository, buildovacím serverem, IDE, CASE, apod. Např. k namapování změn v kódu na příslušný task pak pouze stačí odkazovat id tasku v commit message.

Ale když se to podaří ...

A v čem jsou vlastně malé tasky šikovnější než ty velké obludy?

  • Rychlé vyřešení tasku působí blahodárně na psychiku a dobrý pocit z dokončení je účinným motivátorem do další práce. Rozplizlé dlouhé tasky nás naopak demotivují, nevidíme na jejich vzdálený konec a vnášejí pochybnosti o naší pracovní efektivitě. Tak jako většina lidských činností je i vývoj software psychologickou hrou s naším podvědomím, snahou udržet nadšení, pozornost a správný kurz k požadovanému cíli.
  • Menší jednotky práce je snadnější přesně specifikovat. Problém jsme nuceni už při zadávání lépe promyslet a zadefinovat akceptační kritéria. Dobrým zadáním problému zvyšujeme pravděpodobnost správné realizace a efektivního review.
  • Přesnější estimace. Je dost deprimující, když se skutečná pracnost na hony liší od té odhadované. Malé úkoly trefíme mnohem lépe. Doporučuji mírně pesimistický přístup a zohlednit časovou rezervu. Udělat úkol dříve než se čekalo je povzbuzující. Máme ze sebe dobrý pocit a roste nám správným způsobem sebevědomí. Naopak výrazné přešvihnutí estimace nás dostává pod tlak, který často vyústí ve sníženou kvalitu výsledku.
  • Review menších změn je mnohem efektivnější. Je zřejmé, na co se zaměřit. Review trvá kratší dobu, takže reviewer je pozornější, neusíná a často i něco objeví.
  • Stává se méně často, že odcházíme domů a zůstane po nás nedokončený úkol. Já osobně nemám tyhle situace vůbec rád a když něco nedotáhnu do konce, přemýšlím nad tím ještě doma. A nejhorší je nedotahovat věci v pátek odpoledne.
  • Pokud zaneseme chybu nebo rozbijeme CI build, pak je problém mnohem lépe dohledatelný. Je rozdíl, pokud hledáte v commitu s 20 změněnými řádky nebo s 200.
  • Dostáváme rychlejší zpětnou vazbu a pokud se něco nepovede, nevracíme se příliš daleko dozadu. Víme, jak je nepříjemné zahodit kód, nad kterým jsme strávili dlouhé hodiny nebo dny. Obvykle je ale výhodnější špatný kód zahodit, než obhajovat jeho smysluplnost a tím jeho eutanázii pouze oddalovat a zvyšovat tak náklady na vývoj.
  • Malé tasky vnášejí do vývoje větší dynamiku a celý tým může sledovat postup řešení většího celku, třeba user story. Nestává se, že programátor dostane zadání, pár dnů o něm nevíte a pak se objeví s “vymazlenou” implementací, která se ale hodně odklonila od původního záměru a trpí mnoha nedostatky.
  • Jistě znáte techniku TDD, která nabádá ke krátkým implementačním cyklům se strukturou: 1. rozmysli si co chceš (napiš test), 2. naimplementuj to (napiš produkční kód), 3. zkontroluj, jestli změna nerozbila celek (všechny testy zelené), 4. vylepši fungující implementaci (refaktoring). Díky TDD dostáváme okamžitou zpětnou vazbu o stavu našeho kódu. Malý task by pak v tomto chápání mohl mít podobný efekt jako cyklus TDD, ale s větší granularitou. Nutí nás více rozmýšlet požadovaný výsledek, ten dostáváme již během několika hodin. Po uložení změn do repository získáme skrze CI build informaci o stavu celku. V rámci review můžeme řešení ještě vylepšit.

S malými tasky můžeme dosáhnout velkých výsledků. A navíc velmi efektivním způsobem. A za každé dokončení tasku se můžeme nějak odměnit. Třeba procházkou k lednici, krátkou rozcvičkou nebo dobrým kafem. A život programátora bude zase o něco veselejší! ;)

neděle 4. května 2014

Mýty o češtině v softwarových projektech

Pojďme společně rozkrýt několik mýtů pojících se k používání češtiny v softwarových projektech. Do mých názorů se promítají zkušenosti ze dvou zcela odlišných softwarových firem a světů. Dřívější firma byla orientovaná na regionální trh (ČR, SK) a všechny projekty byly realizovány v češtině. Stávající firma naopak dodává systémy do všech koutů světa a na vývoji pracují lidé z více států. Vývoj tedy logicky probíhá kompletně v angličtině.

Je potřeba přiznat, že ještě před několika lety bych určitě mluvil jinak a tento blogpost bych nenapsal. I z některých mých prehistorických příspěvků je zřejmé, jaký pasivní zastánce češtiny v kódu jsem dříve býval. :) Možná ne přímo zastánce, ale spíš ten, kterému čeština nijak výrazně nevadila. Byl jsem tak prostě zvyklý roky programovat a celé to zapadalo do požadavků na software realizovaných projektů. Domnívám se, že není problém své názory měnit na základě poučení z chyb a podle postupně získaných zkušeností. :)

Mýtus "Programátor nepotřebuje umět výborně anglicky"

Znalost angličtiny je jednou z klíčových dovedností programátora. Dalo by se říct, že je to takový meta-skill. Náš obor klade vysoké nároky na průběžné učení a rozšiřování profesní kvalifikace. Bez znalosti angličtiny je právě získávání nových dovedností a znalostí velmi problematické. Knížky, fóra, github, blogy, socsítě, návody, dokumentace, a další jsou studnicí informací, které mohou rozhodovat o úspěchu či neúspěchu celého projektu.

Zdrojový kód je důležitý komunikační prostředek celého týmu. Jazykové schopnosti členů týmu se výrazně projeví na kvalitě celého kódu. Špatné pojmenování je významným zdrojem programových chyb a nečekaných překvapení. Testy slouží jako interní dokumentace systému a jejich názvy musí být co nejvýstižnější.

Určitě nezastávám názor, že programátor, který neumí pořádně anglicky, není schopen vytvářet ve výsledku kvalitní aplikace. Věřím, že mnoho dobrých aplikací napsali a ještě napíšou lidé, kteří anglicky umí velice špatně. Ale mnohem větší procento dobrých programátorů angličtinu ovládá dobře. Je to stejné jako s jinými skilly. Nemusíte psát testy, používat TDD, CI, agilní metodiky, prototypování, iterativní vývoj, revize kódu, apod. a požadovaného výsledku také dosáhnete. Otázkou je v jaké kvalitě a s jakou efektivitou? A hlavně, kdo a jak bude schopen aplikaci dlouhodobě udržovat a rozvíjet?

Souvislost jazykové vybavenosti programátora a otázka pracovních příležitostí na zajímavých projektech je na samostatný blogpost. Určitě má zkušenosti každý, kdo se v poslední době zajímal o nějaké pracovní nabídky. Angličtina je již téměř všude must-have. A kde není, tam je to podezřelé. :)

Mýtus "Čeština ve zdrojovém kódu nevadí"

English. Lingua franca for programming.

Z pohledu někoho, kdo angličtinou příliš nevládne, je čeština jedinou šancí jak významu kódu porozumět. Já ale za ideální situaci považuji, když jediným místem ve zdrojových kódech, kde objevíme češtinu, jsou lokalizované resources. Čeština namíchaná s angličtinou snižuje čitelnost kódu. Do názvosloví se zanášejí patvary typu ObjednavkaFactory, ObjednavkaTovarna, getCena, apod. Neustále se řeší, co se má přeložit a kdy je lepší ponechat anglický ekvivalent. Pamatuji na situaci, kdy kolega pojmenoval třídu 'Kanalovna', protože pracovala s channels WCF služby. Jiným hezkým případem programátorské lidové tvořivosti budiž chybová hláška z přiloženého tweetu, kterou nedávno zpopularizoval Augi. Prostě hromada problémů způsobená díky pokusům sloučit dva nekompatibilní jazykové světy.


Mýtus "Terminologie domény by měla být v češtině, protože v ní máme větší vyjadřovací možnosti"

Nejčastější výjimky z pravidla “vše v angličtině” se dělají na úrovni názvů doménových objektů. Argumentem bývá terminologická složitost některých specifických domén, kdy je problém najít vhodný termín “alespoň v češtině”. Pokud ale najdeme vhodný termín v češtině, určitě ho najdeme také v angličtině. V některých případech se určitě vyplatí spolupracovat se zkušeným překladatelem. Doménu by měli dobře znát doménoví analytici a v potřebném rozsahu také programátoři. Kodéři bez znalostí souvislostí nemají obvykle v projektu příliš vysokou hodnotu.

Osobně vidím problém ještě někde jinde. A sice je nutné, aby každý projekt měl dobře definovaný doménový slovník, ze kterého vychází terminologie používaná v projektu. Z vlastní zkušenosti vím, jak velký problém to bývá. Pokud se už na začátku projektu nezadefinují jednoznačně pojmy, pak to dopadá tak, že se systém hemží synonymy a různými názvy pro stejnou entitu nebo vlastnost. Takové nejednoznačnosti výrazně komplikují pochopení a udržovatelnost systému.

Mýtus "Každý softwarový projekt by měl být realizován v angličtině"

Jsou projekty, u kterých je jasné, že jiná možnost než angličtina neexistuje. Např. děláte pro zahraničního zákazníka, ve vašem týmu se mluví více jazyky, máte globálnější ambice, vyvíjíte nějaký open-source nebo prostě jen chcete, aby váš kód pochopil i někdo nemluvící česky. Na druhou stranu jsou stále situace, kdy je nutné projekt realizovat ve větší míře v češtině. V případě, že máte pouze lokálního zákazníka, kterému nevadí, že nebude mít projektové artefakty v angličtině a současně nemáte tým, který by to v angličtině zvládl. Pak to zřejmě smysl má. Osobně si ale myslím, že takové ryze české projekty budou stále více v menšině. Uvědomělí zákazníci budou požadovat za svoje (nemalé) investice realizace projektů, které nebudou pevně svázané s lokálním jazykem.

Mýtus "Dobrá kombinace je kód v angličtině a zbytek v češtině"

Nevidím to jako úplně dobrý nápad. Takový hybrid asi nebude použitelný pro někoho, kdo nemluví česky. Při realizaci projektu se navíc budete muset neustále přepínat mezi češtinou a angličtinou. Rozhodněte se pro angličtinu a vytvářejte všechny projektové artefakty v angličtině. Zpočátku to možná bude trochu drhnout, ale vydržte, výhody jsou zřejmé.

Mýtus "Kód v angličtině, komentáře v češtině"

Raději dobře čitelný kód, který nepotřebuje (nedokumentační) komentáře. A pokud jsou přeci jen potřeba, pak bych rozhodně zůstal u angličtiny. Komentáře v češtině by se nejspíše staly nesmyslnými ostrůvky vítězství programátorova nacionálního cítění. U dokumentačních komentářů předpokládám, že budou vždy v angličtině.

A na závěr jeden bonbónek ...

"Pro větší názornost jsem zdrojový kód přeložil do češtiny"

Néé, jen to ne. Pokud k tomu autor překladu odborné literatury přidá ještě jako bonus diakritiku, pak takovou knížku dočte do konce zřejmě jen hodně otrlý jedinec. ;)

Jaký názor na symbiózu češtiny a angličtiny máte vy? Díky za komentář.

sobota 26. dubna 2014

Dopřejte vašemu kódu pořádnou revizi

Revize kódu (code review) patří mezi techniky, které mohou posunout vnitřní a vnější kvalitu vašeho systému do vyšší ligy. Musí se však dělat správně a efektivně. Revidování kódu může být časově náročné a od manažerů víme, že čas jsou peníze. Proto se systematické revidování používá především u projektů, kde je kvalita nadřazená brzkému dodání. Na druhou stranu, pokud jste někdy dělali na projektu, který se dostal do spirály smrti díky tragické kvalitě, jistě se shodneme na tom, že pojem “rychlý vývoj” je vždy relativní. Dobré revize v konečném důsledku čas a náklady na projekt snižují.

Revidovat kód lze mnoha způsoby. Ti co programují v páru, provádějí revizi kódu nepřetržitě již během jeho psaní. V ostatních případech jsou fáze psaní kódu a fáze revidování v čase odděleny. Čím více je revize opožděna za implementací, tím jsou ale případné nápravy komplikovanější. Revize se také liší stupněm formálnosti, rozsahem (např. pouze kritické části aplikace nebo všechno), počtem revidujících (jeden nebo celá skupina) a tím, zda-li je autor kódu přítomen nebo ne.

Hlavní přínosy

K čemu konkrétně jsou vlastně revize kódu dobré? Pomáhají nám v především v těchto záležitostech:

  • Ověřování splnění zadání.
  • Objevování chyb a případných rizik.
  • Zlepšování kvality návrhu.
  • Zlepšování čitelnosti kódu.
  • Zlepšování udržovatelnosti kódu.
  • Šíření znalostí a způsobu řešení problémů.
  • Zvyšování zastupitelnosti členů týmu.
  • Autor kódu dostává zpětnou vazbu ke svojí práci a díky ní se rychleji zlepšuje.

Dobře revidovat kód je dovednost, kterou musíme neustále procvičovat a zlepšovat. Abychom zbytečně nemrhali časem, ale aby nám revize opravdu sloužily, musíme si pohlídat několik základních věcí. Sem s nimi ...

Co mám vlastně revidovat?

Co opravdu, ale opravdu nemáme jako programátoři rádi, jsou špatně zadané úkoly. Při implementaci už není prostor na neurčitost. Ta nás brzdí a blokuje. Psát jednoznačné a srozumitelné zadání je ctností dobrého analytika. “Chytře” zadaný úkol (mrkněte na SMART) zvyšuje pravděpodobnost správného pochopení a odpovídající implementace a efektivní revize. Těžko ověříme splnění zadání, pokud je odbyté nebo nejasné. I jako revidující si vyžádejme upřesnění zadání, pokud je to potřeba. Revizí přebíráme stejnou zodpovědnost za úkol jako ten, kdo jej naimplementoval.

Velký nebo malý úkol

Revize malé změny - hodně připomínek, revize rozsáhlé změny - vypadá to dobře.

Pokud chceme mít revize opravdu smysluplné, dekomponujme problémy na pokud možno co nejmenší úkoly a ty revidujme odděleně. Implementace úkolu by neměla trvat více než jen několik hodin. Příliš rozsáhlé změny ukryjí defekty kódu, špatný design, bugy a jiné nedostatky. Snaha pochopit cizí kód (někdy i svůj) je vysoce náročná na soustředění a to jak víme není zadarmo. Po krátké době jsme unavení tak, že přepínáme na autopilota a pravděpodobnost přehlédnutí problému letí nahoru.

Dohledatelný rozsah změny

Rozsah revidované změny musí být jasně dohledatelný. Proto je vhodné, aby každý commit do repository byl logicky mapovaný právě na jeden úkol. Buildovací servery pak z takových commitů umí vyrobit ke každému úkolu přehledné reporty se zvýrazněním změn v jednotlivých souborech. Bez kvalitních podpůrných nástrojů a jejich vzájemné integrace se revize snadno změní ve zmatené prohlížení potenciálně změněných souborů.

Dobrá kondice revizora

Když se pořádně vyspíme, není pátek odpoledne a nemáme kofeinový deficit, pak máme nakročeno ke kvalitní revizi. Všechno je najednou mnohem jasnější. Prostě nemá smysl revidovat, když je člověk unavený. Je to podobné jako s programováním, jenom s tím rozdílem, že sice žádnou chybu nepřiděláme, ale ani žádnou neobjevíme.

Potřebná úroveň znalostí

Schopnosti a dovednosti revidujícího by neměly být výrazně nižší než schopnosti autora kódu. Mohlo by se pak totiž stát, že se mu zvolené řešení i kód bez výhrad líbí, přestože ve skutečnosti trpí mnoha nedostatky. A taková revize nemá žádný význam. Revidovat by proto měli ti zkušenější z týmu. Revidující by měl mít dobré znalosti použitých programovacích jazyků, frameworků, návrhových vzorů a principů, a mnoha dalších věcí. Jedním z přínosů revizí je právě to, že méně zkušení členové týmu získávají skrze zpětnou vazbu z revizí mnohem rychleji nové zkušenosti a tím se profesně zlepšují.

Automatizujme

Používejme nástroje pro statickou a dynamickou analýzu kódu, které se budou automatizovaně spouštět v rámci buildů hlídajících kvalitu. Co lze zkontrolovat automatizovaně to nemusíme revidovat. Šetřeme čas a soustřeďme se na záležitosti, které za nás programy nevyřeší.

Optimalizujme workflow

Pokud zatím revize nepoužíváte, zavádějte je opatrně. Hledejte ideální workflow, které bude kompatibilní s vašimi vývojovými procesy. Vyzkoušejte více variant a vyberte tu pravou. Až se vám revize dostanou pod kůži v rámci menšího týmu, teprve potom je zavádějte ve větším rozsahu. Revize kódu mají své opodstatnění jak v agilních, tak i především ve formálnějších metodikách. A není problém kombinovat revize více typů. Například my v rámci našeho projektu děláme některé úkoly v páru (okamžitá revize). Většinu úkolů ale revidujeme ad-post bez autora nebo při komplikovanějších věcech i s jeho přítomností. Velké implementační celky ještě revidujeme více formální revizí se softwarovým architektem zákazníka.

Sociální aspekty revize

S revizí kódu je to jako se ženou - ani nevíte jak a už jste v problémech. Je potřeba k ní přistupovat opatrně, lehce našlapovat a ve vyjadřování volit slovník gentlemana. Výstupem revizí by měly být připomínky, které zlepší kvalitu kódu a nezhorší vztahy v týmu. Případná kritika by měla být věcná, slušná a cílená na konkrétní problém. Žádné osobní útoky. Svojí nešikovností nebo dokonce špatným úmyslem, můžeme rozpoutat nepříjemné konflikty, které se projeví na fungování týmu. Velkým problémem je také nadřazený přístup zkušenějších vývojářů k těm méně zkušeným. Zdravě fungující tým by si měl s podobnými problémy poradit, ale i přesto buďte opatrní.

Motivace odvádět kvalitní práci

Dobře motivovaný tým chápe revize jako další prostředek ke zlepšení výsledků svojí práce. Na týmy s problematickou úrovní práce může mít zavedení revizí také velmi příznivý efekt. Programátoři, kteří kvalitu kódu do té doby příliš neřešili a v tichosti si něco bastlili, mají najednou nové starosti. Jejich kód začne někdo jiný číst a dokonce připomínkovat. Někdy i veřejně v rámci celého týmu. Dotyčný by musel být skutečný rebel, aby to v něm nehrklo a nezačal více přemýšlet nad tím co a jak píše. Najednou bude jeho práce srovnávána s kolegy a nikdo nechce patřit mezi ty, kteří jsou hodnoceni špatně. Opět pozor na sociální stránku zavádění revizí. Ať se vám v týmu nezačne příliš jiskřit.

Jak vám to reviduje?

Moje osobní zkušenosti s revizemi kódu jsou téměř výhradně pozitivní. Postupně jsme si vyladili vývojový proces tak, že díky revizím kódu těžíme z výše popsaných přínosů. Hodně jsme se vzájemně naučili. Jakmile někdo objeví nový trik, hned ho umí i revidující. Dost nám pomáhají revize se softwarovými architekty z Německa, kteří mají dlouholeté zkušenosti s vývojem jejich systému, do kterého aktuálně píšeme moduly. Jejich rady nás mnohokrát nasměrovaly k lepšímu řešení.

Za mě tedy revizím kódu jednoznačné ANO.

A jaké máte zkušenosti s revidováním kódu vy? Dobré nebo špatné?

neděle 19. ledna 2014

Agilita v korporátním světě

… aneb honba za nulovou chybovostí

Aktuálně dělám na projektu, který je zajímavý z několika pohledů. Jedná se o software pro medical devices, kde jsou kladeny vysoké nároky na zajištění kvality. A neméně zajímavou skutečností je střet historicky vodopádového korporátního přístupu se sílícím vlivem agilních technik. Rád bych popsal zajímavé oblasti naší práce s důrazem na postupy, které nám pomáhají zajišťovat požadovanou kvalitu.

Co vlastně děláme

Na úvod stručně ke kontextu naší práce. Máme v Olomouci tříčlenný vývojový tým a pracujeme pro německou zdravotnickou korporaci Maquet. Konkrétně spolupracujeme se softwarovým oddělením na vývoji systému Tegris. Ten integruje ovládání různých zařízení používaných na operačním sále do jedné aplikace. Ovládat se dají například chytré operační stoly, speciální světla, HD kamery, endoskop a další. Systém má mnoho pokročilých funkcí pro nahrávání a streamování multisource videa. Zajišťuje také různé agendy potřebné při operacích. Jedná se o softwarové řešení dodávané spolu se speciálním hardware, kvůli vysokým nárokům na systém a požadavkům na mnoho speciálních karet a portů. Prostě být operován na sále s tak moderním vybavením musí být snem každého pacienta. Nebo raději ne. ;)

Prvním naším projektem byla integrace ovládání videokonferenčních systémů. Zjednodušeně řečeno jsme vyvíjeli modul, který umožňuje při operaci provádět videokonferenční hovory a ovládat je z Tegrisu.

Aktuálním druhým projektem je ovládání zařízení, která jsou připojená k nové hardwarové sběrnici. Na tu lze nyní připojit chytré světelné hlavy a HD kamery používané na operačním sále. Každé zařízení má své vlastní hardwarové ovládací panely. Nově tato zařízení půjdou ovládat také přes systém Tegris. A to je naším úkolem.

Vývoj pro medical devices

Vývoj software pro medical devices má svá specifika. Pokud chcete software dodávat do států EU, pak musíte být kompatibilní s hromadou direktiv sjednocených pod MDD. Jedná se o tak složitou byrokracii, že je jen pár lidí na světě, kteří ji mají kompletně nastudovanou a nechají si zaplatit slušný peníz za základní proškolení. Když chcete prodávat do USA, pak musíte být zase kompatibilní s direktivami vydávanými americkou FDA. Ve výsledku to vypadá tak, že potřebujete ve firmě alespoň jednoho člověka na plný pracovní úvazek, který zkoumá, co musí jednotlivé softwarové komponenty splňovat a jaké nároky jsou kladeny na samotný vývojový proces. Takovému člověku opravdu nezávidím. ;)

Pro nás to znamená, že veškeré vývojové fáze musí být standardizované. Všechny meziprodukty vývojového procesu (požadavky, návrh, kód, testovací případy, …) musí být revidovány někým nezúčastněným. Američané vyžadují navíc diskutabilní 100% pokrytí testy. Velký důraz je kladen na fázi akceptačního testování, testuje se v různých podmínkách (laboratorní, reálné) a před každým release. Veškerá snaha je cílena na dosažení co nejmenší chybovosti v produkci.

Medical devices jsou navíc klasifikovány do několika tříd podle závažnosti následků v případě poruchy takového zařízení. Třeba class I jsou zařízení, jejichž výpadek neohrožuje zdraví pacienta. Class III jsou naopak zařízení, jejichž špatná funkčnost může vést k těžkým následkům nebo smrti pacienta. Např. bylo by hodně nepříjemné, kdyby vynechával kardiostimulátor se speciálním software nebo kdyby se zasekl endoskop pro mozkové operace. Náš projekt řeší světla na operačním sále, ty jsou class II. Kdyby světla zhasla nechtěným zásahem obsluhy nebo z důvodu chyby software, asi by na operačním sále nebylo příliš veselo.

Zadání a estimace projektu

Součástí zadání je více jak stovka různě pracných funkcionálních a systémových požadavků na vyvíjený modul, podrobný popis komunikačního protokolu pro hardwarovou sběrnici a vizualizace UI. Z centrály jsme si dovezli reálné železo, které nám zabírá jednu stěnu naší malé kanceláře.

Bylo potřeba se seznámit s problémem, udělat si jednoduchý prototyp pro komunikaci se zařízeními a rychle dodat orientační estimaci, aby byl hlavní projekťák spokojený. Využili jsme agilní techniku odhadování v abstraktních story points. Poměřovali jsme nejdříve jednotlivé requirementy relativně podle předpokládané pracnosti a oceňovali je s využitím čísel od pana Fibonacciho - 1, 2, 3, 5, 8, 13, 21. Nakonec byl každý bod vynásoben bulharskou konstantou, která měla promítnout abstrakci do reálnějších člověkodnů.

Specifikace architektury

Jeden ze systémových požadavků si vynutil, aby většina business logiky ovládání (nízkoúrovňová komunikace, řízení přístupu, zjišťování stavu zařízení, synchronizace, apod.) byla oddělena od hlavního systému do samostatné aplikace. Tato aplikace musela být zpřístupněna jako služba, kterou mělo mít možnost využívat více klientů. Požadavek zásadně ovlivňoval architekturu řešení. Nakonec bylo potřeba navrhnout několik konceptů, ze kterých byl vybrán ten nejvhodnější.

Vítězný koncept se musel rozpracovat do několika různě abstraktních UML diagramů. Hlavní struktura systému je zachycena pomocí komponentového diagramu. Jednotlivé komponenty pak mají své poddiagramy stále ještě na úrovni poměrně abstraktních podkomponent. Specifikace musela obsahovat popis dalších technických aspektů zvoleného řešení.

Z pohledu agilních technik je použití UML vhodné pro lepší vzájemné porozumění při diskuzi o problému. Zároveň se ale nedoporučuje trávit kreslením diagramů příliš času. Důležitá zpětná vazba přichází totiž až ze samotné implementace. Čím je feedback pozdější, tím jsou případné změny dražší. S ohledem na typ našeho projektu jsme ale při realizaci nuceni používat UML poměrně často.

Rozdělení do etap

Rozplánovali jsme celý projekt na menší etapy, které vzdáleně připomínají agilní iterace. Liší se však zásadně tím, že nemají pevný časový rámec. Vybrané requirementy se musí vyřešit všechny. To je opět úlitba centrálnímu projektovému managementu. Nevýhodou je, že se celá etapa natahuje, nejde vrátit nevyřešené úkoly do backlogu a práce tolik neodsýpají. Paralelní práce na více etapách současně nám navíc moc nefungovaly. I tak ale považujeme rozdělení do etap za lepší přístup než čistě vodopádový model. Zpětnou vazbu o postupu prací dostáváme poměrně rychle a případné “vracečky” nejsou tak bolestivé. Etapa v ideálním případě trvá tak 15 pracovních dnů a prochází všemi níže popsanými fázemi.

Analýza požadavků

Rozdělení požadavků do etap bylo provedeno na začátku projektu. Přesun požadavků mezi etapami není příliš oblíbená činnost u centrálního managementu. Někdy ale není zbytí. Stává se poměrně často, že požadavek je potřeba upřesnit nebo zcela změnit. Pak je dobré, abychom měli “zákazníka” komunikačně co nejblíže. “Změnová řízení” jsou někdy otázkou hodin, jindy zase dnů. Někdy se musí chování upřesňovat s výrobním oddělením ve Francii.

Abychom si mohli naše domněnky rychle potvrdit nebo vyvrátit, pomáháme si prototypováním. Věříme, že s dostatkem informací o problému můžeme udělat lepší návrh. Navíc jsme záměrně naplánovali nejrizikovější požadavky do prvních etap realizace, kdy bylo prototypování nejvíc.

Návrh

Každá etapa má návrhovou fázi, kdy mapujeme řešené požadavky na use cases. Iterativním způsobem rozšiřujeme stávající design. Přidáváme (sub)komponenty a jejich vzájemné vztahy. Rozkreslujeme chování komponent do sekvenčních diagramů. Pokud je potřeba, pomůžeme si stavovým nebo aktivitním diagramem. Snažíme se držet na co nejvyšší nutné úrovni abstrakce. Až na úroveň diagramu tříd chodíme jen zřídka. Designové tasky většinou děláme ve dvojici. Je to pro nás efektivnější metoda, kdy nápady okamžitě diskutujeme, připomínkujeme a případně zahazujeme.

Vytvořený návrh musí projít přes design review, které se provádí za přítomnosti softwarového architekta z Německa. Někdy přímo v Německu a v poslední době se nám také daří dělat review i vzdáleně. Dostáváme zpětnou vazbu a rady od kolegů, kteří mají s podobnými systémy mnohem více zkušeností než my. Někdy sice s jejich argumenty úplně nesouhlasíme, ale to je v software development asi normální. Mnohdy je to bazírování na zdánlivých maličkostech, ale je v tom cítit německá preciznost, která se mi ve výsledku hodně líbí.

Implementace

Pokud se dostaneme přes design review, pak se celí natěšení vrháme do vlastní implementace. Snažíme se o TDD přístup, kterým zajišťujeme fázi návrhu na té nejnižší úrovni. Využíváme také Behavior-Driven Development techniku, která zahrnuje outside-in přístup, zlepšuje dokumentační aspekty testů a elegantně řeší problém jednoho assertu na test.

Jednotkové testy musí testovat třídy v izolaci. Používáme proto různé adaptéry abstrahující třídy frameworku, např. ISerialPortAdapter, ITcpClientAdapter, ITimerAdapter, ITaskAdapter. Asynchronní zpracování musí být v jednotkových testech převedeno na synchronní.

Hodně našich tříd musí být thread-safe. Snažíme se proto psát integrační testy, které testují třídy při paralelním přístupu z více vláken. Zatím nemáme příliš zkušeností se zátěžovým testováním, ale snažíme se to změnit.

Tegris je poměrně rozsáhlý systém, který má vysoké výkonnostní požadavky a jsou nutné značné optimalizace na straně implementace (vlákna, pooling, lazy). Error handling je samostatná kapitola, která nám zabrala jednu celou etapu. Systém se musí umět vzpamatovat sám z některých chybových stavů. A především chyba v jednom modulu nesmí ohrozit činnost systému jako celku.

Co se týče UI, tak děláme pouze dummy verzi, která je později nahrazena verzí finální dodávanou od designérské firmy. Systém je přizpůsoben pro dotykové ovládání. Myši nejsou na operačních sálech vítanou havětí. ;)

Code review

Code review si děláme nejdříve interně sami. Snažíme se, aby se vlastní implementace rozpadala na malé úkoly, které zaberou maximálně několik hodin práce. Takto granulované úkoly se ještě rozumně revidují. Ve větších úkolech se už revidující dost ztrácí. Review nám přináší velkou přidanou hodnotu. Občas odhalíme problém v implementaci nebo problematický design, připomínkujeme (ne)čistý kód, vysokou komplexitu, nešikovnou terminologii, apod. Velkou výhodou je to, že se v našem týmu udržuje povědomí o změnách, učíme se jeden od druhého dobré postupy a zvyšujeme vzájemnou zastupitelnost. Refaktoring není u nás sprostým slovem. Praktikujeme společné vlastnictví kódu. Bohužel se nám nedaří ve větší míře dělat pair-programming. Ale není všem dnům konec.

V závěru etapy je kód revidován kolegy z Neměcka. Dozvíme se zajímavé připomínky a dostaneme zpětnou vazbu od někoho, kdo se přímo na implementaci nepodílel. Za sebe opět hodnotím tento postup velice kladně.

Pokud dojde v rámci implementace ke změnám v designu, zanášíme je průběžně do UML modelu.

Testovací případy

Testovací případy (test cases) jsme si nejdříve psali sami, ale teď to rádi přenecháváme specialistům od našich západních sousedů. Každý požadavek musí být mapovaný na nějaký testovací případ. Testovací případy jsou zjednodušeně řečeno soupisy prerequisities, test steps a expected results. Měl by je psát někdo z QA oddělení a jsou prováděny ručně před každým vydáním aplikace. My si je musíme také projít před akceptací každé etapy.

Znám i zajímavější práci než psát testovací případy, ale na druhou stranu je to užitečný pohled na systém očima uživatele.

Zajímavostí je, že jsme v rámci projektu museli vyvinout poměrně komplexní simulační nástroj. Jedná se o chytrý fake, který se chová jako reálná zařízení. Umí simulovat chybové stavy, odebírat a přidávat zařízení za běhu a další situace, které by bylo drahé a někdy i velmi problematické navodit se skutečným zařízením. Tento simulační nástroj je určen na primární otestování testovacích případů před vlastním testováním v reálných podmínkách. Ani pro testery totiž není vždy možné se rychle dostat k drahému fyzickému zařízení.

Infrastruktura

Centrální projektový management používá pro podporu vývojového procesu systém Polarion, kterému se naše jednotka snaží spíše vyhýbat. ;) Náš tým si většinu času vystačí s nástrojem YouTrack, ve kterém uděláme rozpad celé etapy do malých tasků. Používáme něco na způsob Kanbanu se stavy Backlog, Ready to Dev, Dev in Progress, Ready for Review, Review in Progress, Finished. Každý task musí mít jasně daná akceptační kritéria. Žádné nekonkrétní, problematicky revidovatelné formulace.

Pro kreslení UML byl vybrán Enterprise Architect, který se nám podařilo postupně ochočit tak, aby pracoval pro nás a ne proti nám. Některé jeho features jsou ale opravdu pouze pro otrlé jedince.

Správu zdrojových kódů řešíme přes Mercurial, nad kterým kmitá TeamCity. Buildovací skripty jsou napsané v Rake (Ruby Make).

Pracujeme ve Visual Studio 2012 s ReSharper 7. Aplikace je napsaná v C# nad .Net 4.0, UI je ve WPF a služba je typu WCF. Jako testovací framework je využit NUnit a pro mockování RhinoMocks. Pokrytí testy měříme přes dotCover. Kódovací standardy nám hlídá policajt StyleCop a jiný policajt FxCop zase provádí statickou analýzu kódu.

Pár slov na závěr

Ještě nevíme, jak celý projekt dopadne. Netušíme, jaká bude výsledná chybovost v produkci. Doufáme však, že minimální. Děláme pro to maximum. Snažíme se využívat všech nám známých technik pro zajištění kvality. Získáváme tím už od začátku větší pocit jistoty a práce není stresující. Navíc je docela fajn pracovat pro firmu, která má v Programming Guidelines jako první uvedeno pravidlo:

“It is more important to write correct and maintainable code than supposedly quickly programmed code.”

Můžete se mrknout na komerční videa představující systém Tegris a novou generaci světel Volista.

neděle 12. ledna 2014

Proč vývojáři odcházejí z IT firem

Brzy tomu bude rok, co jsem odešel z IT firmy, ve které jsem pracoval 13 let. Bylo to pro mě dost zásadní rozhodnutí a proto jsem si chtěl své důvody pro odchod porovnat s názory ostatních “nespokojenců”. Poptal jsem se komunity na devel.cz, jaké (by) byly jejich důvody pro odchod z firmy. Díky Jirkovi Kneslovi jsem také mohl nahlédnout do výsledků ankety o programátorské práci snů.

Nakonec vznikl tento příspěvek jako kompendium názorů několika desítek lidí z IT a jejich pracovních potřeb. Mohl by se stát checklistem pro ty, kteří programátory zaměstnávají a chtějí si je i do budoucna udržet.

Dvě skupiny vývojářů

Zřejmě má smysl rozdělit vývojáře do dvou logických skupin. Do té první by patřili lidé, kteří do práce chodí proto, aby něco vydělali a nemají potřebu se neustále učit nové věci. Ve své práci používají několik technologií a jazyků, které mají zvládnuté buď dobře nebo špatně. Mají každopádně své zaběhlé pracovní postupy a tyto postupy neradi mění. Mají pouze nonIT koníčky a doma počítač zapínají spíš pro zábavu než kvůli práci. Jsou to programátoři usedlíci.

Do druhé skupiny patří všichni ti, pro které je programováni víc než jen práce. Je to jejich vášeň a návyková droga zároveň. Nová technologie, nový jazyk nebo nový projekt v jejich těle vyvolávají příjemné chvění. Chtějí klouzat po technologické vlně a pořád se zlepšovat. Jejich počítače pracuji na plný výkon v práci i doma. Takoví programátoři jsou nadšení dobyvatelé nových technologií.

Každá skupina programátorů má své místo v oboru a je potřeba je obě respektovat a jejich případných předností využívat. Od práce, kterou jsou ochotni dělat usedlíci, by dobyvatelé rychle utekli. Naopak šikovní dobyvatelé obvykle zvládají novátorské úkoly s mnohem větší elegancí.

Atraktivita práce

Pracovní stereotyp působí jako infekce na motivaci a pracovní výkonnost. Programátorskou senilitu zajistí práce na dlouhodobém a nezajímavém projektu, ve kterém se navíc používají zastaralé technologie. Úplné peklo je pak udržovat legacy systém, jehož technologický dluh se rovná dvacetileté hypotéce. Dobyvatelé preferují raději pestrost krátkodobých projektů než pracovní agónii těch dlouhodobých. Firmy by měly být aktivní a hledat technologické výzvy pro nové projekty, díky kterým by využívaly a zvyšovaly potenciál svých lidí.

Profesní růst

Atraktivní pracovní náplň zřejmě podněcuje profesní růst. Firmy by navíc měly investovat do smysluplného školení lidí a podporovat firemní kulturu sdílení znalostí. Nabízet nějakou formu innovation time. Akceptovat, promýšlet a případně realizovat nápady na zlepšení od všech členů týmu. Skvělé je mít v blízkosti člověka, který v něčem vyniká a inspiruje ostatní. Firma by také měla vytvářet zdravou úroveň pracovního stresu, která napomáhá udržovat pracovní tempo a nutí lidi ke zlepšování. Na pocit sebeuspokojení už doplatilo hodně lidí i neexistujících firem.

Smysl práce

Dělat na projektu, kterému člověk nevěří, je demotivující. Rádi děláme práci, která přináší business value a na konci které najdeme spokojené uživatele. Ten pocit je někdy lepší než připsání výplaty nebo proplacení faktury na účet.

Zaručeným znechucovadlem práce je přeprocesované korporátní prostředí, ve kterém trávíte více času na poradách a řešením byrokracie, než samotnou činností, která vás baví.

Kvalita práce

Za svoji práci se nechceme stydět. Rádi bychom dodali produkt, který má vysokou vnitřní i vnější kvalitu. K životu programátora to sice patří, ale trávit příliš mnoho času bug huntingem je otrava. Pokud je produkt dlouhodobě ve špatném stavu, frustrace a stres se zvyšuje.

Je potěšující, kolik lidí z ankety preferuje prostředí, ve kterém se pracuje agilně, píšou se testy, dodržují se pravidla čistého kódu, zásady dobrého návrhu, apod. Na základě svých zkušeností totiž zjistili, že práce v takovém prostředí je baví a působí pozitivně na jejich nervový systém.

Mezilidské vztahy

Nakonec stejně nejčastějším důvodem pro odchod z firmy bývají samotní lidé, kteří znepříjemňují pracovní dobu. Ztráta důvěry k nadřízenému, nevhodné chování kolegů, nerespektování osobnosti a názorů, ponižování nebo osobní antipatie. Čím větší firma, tím větší procento “zmrdovosti”. Hodně programátorů proto z těchto důvodů preferuje menší firmy nebo volnonožství a práci na kontrakt.

Dobrotu také nedělá mix dobyvatelů a usedlíků v jednom vývojovém týmu. Mentální založení obou skupin je natolik odlišné, že nebudou mít zřejmě příliš společných tmelících prvků.

Rádi pracujeme s lidmi, se kterými jsme zároveň přátelé. Nemáme s nimi komunikační problém a máme naopak vzájemnou důvěru. A taková přátelství se mohou vytvořit třeba na teambuildingových akcích nebo při párovém programování.

Projektové řízení

Špatné projektové vedení může demoralizovat tým a úplně otrávit práci. Snem programátorů jsou firmy typu flat organization a self-managing týmy. Hierarchie není vrstvená a nešéfují lidé odtržení od reality skutečné práce. Lídry týmů jsou ti pracovně nejschopnější, kteří pracují po většinu času s ostatními.

Programátoři nemají rádi přílišný stres před dokončením projektu. Proto nemají rádi ani vodopádové vývojové procesy. Preferují naopak agilní postupy, při kterých dostávají informaci o stavu projektu ihned a během celého trvání projektu. Práce se tak dají lépe řídit a ve výsledku nejsou tolik stresující.

Férovost firmy

Férová firma dodržuje zákony, platí licenční poplatky, nepodplácí při výběrových řízeních, nevykazuje neprováděnou práci, nedodává odfláknuté produkty, nezneužívá evropské fondy, komunikuje otevřeně, platí včas závazky vůči zaměstnancům, atd. Férové firmě se dá prostě věřit. Férová firma přitahuje férové zaměstnance a vztahy se zákazníky zakládá na vzájemné důvěře. Naopak, nedá se očekávat, že v neférové firmě budou lidé spokojení.

Pracovní podmínky

Mít dobrý kávovar je v IT základ. Firmy nesmí zapomínat pravidelně upgradovat HW tak, aby nebyl slabým místem vývojářovy činnosti. Měl by mít k dispozici dobré SW nástroje, aby jeho práce byla efektivní a ne stereotypní. Pro dlouhodobý dobrý zdravotní stav programátora je nesmírně důležitá kvalitní židle, (pokud možno polohovací) stůl, ergonomický monitor, klávesnice, myš, apod.

Problém je mnohdy náročné dojíždění. Stále více lidí hledá kombinovaný home-office režim. Pak je však potřeba vyřešit specifika remote komunikace a organizace práce. Zpestřením pracovní rutiny může být občasné digitální nomádství a vzdálená práce z nějakého atraktivního místa.

Peníze

Peníze si možná nezaslouží být jako poslední téma. Ale věřte nebo ne, pro mnoho programátorů dobyvatelů není finanční ohodnocení v TOP3 jejich seznamu nejdůležitějších pracovních požadavků. Ten, kdo již dříve měnil práci z nefinančních důvodů, tomu jistě rozumí. Být totiž dobře zajištěný, ale přitom nespokojený programátor, není žádné terno.

Co si o tom myslíte vy?

pátek 3. ledna 2014

Fenomén Coderetreat

… aneb Den, který může změnit váš profesní život

V sobotu 14. prosince 2013 proběhl další díl Global Day of Coderetreat. Tentokrát na více než 165 místech po celém světě. Možná by vás mohlo zajímat, proč se tahle akce stává rok od roku populárnější. Pojďme se na Coderetreat podívat očima účastníků akce, která proběhla na Vsetíně.

První nakouknutí do říše testů

David: Jsem děsně rád za tuhle akci, že jsem prozřel, jak se vlastně píšou testy.

Akce je určena pro všechny programátory, kteří se chtějí naučit nebo se zdokonalit v technikách agilního vývoje. Důraz je kladen především na Test-Driven Development. Největší mentální dopad má akce samozřejmě na nováčky, pro které je to tak trochu výlet do říše za zrcadlem. Ovšem i ti zkušenější se vždy dozví něco nového a mohou si třeba vyzkoušet psaní testů v jiném programovacím jazyce.

Test-First jako mentální blok

Zdenek: Již dříve jsem se naučil přemýšlet o psaní kódu tak, aby byl testovatelný. Dnes jsem si ale potvrdil, že mám velký mentální blok přemýšlet nejdřív o psaní testu a teprve potom o kódu.
Helena: Aha, takže takhle se o tom má přemejšlet. Teď jsem konečně pochopila podstatu TDD.

Věřím, že velké procento SW projektů v dnešní době už má ve svých postupech psaní testů. Je ovšem rozdíl psát testy po implementaci a nebo ještě před ní. Začít nejdříve od testů je pro mnoho lidí velkou psychickou bariérou. Během celého dne se pokoušíme tuto bariéru postupně bourat a porozumět výhodám Test-First přístupu.

Návrh a efektivnější implementace pomocí Test-First

Zdenek: Nejzajímavější částí bylo specifikování požadavků přes testy.
Honza: Psát testy jako první je pro mě velký mentální obrat a může mi pomoci vyhnout se snaze o sice perfektní, ale mnohdy zbytečnou dopřednou implementaci.

Test-First přístup nás nutí nejdříve přemýšlet nad tím, co potřebujeme implementovat a pak teprve jak implementovat. Psaní testu je fáze návrhu, kdy dostáváme okamžitou zpětnou vazbu o testovatelnosti kódu. Implementujeme pouze to, co si vyžadují testy. Pěkně inkrementálně po malých krůčcích. Žádné zbytečné věci navíc, které aktuálně nepotřebujeme.

Párové programování

Lenka: Líbilo se mi párové programování. Víc hlav víc ví a dovedu si představit, že bychom ho ve firmě používali.
Sváťa: Úplně super bylo párové programování. I kdyby ta dvojice problém nevyřešila lépe, tak budou mít v budoucnu oba o problému mnohem větší povědomí.
Jarda: Dnešní zkušenost mě utvrzuje v tom, že párové programování by se mělo určitě více využívat v praxi.
Libor: Viděl jsem, jak Kuba perfektně ovládá svoje vývojové prostředí, jedna klávesová zkratka za druhou.
Zdenek: Po pěti sešnách jsem si myslel, že už mě nic nepřekvapí. Ale tady kolega mi i v té poslední ukázal zcela jiný přístup, který byl téměř geniální.

Je u vás běžné, že přijdete za kolegou v práci a začnete řešit problém společně? Nebo jste spíše týmem individualistů? Během Coderetreatu pracujete v páru neustále. A každý blok s jiným parťákem. Zpočátku možná trochu nezvyklá a tudíž nepříjemná záležitost, ale postupem času se vám to začne líbit. Ztrácíte zábrany, učíte se komunikovat o problému, hledáte společně řešení, díváte se na problém optikou kolegy, poznávat jeho pracovní postupy. A tím vším se učíte nové věci, zlepšujete se a jste nuceni ze sebe dostat to nejlepší.

Příjemná atmosféra na prvním místě

Marek: Byla zde velice přátelská atmosféra. To jsem u ajťáků nečekal. :)
Vytvoření příjemné atmosféry je nejdůležitějším předpokladem pro úspěch celé akce. Pokud se lidé dokáží uvolnit, užijí si i ta nejnáročnější cvičení. Mezi účastníky jsou různě pokročilí programátoři, přesto byste nenašli žádné náznaky nadřazenosti nebo posměchu. Všichni si chceme den pořádně užít, naučit se něco nového a poznat nové lidi. Koncept celé akce je navržen tak, aby k dosažení těchto cílů maximálně napomáhal.

Skrze kód spolu komunikujeme

Tomáš: Když si myslím, že je něco naprosto jasné, tak se to těm ostatním vůbec jasné zdát nemusí.
Zdenek: U ping-pongu jsem si uvědomil, jak dobré je přesně se vyjadřovat. Kolega totiž dělal vše úplně doslova.

Nejoblíbenější aktivitou je obvykle ping-pong, při kterém ještě navíc vypínáme zvuk. Jeden z dvojice píše test a druhý musí napsat implementaci, která zaručí procházení testu. Nemluví se, proto je velmi důležité, aby bylo pouze z kódu zřejmé, co je záměrem testu. Správné názvy testů, principy čistého kódu a důraz na jednoduchost vyústí v kód, který je dobře čitelný a tím pádem i dobře pochopitelný a udržovatelný.

Za hranicí komfortní zóny

Libor: Některé omezující požadavky mně opravdu zamotaly hlavu.
Zdenek: Do příště se musím naučit UML, protože mám trochu hokej ve vazbách v class diagramech.
Jarda: Zase jsem objevil své slabé stránky a mám určitě o čem přemýšlet.
Marek: Naučím se pořádně klávesové zkratky svého IDE.

Všichni se na akci přicházíme naučit něco nového a jako bonus obdržíme zpětnou vazbu o tom, co nám ve skutečnosti moc nejde. Dělej hlavně to, co ti nejde (pokud to ovšem potřebuješ) neboli dostávej se mimo svoji komfortní bublinu tak často, jak jen to jde. Budeš se učit mnohem rychleji.

Přenášení znalostí do praxe

Jarda: Už jen kdybychom u nás ve firmě zavedli psaní testů, tak by to byl velký pokrok.
Roman: Z minulého CR jsem si odnesl spoustu věcí a aplikoval jsem je ve své praxi. Začal jsem psát mnohem více testy. Bez testů si dnes už některé věci vůbec nedokážu představit.

Coderetreat není pouze celodenní bojová hra, která skončí po poslední session. Je to především začátek procesu, během kterého se začnete na váš svět vývoje software dívat jinýma očima. Možná pak vyzkoušíte nějaké nové věci na reálných projektech a možná jednu sobotu zúročíte na další roky efektivnější práce.

Závěrem

Pokud se jednou rozhodnete, že se nějakého Coderetreatu zúčastníte, budu vám držet palce, aby vaše hodnocení vypadalo třeba nějak takto:

Zdenek: Dnes jsem si uvědomil, jakou pozitivní energií mě celá ta akce nabila, kolik nových témat a podnětů jsem si odnesl a kolik nových kamarádů jsem poznal.

A tady je naše celá parta ve slušivých trikotech:

Video - závěrečná retrospektiva

Na závěr akce jsou všichni účastníci požádáni, aby volně odpověděli na otázky:

  • Co jste se dnes naučili nového?
  • Bylo něco, co vás dnes překvapilo?
  • Bude něco, co začnete v budoucnu dělat jinak?

Pokud si chcete zasadit výše uvedené výroky do širšího kontextu, určitě mrkněte na tohle video:

Poděkování

Chtěl bych poděkovat:

Nashledanou příště …

Odkazy

Pokud se chcete o formátu Coderetreat dozvědět více, můžete také navštívit: