84. Design Patterns Jiří Mareš ( [email_address] , jirablog.blogspot.com ) ČSAD SVT Praha s.r.o. ( www.svt.cz )
Notas do Editor
Na škole jsem se o vývoji moc nedozvěděl, naučil jsem se programovat Začínal jsem hekticky Dneska už máme řadu věcí pod plnou kontrolou
Dneska: děláme generování dokladů, jejich započtení a finanční vyrovnání Web pro vlastníky karet Statistická data na základě linek a spojů A chystají se dokonce znalost linek a rekonstrukce cesty jednotlivých cestujících
Peněženky jsou jednoduché, ale hlídají se (zajímavé je přehazování pořadí transakcí díky špatnému času v zařízeních) Zařízení jsou offline – možná ztráta dat Různé aplikace, kupón – různé algoritmy rozúčtování Uzávěrka, bilance, faktury, grafy - ukázka
SaaS – pokud stačí webové rozhraní, pak je to ideální přístup - jednoduchá distribuce nových verzí, všichni používají nejposlednější verzi - v dnešní době Google a Amazon cloudu je vše ještě jednodušší Co nejjednodušší architektura – největším problémem velkých dlouhotrvajících projektů – overengineering Failover – DB máme - aplikační server - bude
Existuje již druhá revize, tj. Přepsání kódu, pomalu se chystáme na třetí, to už bude spíš evoluce než revoluce V 1614 java souborech je 342932 řádků kódu V 988 xml souborech je 188210 řádků V 180 jsp souborech je 14080 řádků Ošklivé slovo, ale používáme Javu, groovy, shellové skripty, XSLT, XSL-FO, Javascript … Testování má poměrně vysokou prioritu, navíc se jedná o výkladní skříň společnosti na spolehlivost klademe velkou váhu
Podstatné je, že se spustí triviální aplikace a nabaluje se funkcionalita, testy, průběžně se vytváří uživatelská dokumentace … Ve scrumu jde o zatáhnutí vývojářů do dění – jsou spoluzodpovědní, sami se rozhodují, sami určují co budou dělat, jak Navíc pokud je zákazník otevřený, pak se nechá domluvit, že kdykoliv bude mít pocit, že má vše co potřebuje, může projekt stopnout a dostat 70% neutracených peněz
Číslo je důležité, neseme jej napříč celým procesem vývoje Plánování je velmi jednoduché – každý vývojář má přehled co má řešit, co může řešit, co má jakou prioritu Reportování Ukázky 003 - 007
Podporuje distribuované buildy Automatizovaný build ant, gradle (i maven) - gradle – super jako maven, ale více deterministický - build script je v groovy, tj. Méně ukecaný než mavení XML Hudson – 008 - 013
Okamžitý přístup ke zdojákům, jak pro ostatní vývojáře, tak pro CI server – samozřejmostí je vzdálený přístup Historie změn – hodně důležité, víte kdy se co, jak změnilo a kdo změnu udělal Větvení – zkoušení nových věcí, opravy chyb do starších verzí Tagování – dokážete se jednoznačně odkázat na stav projektu v určitou dobu
Test – co nejjednodušší Refactoring – bez testu nemozny (jak refactorovat když nejsou testy) Ukázat použití DI – transaction DAO Guice je hezčí, protože není řízem XML, ale kódem … Junit 3 měl problém s pamětí -> přechod k TestNG - data provider DisjointIntervalComparatorTest – postaru … VatTest .. realVat_scale .. data provider Jde jednoduse kombinovat vice komparatoru Mock objekt – easy mock podporuje refactoring - DeviceFacadeTest
- testy se naklikat dají, ale musí se opravit, protože změna UI vyžaduje změnu testu, vhodné správně volit výběr elementů stránky, opět se musí stránka vyvíjet s ohledem na testovatelnost - pouštíme testy oproti VMWARE serveru, automatizovaně - IE má problém s XPath (pomalé)
Vše to běží na Hudsonu, tj. Automaticky - ukázat coverage CardsExchange
Proč? Něco jako pair programming, 2 lidé přemýšlejí nad každým řádkem Ukázka jak děláme review 015-019
020 – ukázka Contract4j PMD pracuje na zdrojákem, duplicitni kod Checkstyle opet pracuje nad zdrojakem Máme vrstvit (Model, DAO, Facade, UI) - ne, není to objektové, ale funkcionální programování - objektové je – metoda tam kde jsou data - problém je s DAO vrstvou – různé implementace a model nezajímá, která je použitá??
Ukázka javadoc v Utilu UML ukázka Ukázka DB Ukázka unit testu, který říká jak věc použít
- multilingual – zvětšuje přehled a vylepšuje kódování, protože dobré prvky z jednoho jazyka zanášíme do druhého