Dostal jsme dotaz, jak si poradit s odstraňováním chyb u starší a rozsáhlé aplikace. Když jsem odepisoval, uvědomil jsem si, že sepisuju jakési “triviální  desatero vývoje”", které se snažím už dlouhou dobu svému okolí vtloukat dohlavy. I když jde o triviální zásady, budu příště odkazovat raději na tento příspěvek, než abych vše opakoval pokaždé znovu. Jméno firmy je v textu nahrazenou souslovím “anonymní firma”.

“Zdravím,
to je na hodně dlouhý příspěvek.
Alespoň tedy:

1) Je nutné zrušit umělou hranici mezi vývojáři a testery. Žádná výměna informací přes šéfy oddělení nebo pověřené osoby.

2) Na každou objevenou chybu musí být napsán automatický test, který zajistí, že chyba neprobublá do dalších releasů. Bez toho žádné organizační opatření nefunguje. Bez napsaného testu se chyba nepovažuje za odstraněnou, ale jen za náhodou se nyní neprojevující.

3) Vytvořit malé sebeorganizující týmy odpovědné za určitou část projektu (nastálo, nebo do dalšího releasu). V čele team leader, který garantuje kvalitu. Team leader je k dispozici i testerům a řeší nesrovnalosti v analýze a systémovém designu. S dalšími team leadery řeší problémy integrace různých částí projektu. Team leader ale stále většinu času kóduje, není to embryo vychovávané pro střední management.

4) Je potřeba postupně napsat velké množství automatických testů (unit, integrační, akceptační) tak, aby se testeři věnovali hlavně novým záležitostem v releasu a aby vývojáři ani testeři nebyli obětí "ručně prováděných" regresních testů, které mají formu nikdy nekončícího debugování. Tím se i zkrátí doba, kterou "anonymní firma" nutně musí trávit opakovaným debugováním a "ručním" nalézáním příčin chyb. Automatizované testy představují práci, která se na projektech vyplatí, a navíc jde i o mnohem levnější řešení problému, než nabírání dalších a dalších testerů.

5) Nedávat žádné fixní odhady na odstranění chyb ani nikoho exkluzivně nealokovat jen na odstraňování chyb. Vývojář není a přes různé manažerské poučky ani nebude anonymní zdroj, který sebereme z jiného projektu, posadíme k aplikaci, kterou nezná, ale u které dostane befelem, že za jednu normohodinu musí odstranit 20 bugů. Tato kouzla fungují jenom v Excelu. V reálném světě vývojář těch 20 bugů neodstraní, ani když ho posadíte do open space, který  je oblepen motivačním majstrštykem vytisknutým z PowerPointu nejlepším absolventem MBA.

Pokud se objeví chyba, chopí se jí člověk, který za danou oblast odpovídá (konflikty přinejhorším vyřeší team leadeři). Vývojář neustále čte a refaktorizuje kód, pokud možno ihned také odstraňuje chyby . A jsme opět u testů - dokud ty automatizované testy mít nebudete, vývojáři do kódu raději nezasahují, protože nevědí, kde všude se změna projeví a raději neriskují další možnou příčinu pádu aplikace po nasazení u zákazníka. A psát použitelné, ne jen formální-švejkovské testy, kdy se hodnotí "jen code coverage", se musí všichni vývojáři naučit a nějakou dobu to zabere.

Mám zkušenost s 12 let starou aplikací psanou původně pro VB, poté čátečně přepsanou na .Net Framework,  která byla po 9 letech postupně obalena testy, a ani dnes sice nejde o žádnou vývojářskou lahůdku, ale pracuje se na ní beze strachu, co při každé změně v aplikaci zničíme. Nic jiného než to, co píšu výše, se mi neosvědčilo.

A pak další záležitosti jako (nutné) bonbonky:

• Neztrácet čas “mergováním” změn v něčem tak zastaralém a nepohodlném jako je Subversion. V Mercurialu (GITu) je propagace změn z vývojové větve do hlavní (a zpět) otázka chvíle. V Subversion ani TFS jsem po pár zkušenostech raději moc "branchů" nedělal.
  
• Automatické buildy spojené s již napsanými testy.
  
