20101124 Aplikované nástroje SW inženýra

495 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
495
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • 20101124 Aplikované nástroje SW inženýra

    1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Nástroje SI – code coverage ● Použitelné pro kontrolu testů ● Představa, jak moc je otestováno ● 100% coverage není záruka
    14. 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. 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. 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. 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. 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. 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. 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)

    ×