Zkušenosti ze zavádění testování

Bude to již skoro dva roky, kdy jsem začal zavádět testování ve firmě (viz článek Největší problémy při zavádění testování). Teď jsem se dostal do stavu, že si potřebuji vše zpětně zhodnotit a posunout to ve firmě zase o kousek dále.

Co se povedlo:

• základní principy a přínosy testování zná v týmu snad každý, každý až na nějaké výjimky již má zkušenosti s napsáním vlastních testů. V tomto ohledu se to rozjíždělo pomaleji než jsem na začátku čekal, trvalo chvíli než se dostavil efekt sněhové koule. Nejdříve jsem psal testy jen já, pak se začali postupně přidávat po jednom další a další až nyní je nás většina. Ovšem samozřejmostí je to pořád jen pro pár lidí. Také pomohlo několik případů, kdy nebylo jiné možnosti než napsaní aut. testů, protože ruční vytváření testovacích dat bylo strašně moc komplikované a zdlouhavé.
• technické řešení resp. podpora pro psaní testů byla již od samého počátku hotová, v průběhu těch dvou let jsem toho zase tolik nemusel přidávat. Naše řešení je postavené nad vlastním frameworkem pro vytváření testovacích dat (viz článek Vytváření testovacích dat), doplněné o některé zajímavé vychytávky pro snadnější psaní testů - Testování webových služeb nebo Plošné vypnutí povinného @Autowired.
• téma testování se začíná ve firmě prosazovat, nejen ve vývoji, ale zejména v konzultantské části firmy. V tomto ohledu také nastává posun z manažerského pohledu - ze začátku bylo testování, dle mého názoru, podporováno hlavně kvůli tomu, že o tom hodně lidí mluvilo, a že jsem byl schopen říci jak s testováním začít, jak to celé uchopit. Nyní je to spíše o snaze celé testování více zefektivnit, případně začít více měřit. Je tedy např. snaha o lepší spolupráci mezi konzultanty (zadavateli úkolů) a vývojáři tak, aby již zadání obsahovalo podpůrné informace pro co nejefektivnější psaní unit testů, které by ve výsledku měli ulevit právě konzultantům.
• testy jsou součástí automatického buildu

Co se nepovedlo:

• stále jsou zarytí jedinci, kteří testování "odolávají". Neustálá argumentace a úsilí mě celkem vyčerpává, ale je to vlastně má jediná zbraň, takže musím vydržet
• bylo ode mě na začátku celkem naivní si myslet, že když někdo "prasí" produkční kód, tak testy na tom budou lépe. Spíše naopak. Testy jsou prostě považovány za něco "méně kvalitního", co nepotřebuje komentáře, vše se může psát bez nějaké struktury pod sebe. Tento bod nesouvisí nejen s testy, ale je to spíše úkol pro celý tým - používat a dodržovat konvence pro psaní zdrojového kódu.
• unit testy fungují víceméně jako nástroj vývojáře, aby si svůj kód alespoň párkrát spustil a ověřil, že to plus mínus funguje. Z mého pohledu je potřeba zlepšit předávané informace od konzultantů, aby již v zadání úkolů byly uvedeny informace na co je vhodné se během testování zaměřit tak, aby to v konečném důsledku pomohlo nejen vývojářům, ale i konzultantům, kteří to vše musí převzít a sami ověřit, že je implementace správná.
• chybí nám měřitelná zpětná vazba, neumíme říci, že díky pokrytí určité části testy se zlepšila chybovost o tolik a tolik. Neumíme říci, zda vynaložený čas na psaní testů je v konečném důsledku opravdu přínosem nebo není. Já jako vývojář vím o hodně výhodách a bez testů si to už nedovedu představit, ale má podobný názor i vedení? Obávám se, že zatím ne.
• od začátku jsme chtěli, aby se testy co nejvíce efektivně, tj. psát testy jen k tomu, kde to má přidanou hodnotu. Vymysleli jsme to tak, že každý kdo bude chtít psát nějaké testy, tak přijde za mnou a zkusí mě přesvědčit, že daný test má smysl. Na první pohled dobrý nápad, ale ve výsledku špatné - potřebovali jsme motivovat vývojáře ke psaní testů a ne jim házet klacky pod nohy. Od tohoto jsme postupně opustili, bohužel zase mám někdy pocit, že některé testy mi nepřijdou moc efektivní. Ale asi je lepší mít více testů než méně.

Co dále v nejbližší době?

• v rámci code review se více zaměřím právě na testy
• chtěl bych zlepšit dokumentaci testů resp. JavaDoc testů. Jsem toho názoru, že každý by měl umět před implementací metody popsat, co daná metoda bude dělat. Pokud toho není schopen, pak vlastně přesně neví, co daná metoda má dělat. To samé platí o testech - každý si musí před každým testem říci, co chce testovat, jaké budou vstupy a jaké očekávané výstupy. Zde bych to chtěl nějak standardizovat, ale ještě nevím jak - nějaká jednotná JavaDoc šablona nebo nějak úplně jinak? Budu rád za nápady, jak se to řeší jinde.
• musím zrychlit běh testů na build serveru. Je pravda, že build server je přetížený, ale i tak je hodně, pokud nám celý build včetně všech testů běží skoro hodinu. Zpětná vazba musí být rychlejší. (pozn: máme cca 700 tabulek, k tomu odpovídající Hibernate entity, které se musí vždy všechny inicializovat. Dokončení modularizace aplikace s možností vypnutí/zapnutí modulů bude až tak příští rok). Zde by možná mohl pomoci systém agentů, který znám z TeamCity. Nebo vhodně definovat testovací profily a pouštět to na více strojích vždy pouze s daným profilem.

