neděle 28. února 2016

Požadavky na požadavky

Primárním cílem každého software je řešit problémy zákazníka nebo své cílové skupiny. Řešení je popsáno specifikací požadavků na systém. Psát dobré požadavky a efektivně je spravovat není snadné. Vyžaduje to specifické dovednosti a spolupráci napříč celým týmem. Dobrá specifikace je ale stejně důležitá jako dobrý zdrojový kód.

Pojďme se společně podívat, jaké problémy nám mohou komplikovat práci s požadavky.

Tohle není můj problém

Programátor: “Od analytiků dostáváme hrozné zadání. Jak podle toho máme něco naprogramovat!?”

Analytik: “Vykomunikoval jsem to se zákazníkem, popsal hlavní ideu, navrhl postup a tím to pro mě končí. Programátoři ale chtějí, abych za ně promýšlel problém do úplných detailů. To je jejich práce. Na to nemám čas.”

Pokud mají dvě skupiny v naší firmě potřebu se vzájemně vyhraňovat, máme dost závažný problém. Týmové role nespolupracují efektivně. Chtějí si nadefinovat rigidní rozhraní místo snahy o spolupráci na nejlepším výsledku. Agilita je o společné zodpovědnosti za vše, co s vyvíjeným software souvisí. Včetně požadavků. Odolejme pokušení sortovat na ty, co dělají zadání a na ty, co podle zadání dělají konstrukci. Jsme jeden tým. Pokud můžeme, posaďme zákazníka, analytika, programátora, testera a další lidi do jedné kanceláře. Nebo je propojme nějakým efektivním komunikačním kanálem. Potřebujeme dobrou komunikaci, rychlou zpětnou vazbu a rychlé zapracování změn.

Zrovna dodělávám kompletní specifikaci

Projektový manažer: “Výborně Karle, ta specifikace vypadá neprůstřelně, teď to necháme kluky naestimovat a můžeme podepsat smlouvu.”

Pokusy vytvořit kompletní specifikaci ještě před konstrukcí (up-front) možná fungují u malých věcí nebo u opakujících se podobných projektů. Často ale ani tam. U větších věcí s vysokým stupněm inovace a nejistoty jsou ale podobné ambice tvrdě trestány. Navýšením nákladů a frustrací ze zbytečné práce, kterou musíme často zahodit. Rigidní vodopádová snaha zakonzervovat požadavky je často naivní obranou proti neschopnosti efektivně provádět změny během konstrukce. A nebo je důsledkem striktní smlouvy o dílo, kde zákazník raději vsadí na jistotu “dodání funkcionality v požadovaném rozsahu”.

Buďme připraveni na změnu. Mějme na paměti celek, ale rozdělujme na podproblémy. Specifikujme vysokoúrovňové business požadavky. Analyzujme je podle priority a rozpracujme do podrobnějších produktových požadavků ve formě user stories. Prioritizované user stories nám vytvoří produktový backlog. User story ale zatím není zadání, na které čeká programátor. Je to pouze placeholder pro následnou detailní specifikaci.

Když se na user story dostane řada, začíná její detailnější analýza a definice požadavků. Očekávanými výsledky jsou popis chování systému (use cases), upřesnění UI (mock-ups) a nefunkcionální specifikace. Analytik analyzuje problém a navrhuje řešení v úzké spolupráci se zadavatelem. Využívá znalostí a spolupráce dalších rolí v týmu. V případě rizik, omezené znalosti technologií nebo možnosti více konceptů, je prováděno rychlé prototypování. Ty nejrizikovější věci by měly být odprototypovány na začátku projektu.

Dobrou praktikou je vytvoření test cases ještě před vlastní konstrukcí. V této fázi mohou test cases odhalit závažné nedostatky ve specifikaci požadavků a ušetřit tak spoustu peněz v případě pokračování špatným směrem. Pokud tester není schopen napsat kompletní a jednoznačné testovací případy, zřejmě ani programátor nebude schopen efektivní implementace. Zkušený tester prokoukne nedefinované alternativní větve, chybějící podmínky nebo neošetřené chybové stavy. Často jsou v detailech ukryta závažná projektový rizika.

Nevíte někdo, jak to funguje?

Analytik: “Omlouvám se za hromadný email na všechny lidi ve firmě, ale nemůžu najít specifikaci business pravidel pro XY. Poradí mi někdo, prosím?”

Odpověď A: “Aleši, to by mě taky zajímalo, až to zjistíš, dej mně prosím vědět.”

Odpověď B: “Zkus složku SpecABC, jsou tam nějaké staré wordy. Kdyby to nebylo tam, tak něco možná bude na naší wiki. Jinak dělal to Lojza a ten už ve firmě není. Jak asi víš, z těch přesčasů mu nakonec hráblo. Pokud to nenajdeš, budeš to muset pochopit z kódu. Ale to ti fakt nezávidím. :)”

Na začátku každého projektu vše vypadá krásně a růžově. Lidé jsou nadšení. Všichni zúčastnění vědí o projektu téměř všechno. Nějaká specifikace možná existuje, ale její správě a aktualizaci se často nevěnuje příliš velká pozornost. Požadovaná funkcionalita se dodává rychle, všechno klape a management se poplácává po zádech. Všichni jsou happy.

Projekt roste, vyvíjí se, nová funkcionalita přibývá a stávající se mění, noví lidé přicházejí, původní odcházejí. Je nutná specializace, komplexita systému je už příliš vysoká. Začínají se zvyšovat náklady na správu všech projektových artefaktů. Kde máme aktuální informace? Co všechno se musí upravit kvůli novému požadavku? Jaká jsou rizika? Co vlastně máme před releasem otestovat?