• Automatické nasazení nové verze aplikace, aby testeři nemuseli pátrat, kde seženou novou verzi a také, aby nasazení do produkčního prostředí neznamenalo 3denní práci party lidí, kteří se metodou pokus-omyl snaží dostat aplikaci do použitelného stavu u zákazníka.
  
• Alespoň u nováčků code review, abyste rychle odstranili jejich špatné návyky.
  
• Statická analýza kódu.

A dovolím si jednu soukromou poznámku k "anonymní firmě" - pokud možno zredukovat/vyhodit všechny těžkotonážní, neskutečně drahé a pro vývojáře zabijácké nápady se zavedením nejhorší možné formy vodopádu  - analýza->samostatný systémový design->vývoj->testy, v jehož bludném pádu se bude produkovat množství dokumentů, navíc rychlokvašenými analytiky/designery, v mizerné kvalitě a bez vazby na skutečné potřeby projektu. Analýza a systémový design jsou fáze projektu, které pomáhají jen do doby, než se jich chytí nějaký exot, který nikdy žádnou aplikaci nevyvíjel a který si myslí, že analytická práce spočívá ve štosování nahodilých myšlenek zákazníka do příslušné šablony pro use case. Což je dle mých zkušeností většina “čistých”, míněno vývojem nedotčených, analytiků na pracovním trhu.

Opět vás všechny zvu na pravidelný podzimní běh kurzů Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a Pokročilé návrhové vzory a objektové principy 2.

Novinkou v tomto roce je kurz pro začátečníky nazvaný Základy objektově orientovaného návrhu a vývoje. Někteří z vás ho mohli během posledních dvou let absolvovat ve formě inhouse kurzu pod interním názvem UML 0.  Kurz UML 0 vznikl velmi spontánně jako reakce na požadavky některých firem, které nechtěly rovnou absolvovat stávající kurzy. Nyní je vycizelované UML 0 dostupné i jako veřejný kurz, protože v emailech se opakovaly žádosti o jeho veřejnou formu od lidí, kteří kurz absolvovali a nyní na něj chtěli poslat své kolegy.

O tomto novém kurzu naleznete podrobné informace níže v této pozvánce. Znovu opakuji, že se jedná o kurz pro začátečníky, který dříve v nabídce nebyl, protože kurzy Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a Pokročilé návrhové vzory a objektové principy 2 byly a stále jsou určeny pro lidi, kteří základy znají. Nenechte se ale zmást “kódovým” názvem nového kurzu (UML 0), účastníci bývají překvapeni, že s UML na kurzu zacházíme zcela pragmaticky a bez  posvátné úcty, ale i bez módních předsudků a rychlých odsudků. UML bereme jako nástroj, a ne jako samoúčelný cíl našeho snažení na kurzu.

Veřejný kurz Základy objektově orientovaného návrhu a vývoje (UML 0) 

Datum konání kurzu: 19. 9. – 21. 9. 2011

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

FAQ  - často kladené dotazy ke kurzům

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1

Datum konání kurzu:  10. 10. – 12. 10. 2011

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

Výběr z ohlasů na kurz

FAQ - často kladené dotazy ke kurzům

Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 2

Datum konání kurzu:  24. 10. – 26. 10. 2011

Místo konání:

Školící středisko Tutor

U Půjčovny 2
110 00 Praha 1

Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.

Podrobné informace o kurzu a možnost přihlásit se na kurz

Program kurzu

Výběr z ohlasů na kurzy

FAQ - často kladené dotazy ke kurzům

Program nového kurzu Základy objektově orientovaného návrhu a vývoje (UML 0)

Předpokládané znalosti účastníků

1. Základní přehled o etapách vývoje projektu.
   
2. Vhodné je mít nějaké vlastní zkušenosti z analýzy a vývoje projektů, abychom mohli porovnat různé postupy a doporučení a jejich použitelnost v praxi.
   
3. Chuť se učit.;) Schopnost pohlédnout na některá domněle známá témata bez předsudků.
   
4. Částečná znalost UML je vhodná, ale u tohoto kurzu není vyžadována. Vhodná je hlavně pro konfrontaci vlastních zkušeností s tím, co zazní o použitelnosti různých částí UML na kurzu.
   
5. Nenávist ke kariéře zručného "bušiče", nikým nerespektovaného projektového vedoucího (tzv. sekretářky 2.0) a neschopného analytika / vývojáře.
   