Proč nechci použít Hibernate na dalším projektu

Minulý týden se mě kolega zeptal, zda bych použil znovu Hibernate na dalším projektu? Já jsem mu po krátkém zamyšlení řekl, že již ne, že bych Hibernate (a obecně žádné jiné ORM řešení) nepoužil. Následovala diskuze, kde jsem se snažil obhájit mojí odpověď:

• ORM nástroje se snaží vývojáře odstínit od konkrétního úložiště dat, snaží se vývojáře držet pouze v objektovém světě bez ohledu na to, že nejčastěji ukládáme data do relačních databází. Je naivní si myslet, že napíši kvalitní aplikaci bez znalostí databází a SQL.
  
  
• ORM nástroje (pozn. konkrétně Hibernate, protože s ním několik let pracuji, ale myslím si, že to lze zobecnit pro všechny ORM nástroje) přidávají do projektů další velkou složitost, nároky na znalosti a zkušenosti. Toto má vliv na spoustu dalších věcí - výběr vhodných lidí do týmu, architektura systému, větší pravděpodobnost chyb, plnění termínů atd.
  
  
• znalost SQL mi přijde natolik rozšířená a základní, že v tomto nevidím další znalostí zátěž pro vývojáře
  
  
• používání ORM odstiňuje vývojáře od přímé práce s databází, což často vede k tomu, že vývojáři vůbec vlastně nevědí, jak jsou určité operace náročné, kolik se vlastně výsledně musí zavolat SQL dotazů, aby se jedna Hibernate operace vykonala
  
  
• Hibernate přináší do vývojového týmu prvek náhodnosti, špatné říditelnosti - pokud vím, že mám napsat 3 dotazy přes JDBC, tak je to tak jasná a ohraničená věc, že není co dalšího řešit. Místo toho implementovat DAO pomocí Hibernatu, to moc jasné být nemusí - nikdy člověk neví, na čem se může zaseknout nebo jak se bude Hibernate v určitých kritických stavech chovat.
  
  
• při porovnávání JDBC vs. ORM přístupů je potřeba také zmínit, že databáze často mnohonásobně přežijí aplikace, které je využívají. Technologie pro server a klienta se mění mnohem rychleji než relační databáze a jazyk SQL. Z tohoto pohledu je základem správný návrh databáze bez ohledu na to, jakou architekturu pak aplikace bude mít.
  
  
• kolikrát se na projektu měnila databáze? Možná lepší otázka - stalo se již někomu, že se během projektu měnila databáze? Když pominu vývoj aplikací pro více databází, tak naopak si myslím, že napojení na konkrétní databázi mi nabízí mnohem více než když jsem odstíněný přes ORM.
  
  
• ladění složitějších HQL nebo Criteria dotazů moc nejde a já osobně jsem vždy skončil u SQL. Někdy postupuji i naopak - pomocí SQL si vyzkouším, že daný dotaz je možné vytvořit, a že je správný a pak ho přepisuji pomocí Hibernatu.
  

Myslím, že nejsem sám, kdo má dnes podobný názor k této problematice jako já, viz např. článek Problems with ORMs jako jeden z nich.

Základní otázkou ale zůstává, co tedy jiného místo toho? Mě zde bohužel chybí osobní zkušenost, ale určitě bych se vydal cestou přes JDBC, tedy jako vhodné řešení mi přijde použití MyBatis nebo Spring JDBC nebo Spring Data nebo to celé nějak zkombinovat dohromady.

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.

Co vybrat na klienta? Konec prvního kola

Vítězem prvního kola se stal .Net, i když i GWT budeme chtít využít.

Jako první volbu pro přepis našich stávajících aplikací použijeme .Net platformu. To je zatím jedno jasné rozhodnutí, na kterém jsme se domluvili, a které nám dává smysl. Hned příští měsíc si v tom vyzkoušíme napsat jednu zcela novou aplikaci, abychom nabrali zkušenosti a získali cennou zpětnou vazbu.

Mezi hlavní argumenty pro .Net patří tyto:

• možnost výběru cílové podoby aplikace (za splnění určitých podmínek během vývoje) - standalone aplikace vs. webová aplikace Silverlight
  
• naši zákazníci jsou zvyklý na velký uživatelský komfort z našich stávajících aplikací, toto musíme i nadále dodržet
  
• chceme řešit vývoj aplikací, ne řešit detaily GUI pro různé prohlížeče
  
• většina vývojářů, kteří nyní dělali v Delphi, chtějí spíše .Net než něco jiného. Preferujeme know-how kolem řešené problematiky, než znalost samotné technologie.
  

Nicméně i GWT (asi) nezůstane stranou. Existuje spoustu oblastí a problémů, které není vhodné řešit jen .Net platformou, Silverlight je pro spoustu webových řešení těžkopádné a nevhodné. Proto mi dává smysl mít na výběr - buď .Net platformu pro naše produkty a nebo "čisté" webové řešení jako např. GWT nebo i třeba i něco jiného (zde ještě nemáme zcela jasno).

Firma má know-how jak ve vývoji tlustých klientů, tak i čistě webových projektů, proto mi přijde vhodné tohoto dále využít a stanovit pro firmu dvě nosné technologie. Navíc je to i slušná konkurenční výhoda, umět použít technologii podle zadání projektu a ne podle interních možností.