Programátoři jsou největší lháři

V nadpise dnešního článku cituji mého kamaráda, který začal pracovat jako project manager v softwarové společnosti, a který hlavně dosud většinu svého profesního života pracoval mimo jakýkoliv softwarový vývoj. Zřejmě zvyklý z jiných oborů, kde člověk na první pohled vidí, v jakém stavu je projekt, tak zde asi celkem narazil, protože dost často se během vývoje musí člověk spoléhat na to, co řeknou programátoři. A ze své zkušenosti vím, že odpověď na stav řešeného problému vždy vypadá hodně podobně - "Mám to už skoro hotové, jen musím ještě něco dodělat". Smutné je, že tato odpověď má většinou několik pokračování, kdy zní skoro stejně, jen se přidávají další přídavná jména a příslovce, aby to vypadalo, že už se konec opravdu blíží - "Myslím, že teď už budu mít skutečně většinu hotovou, jen ještě dopsat testy, ale to už je opravdu drobnost a neměl by to být žádný problém".

Je pravda, že každý project manager chce mít pocit, že má vše pod kontrolou, a že projekt postupuje podle plánu. Co ale určitě nemá rád, když dostává špatné a nepřesné informace - pak je nejistý, neví, zvláště když to není project manager, který si sám prošel vývojem. Nejhorší úplně je, když se programátor celou dobu tváří, že "žádný problém" a pár dní před koncem se zjistí, že se to nestihne.

Programátor má často mylný pocit, že bude "špatný" programátor, když řekne přesně stav věci, když snad přizná, že něco nejde podle plánu. Pokud programátor pracuje jak má a vždy říká věci jak jsou, tak se nikdy nemusí bát, že by on byl snad ten špatný. Programování je hodně o přemýšlení, o nalézání nových cestiček, o zkoušení nepoznaného, proto se prostě musí počítat s tím, že vždy vše nepůjde podle plánu. Ale je potřeba to říkát, komunikovat! Jeden kamarád hezky vyjádřil vývoj softwaru jako "interaktivní hru mezi vývojovým týmem a zákazníkem", kde komunikace a přímé jednání jsou nezbytností pro úspěch projektu.

Programátoři (zejména ti mladší) se hodně ženou po technologiích se snahou mít co nejvíce "buzzwords" ve svém životopise. Je pravda, že toto určitě zaujme, ale z pohledu vedení týmu bych často preferoval zcela základní lidské vlastnosti:

• přímé jednání, snažím se říkat přesně jak se věci mají
• když řeknu nějaký termín, tak udělám maximum pro jeho dosažení a pokud něco nestíhám, tak na to včas upozorním
• komunikativnost
• být otevřený, mít ochotu se učit novým věcem

Došel jsem k přesvědčení, že si mě firmy najímají kvůli tomu, že jim dokážu pomoci (což neznamená, že to musím vždy dělat já sám). Firmy jsou ochotny nadstandardně zaplatit, pokud mají problém a vy jim dokážete pomoci, ale vždy za předpokladu, že "co řeknete, tak to platí". Firma má často problémy se svými zaměstnanci a nemá vůbec potřebu využívat externistu, který jí nepřináší maximální užitek.

Vybrat JasperReports nebo BIRT reports?

Potřebuji se rozhodnout, jaké řešení na reporty vybrat a pořád nevím. Nějaké porovnání těchto nástrojů jsem již uváděl na mém blogu, ale již je to skoro tři roky zpátky a od té doby se mnoho věcí určitě změnilo.

Pořád si myslím, že volba je mezi JasperReports a BIRT reports. Našel jsem další možnosti jako Pentaho Reporting, Crystal Reports nebo NextReports, ale žádné z těchto řešení mě moc nezaujalo.

Já osobně žádné pokročilé funkce od nástroje neočekávám, spíše ty základní:

• reporty budou primárně zobrazeny na webové stránce
• export do PDF, XLS je nutností
• absolutní většina reportů bude statických, tedy uživatel klikne na odkaz a zobrazí se mu určitý report. Žádná velká interakce uživatele při zobrazování reportu nebude.

Můj favorit je JasperReports, ale asi jen díky nějakým subjektivním důvodům:

• JaspeReports je tu už dlouho a již od nějaké 1.x verze Springu je součástí standardní podpory. Takže Spring nabízí podporu na podobné úrovni jako jiné prezentační frameworky jako Freemarker, Velocity atd.
• velká komunita a rozsáhlá dokumentace (z uvedených nástrojů nejlepší)
• myšlenka kolem JasperReports Serveru mi přijde zajímavá a bez většího úsilí nabízí velkou přidanou hodnotu

Moc pěkné srovnání je v článku BIRT, Jasper, Pentaho - Comparison Matrix nebo v článcích JasperReports, případně BIRT Vs Jasper Report A Comparitive Study.

Jaké máte prosím zkušenosti vy?

Agile Prague Conference 2011 - ohlédnutí

Ve čtvrtek a v pátek se v Praze konal první ročník konference o agilním přístupu k vývoji - Agile Prague Conference, které jsem se zúčastnil.

