1. Vývoj clearingového systému
CARDS EXCHANGE
a
aplikované nástroje
softwarového inženýra
(www.slideshare.net/jiramares/20101124-matfyz)
Jiří Mareš
ČSAD SVT Praha s.r.o.
24.11.2010
2. Něco o mě
● Vystudoval jsem FEL ČVUT
● 17 let vyvíjím software
● Posledních 8 let v SVT
● V SVT jsem se hodně zaměřil na kvalitu
kódu
Něco o SVT
● Existuje 30 let, od 1991 s.r.o.
● Více než 25 let zkušeností s AMS
● Od roku 2006 držitelem ISO 9001:2000
3. Clearingový systém
CARDS EXCHANGE
● Motivace: umožnění křížového používání
čipových karet mezi dopravci ve
Středočeském kraji s vypočtením objemu
plateb mezi dopravci
● Nyní
– 6 systémů
– 53 subjektů
● el. peněženky, kupóny
4. Clearing CARDS – princip
● Cestující má kartu vydanou subjektem A
● Používá ji u různých subjektů (včetně A)
● Jedná se o platby (el. peněženka) i o
kupóny
● Za měsíc vytvoříme závěrku
● Započteme toky peněz
● Zajistíme převod peněz
5. Clearing CARDS - architektura
● SaaS – Software as a Service
● Webová aplikace
● Žádné EJB
● OS SUSE Linux Enterprise Server
● Aplikační server Apache Tomcat
● Databázový server IBM DB2
● Failover
6. Clearing CARDS
jaký je to SW projekt
● Dlouhodobý – trvá již 7 let
● Velký – 2754 java, 1977 xml, 362 jsp, 157
groovy souborů – cca. 10,5k testů
● Multi-technologický
● Počítáme peníze – spolehlivost má
vysokou prioritu
7. Nástroje SI – metodika vývoje
● Agile (Scrum) - jenom ne vodopád
– Kritické věci se řeší nejdřív
– Zákazník stále vidí kam se vývoj ubírá
– Častá integrace
– Agile & Iterative Developmen / Larman
● U nás
– Hlavní release každý měsíc
– Až 2 další opravné
8. Nástroje SI – evidence požadavků
● Systém JIRA (www.atlassian.com)
– Každý požadavek má číslo
– Evidují se podpožadavky a jiné závislosti
– Plánujeme – kdo, v jakém releasu, s jakou
prioritou
– Víme v jakém stavu každý požadavek je
– Tento přehled má kdokoliv z firmy
– Máme k dispozici různé reporty
9. Nástroje SI – continuous integration
● CI server – u nás Hudson (hudson.dev.java.net)
● Automatizovaný build
● Gradle (gradle.org), Ant (ant.apache.org)
● Nutný version control repository – u nás
Subversion (subversion.tigris.org)
● Často commitovat
● Okamžitě máme binárky na deploy
● Automatizovaný deployment
● Testování
10. Nástroje SI
version control system
● Přístup ke kódu pro všechny
● Historie změn
● Větvení zdrojového kódu
● Tagování - release
● Lepší než CVS (transakční, verzuje i
adresáře)
● Dnes nejlépe hg, git
11. Nástroje SI – unit testy
● Automatizované testování, refactoring
● Návrh kódu s ohledem na otestovatelnost
– Rozumné rozložení kódu
– Dependency Injection
● Guice (code.google.com/p/google-guice/)
● Spring (www.springsource.org)
● Používáme TestNG (testng.org)
● ne jUnit (www.junit.org),
Hamcrest (code.google.com/p/hamcrest/)
● Mock objekty – easymock (www.easymock.org)
● mockito(code.google.com/p/mockito/)
12. Nástroje SI – integrační testy
● Webová aplikace – Selenium (seleniumhq.org)
● Testy se dají de facto naklikat
(SeleniumIDE) – problém se selektory
● Testy se dají spustit na různých OS i v
různých prohlížečích (díky VMWare
pouštíme v noci oproti Firefoxu i IE vs.
Linuxu i Windows)
13. Nástroje SI – code coverage
● Použitelné pro kontrolu testů
● Představa, jak moc je otestováno
● 100% coverage není záruka
14. Nástroje SI – code review
● Proč?
– Víc očí víc vidí
– Víc mozků tomu rozumí
– Předávání zkušeností
– Neopakovat se
● Záruka kvality
● Děláme review každého nového kódu
podle požadavků v systému JIRA
15. Nástroje SI – kvalita kódu
● Design by Contract – Contract4j
(www.contract4j.org)
● FindBugs (findbugs.sourceforge.net)
● PMD (pmd.sourceforge.net)
● Checkstyle (checkstyle.sourceforge.net)
● Vrstvení aplikace vs. kód je tam kde jsou
data
16. Nástroje SI - dokumentace
● Dokumentace neodpovídá skutečnosti
● Kód je dokumentace - generování
dokumentace z kódu
– Javadoc
– UMLGraph (www.umlgraph.org)
– SchemaSPY (schemaspy.sourceforge.net)
– Unit testy
17. Nástroje SI
to celé nejenom v Javě
● Používáme HTML, CSS
● XML + XSLT + XSL-FO
– Fop (xmlgraphics.apache.org/fop/)
– iText (itextpdf.com)
● Groovy (groovy.codehaus.org)
● JavaScript
– jQuery (jquery.com)
18. Nástroje SI – proč opensource
● Mám zdrojáky
– Mohu zjistit jak funguje
– Mohu fungování změnit (opravit)
● Vrátit zpět něco komunitě pomocí patchů
● Neplatím, ale občas problém s licencí
19. Nástroje SI – vlastní hlava
● Se učit, se učit, se učit
● Kolik jazyků umíš tolikrát jsi programátorem
● Nové jazyky = nové finty
● Hackathon (wikipedia.org/wiki/Hackathon)
20. Děkuji za pozornost
● The Pragmatic Programmer / Hunt,
Thomas
● Design Patterns
Jiří Mareš (jiri.mares@svt.cz, jirablog.blogspot.com)
ČSAD SVT Praha s.r.o. (www.svt.cz)
Hinweis der Redaktion
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