Obecné informace ke kurzu

Pro vývojáře se u konstrukcí a prvků jazyka UML, které jsou považovány za analytické, dělají časté odbočky do kódu, aby vývojáři pochopili, že UML ani principy OOP nejsou nějaké nesmyslné abstrakce, ale užitečné konstrukce, které sami v programovacích jazycích používají denně. U role analytika stále zdůrazňuji, jaké znalosti z oblasti vývoje aplikací musí analytik mít, aby byl pro projekt užitečný a nevytvářel jen dokumentaci pro dokumentaci, kterou vývojáři nevyužijí a (až příliš často oprávněně) ji považují  za nesmyslnou, drahou a hlavně  vyvíjenému projektu nic nepřinášející. Kurz je určen pro vývojáře, systémové designery, analytiky a projektové manažery, kteří se chtějí seznámit se základními principy objektového programování a s modelováním v jazyce UML.

Program školení

• Proč má dnes UML v některých kruzích špatnou pověst? Musíte být těžkotonážní rytíři cválající na drahých CASE nástrojích a neživotných formálních projektových metodikách, nebo si vystačíte s nástroji a postupy, které zachytí vaše myšlenky, ale nenutí vás přizpůsobovat se "Jen Tomu Jedinému Pravému Stylu Návrhu A Vývoje"?
  
  
• Dostali jste poptávku, máte za pár dní dodat nabídku a v seznamu svých dovedností nenalézáte jasnovidectví ani nemáte po ruce čarovnou skleněnou kouli, abyste zákazníkovi do nabídky vyvěštili konečnou cenu i datum dokončení projektu? Co dělat v počáteční fázi projektu, kdy ještě ani nevíte, jestli budete projekt vyvíjet?
  
  
• Požadavky na systém. Jak je to s případy užití? Má vlastní zrychlená funkční specifikace bez zbytečných formalit.
  
  
• Rozsáhlé ukázky fukčních specifikací z projektů.
  
  
• Diagram tříd v UML.
  
  
• Rozdíl mezi analytickým diagramem tříd a diagramem tříd vytvářeným ve fázi systémového designu - existuje takový rozdíl, nebo jde jen o další hloupý mýtus?
  
  
• Třída - základní principy OOP, operace, atributy, viditelnost členů třídy.
  
  
• Vztahy mezi elementy diagramu (asociace, agregace, generalizace, závislost, realizace) – vše vykládáno na konkrétních příkladech z praxe + ukázky nejčastějších chyb, se kterými jsem se setkal.
  
  
• Dobře zapamatovatelné principy návrhu známé pod zkratkou SOLID v příkladech. Unit testy, integrační testy, akceptační testy - skutečně si stále myslíte, že se bez nich na projektech obejdete?
  
  
• Nejen SOLIDní principy stojí v pozadí návrhu aplikací...
  
  
• Nenásilný přechod k jednoduchým návrhovým vzorům.
  
  
• Příklady složitých diagramů tříd. Jak je udržovat v souladu s napsaným kódem? A musíme je udržovat? Co se na projektech vyplatí dělat a co projekt spolehlivě zabije?
  
  
• Objektový diagram + příklady.
  
  
• Diagramy a diagramy interakce. Příklady. Typy projektů, pro které se tyto diagramy hodí.
  
  
• Vysvětlení stavových diagramů + výhody aplikací řízených přesně definovanými stavovými automaty.
  
  
• Diagram aktivit - modelování složitých business procesů v organizaci. Hrajete si s diagramem aktivit rádi, ale ocení to Váš zákazník?
  
  
• Vrstvy a moduly v aplikaci – architektura aplikace.
  
  
• Relační a objektový svět? Stále jediné možné partnerství z rozumu?
  
  
• Nasazení aplikace – výklad Component & Deployment diagramů.
  
  
• OOP a jeho vztah UML. Vztah UML a OOP k projektové praxi a realitě.
  
  
• Výhody a nevýhody UML – vyzdvižení nejvíce používaných postupů, odhození nepotřebné veteše z jazyka UML.
  
  
• Odpovědi na dotazy frekventantů kurzu.

Těším se s Vámi na setkání na kurzu!

René Stein