Pokud bych měl krátce zhodnotit akci jako takovou, tak moc nevím, co bych ji vytknul - vše probíhalo podle plánu, catering fungoval jak měl, na žádné nedostatky technického rázu jsem nenarazil. Kvalita přednášek a přednášejících byla nadprůměrná - z mého osobního pohledu se mi více líbil pátek a až na jednu hodně slabou přednášku ve čtvrtek jsem byl celkově spokojený. Nejvíce mě zaujaly čtyři "case-study" přednášky českých firem, které se podělili se zkušenostmi se zavaděním agilních metodik u nich ve firmě. Také asi pro mnoho lidí bylo překvapením, že o jednotlivých metodikách se skoro vůbec nemluvilo, vše bylo spíše o důvodech pro agilní vývoj, o organizaci týmů, o zkušenostech ze zavádění agilních přístupů.

Dále nechci procházet jednotlivé přednášky a hodnotit je, chci zmínit zajímavé postřehy a myšlenky, které jsem si odnesl:

• agilní přístup k vývoji má velice úzký vztah ke správné organizaci/struktuře společnosti - pokud chce být firma "agilní", tak musí být agilní celá a ne jen vývojové oddělení a i organizace jako taková tomu musí být přizpůsobena - místo klasické hierarchie šéf - product manager - project manager - tým vytvářet Self Organizing Teams, tj. reorganizovat odpovědnosti na celý tým, podpořit kreativitu a přenést zodpovědnost na všechny členy týmu.
• všechny case-study přednášky se týkaly firem, které mají produkty, takže zákazníkem vývoje jsou interní product manažeři. Hodně by mě zajímal pohled na agilní firmu, které funguje zakázkově pro externí zákazníky (a ještě navíc pro státní sektor)
• došel jsem k názoru, že pro úspěšné zavedení agilních metodik je nezbytné využití externího konzultanta, který díky tomu, že je externí, má mnohem lepší přesvědčovací pozici než interní vedení. Nejčastějším přístupem lidí při zavádění agilních přístupů je, že říkají, že to nebude fungovat, že my máme něco speciálního, co jinde nemají a proto to zde nemůže fungovat. Toto dost často externí člověk může vyvrátit.
• dále mi přišlo velice důležité začínat pilotním týmem/projektem, protože ve všech firmách, které své zkušenosti prezentovali, byla skladba lidí před zaváděním přibližně tato - třetina se moc těší, třetině to je jedno a třetina lidí si myslí, že to nemůže fungovat. Pilotní projekt dokáže hodně lidí z poslední skupiny přesvědčit, že to fungovat může.
• stále více se mi líbí Kanban, jako metodika pro vývoj softwaru - jednoduché, názorné, zábavné a "hravé".
• pro mě osobně nový zajímavý pojem Lean software development
• bez osobního potkávání a intenzivní spolupráce to nejde. Pokud chci co nejvíce omezit psaní dokumentace a pokud chci co nejvíce zodpovědnosti přenést na celý tým, pak musím tento tým dát dohromady, na jedno místo. I když preferuji práci na dálku (zejména kvůli mému osobnímu pohodlí), tak sám vím, že je něco úplně jiného mít tým v jedné kanceláři, kde lítají myšlenky vzduchem, kde všichni táhnou za jeden provaz.
• zpětná vazba od zákazníka musí být co nejkratší - pokud chci něco řídit (viz Teorie řízení z kybernetiky), tak kvalita řízení je přímo úměrná kvalitě zpětné vazby. Na jedné přednášce byla prezentována přímá úměra mezi délkou sprchy a nastavením správné teploty vody. Jak trefné :)
• Dnes (snad již) nikdo nevěří tomu, že vodopádový model může efektivně fungovat. Mnoho firem postoupilo o krok dále a praktikují iterativní způsob vývoje a včetně zavedené postupné integrace. To je ale pořád jen víceméně technický posun, ale pokud se nezmění organizace práce, struktura firmy a předání odpovědnosti týmům, pak není možné se bavit o agilním způsobu vývoje.
• Líbila se mi přednáška, kde přednášející trefně říkal, že dlouhá léta se softwarové inženýrství snažilo okoukávat přístup k vývoji a řešení problémů od průmyslu, který tu už přes sto let byl a dobře fungoval. Až nyní v poslední době se ukázalo, že vývoj softwaru potřebuje zcela něco jiného.

A nakonec přidám ještě pár hesel, které mě zaujaly:

• Vždy bude více požadavků než jaké jsou možnosti realizace - nutná prioritizace požadavků, čím kratší a rychlejší zpětná vazba, tím lepší.
• Častěji bych se měl ptát, zda dělám správnou věc než zda dělám danou věc správně.
• Posunu resp. zlepšení není možné dosáhnout beze změn.
• "When in doubt, leave it out" - pokud si nejsme jisti při výběru a návrhu nějaké nové funkce, tak to raději nechme ať zákazník sám řekne, jak a co chce.
• Kvalitní zpětná vazba od zákazníka není možná bez kvalitní komunikace s ním.
• Čím jednoduší je architektura celého systému, tím rychlejší je přidávání nových vlastností do systému. I proto refaktoring je tolik důležitý.
• Realita se mění, to je realita. Pokud chci vytvářet reálnou aplikaci, pak musím být na každodenní změny připravený.
• Kód píšeme kvůli tomu, že ho ještě nikdo jiný před námi nenapsal. Pokud již někdo napsal, pak není důvod to psát znovu.

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.