Špatné nakládání se specifikací systému je jednou z nejrizikovějších forem softwarového technického dluhu. Členové týmu zdlouhavě dohledávají informace, dělají špatná rozhodnutí na základě nesprávných informací, vznikají duplicity, zvyšuje se chybovost, management je pod tlakem a přehazuje lidi podle toho, kde to nejvíce hoří. Lidé nemají možnost dělat práci kvalitně a proto frustrovaně odcházejí. Někdy může situaci dospět až k tomu, že údržba projektu je tak drahá, že se už dále nevyplácí a projekt je ukončen. Poslední ať zhasne.

Začněme správu požadavků řešit co nejdříve. Celý proces musí být co nejefektivnější a nejjednodušší. Složité postupy nefungují. Zde je přehled Requirement Management Software. Pokud máte s nějakým systémem větší zkušenost a můžete jej doporučit, přidejte prosím komentář.

Výkonný systém s intuitivním UI

Programátor: Arnošt mi zase poslal zadání, ve kterém píše “vytvořit dostatečně výkonný modul s intuitivním ovládáním, podobný tomu z loňska, ale upravený pro letošní administrativu”. Jdu ho intuitivním způsobem poslat k šípku, podobně jako loni.

Jak psát efektivně požadavky je popsáno v Writing Quality Requirements. Je to už sice hodně vousatý článek, ale přehledně shrnuje to nejdůležitější. Čemu se máme vyvarovat a na co se zaměřit. Jedná se o povinné čtení pro všechny vývojáře software.

Podobně jako jsme zvyklí revidovat kód, abychom našli problémy a sdíleli znalosti o implementaci, můžeme revidovat i požadavky. Analytik musí vysvětlit své chápání problému a důvody proč navrhl toto řešení. Pár tipů na review najdete v How to Conduct a Requirements Review.

Dobrý business analytik je vyladěnou kombinací doménových znalostí a analytických dovedností, viz. např. What Business Analyst Skills are Important. Ty je potřeba neustále procvičovat a vylepšovat. Jak rozvíjíte BA ve vašem týmu?

Shrnutí

Dobře definované požadavky na systém jsou prvním zásadním krokem pro kvalitní výsledek snažení celého týmu. Nesnažme se však všechno vymyslet a popsat hned na začátku. Riziko špatné specifikace je příliš vysoké. Změny pak budou bolet mnohem víc než při postupném iterativním vývoji.

Chápejme proces specifikace systému jako spolupráci celého týmu. Nechtějme programátory-opičky, kteří dostanou přesné zadání a jen klepou. To nefunguje. Chceme myslící bytosti, s určitou znalostí domény, aktivně zapojené do procesu vytváření software.

Specifikace je živá interaktivní dokumentace, která se musí efektivně udržovat po celou dobu života projektu. Úroky za macešský přístup k požadavkům jsou totiž příliš vysoké.

Podělíte se s námi o to, jak se daří spravovat požadavky u Vašeho projektu? Díky.

sobota 23. května 2015

Programátore, chceme tě mít on-site

"Po nějaké době je možné dohodnout částečný home-office"
"Projekt je krátkodobý proto klient vyžaduje on-site"

Ach jo, píše se rok 2015 a většina IT firem u nás stále není mentálně připravena a aktivně nepodporuje remote work. Vidí spásu v tom, že budou mít všechny ovečky pěkně pohromadě v budově, do které investovaly velké peníze. Ztrácejí tak možnost spolupracovat s lidmi, kteří mají odbornost, dostatek sebekontroly a požadovaný výsledek by mohli dodat dříve a ve vyšší kvalitě.

Proč? Většina projektů v IT se zpožďuje, prodražuje se a původní estimace, pracně vytřepané z rukávu a několikrát pozměněné, se nám ve finále smějou do očí. Představa, že budou muset vysvětlovat vyšší náklady na projekt a ještě fakt, že tým pracoval remote, mnoho projekťáků děsí. Nebudeme si proto komplikovat situaci, co říkáte?

"Práce remote není pro každého." Pro koho tedy není? Pro někoho, kdo při on-site na rozdíl od remote odvádí výsledky? Aha, takže pracuje dobře jen pod dohledem nadřízeného. Chcete takového kolegu?

"Jak mám jako vedoucí sledovat progres remote týmu?" A jak jej sleduješ u on-site? Efektivní vývojové metodologie nejsou nijak zásadně závislé na tom, jestli transformátory kávy na kód sedí blízko sebe nebo stovky kilometrů. Mnohem více jsou závislé na dobré komunikaci, dostatečné zpětné vazbě a dobrých návycích členů týmu. Zkuste si remote pair work, je to fajn.

"Když já opravdu nevím, co vlastně doma dělá." Dělá to, co je typické pro tvůj tým a firmu. Pokud máš dobře motivované zaměstnance, jste orientovaní na výsledek a kvalitu, bude to dělat i vzdáleně. Prostě pokud ho práce baví, neměj strach. Pokud umíš řídit lidi, poznáš, že někdo do týmu nepatří.

"Komunikace není efektivní, navíc mě pořád ruší zprávy na messengeru". V dnešní době rychlých připojení k internetu a nástrojů pro spolupráci asi nebude problém ve vzdálenosti. Hledej problém někde jinde - v organizaci času a práce, v efektivitě týmových schůzek, ve schopnosti přepnout do distraction-free režimu.

"Lidé, dokonce i programátoři, potřebují trávit společně čas". Tak určitě. Ale kolik vlastně?

Sedí tam hodně programátorů a všichni mají sluchátka, co je to? Open space.

IT firmo, chceš kvalitní lidi nebo je potřebuješ mít hlavně všechny pohromadě?

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é?