JavaZone 2006 - Gode grep når prosjektet blir stort
•
0 likes•318 views
Erfaringsrapport fra STAY-prosjektet på BBS presentert på JavaZone 2006.
More Related Content
Similar to JavaZone 2006 - Gode grep når prosjektet blir stort
Similar to JavaZone 2006 - Gode grep når prosjektet blir stort (20)
JavaZone 2006 - Gode grep når prosjektet blir stort
- 2. Gode (og ikke fullt så gode) Grep når prosjektet blir stort Eirik Torske, BBS JavaZone 2006 Experience reports
- 5. Jo større et programvareprosjekt er, jo lettere kommer svakheter fram – både når det gjelder prosess , organisering og kodekvalitet
- 6. BBS
- 7. egiro ” Alle-til-alle”- løsninger som styrker bankenes markedsposisjon Automatisk betaling av faste regninger On-line kortbetaling Elektronisk bedriftsbetaling Elektronisk fakturaformidling direkte til nettbanken Småpengekort Morgendagens kort Sikkerhetsløsning for nettbank og elektronisk handel
- 8. STAY
- 12. Kontekst: utviklingsmiljø <manuelt>
- 13. Kontekst: utviklingsmiljø <manuelt> <manuell deployment>
- 17. Manuelle rutiner og altruisme vil ikke sørge for at dette ivaretas!
- 18. Og hva trenger vi da?!
- 23. Kontekst: utviklingsmiljø <manuelt> ... ... <manuell deployment> <check out> for-each dependent module: <check out> <deploy> For-each dependent module: <deploy> <kompiler, test, bygg> For-each dependent module: <kompiler, test, bygg>
- 24. Kontekst: utviklingsmiljø <manuelt> ... ... <manuell deployment> EAR/WAR JAR
- 25. Kontekst: utviklingsmiljø <manuelt> <CI-trigget> ... ... WAR/EAR JAR/WAR/EAR
- 26. Bruk av Continuous Integration
- 45. Kravinnsamling
- 46. Kontekst: kravinnsamling Utviklere Krav? Domenet? Domeneksperter (brukere/oppdragsgivere) Java? Automatiserte tester?
- 47. Fra beskrivelse til test Kontekst: kravinnsamling Behandle transaksjon public class BehandleTransaksjonTest extends TestCase { ... } algoritmisk Behandle transaksjon veiledende
- 50. JUnit-baserte kravtester Behandle transaksjon public class BehandeTransaksjonTest extends TestCase { ... } ! Konsekvens: kravtester
- 51. JUnit-baserte kravtester Behandle transaksjon public class BehandeTransaksjonTest extends TestCase { ... } ! Konsekvens: kravtester
- 53. Konsekvens: kravtester FitNesse-baserte kravtester
- 54. Konsekvens: kravtester FitNesse-baserte kravtester
- 55. Konsekvens: kravtester FitNesse-baserte kravtester
- 56. Konsekvens: kravtester FitNesse-baserte kravtester
- 59. Konsekvens: kravtester Formalisert testing Testdynamikk (endringer av testscenarier) Feedback (validering av krav) Domenekunnskap (test-driven top-down approach) Automatisert (regresjonstesting) FitNesse JUnit
- 63. Ser rart ut...?
- 67. … ser jo rart ut, ja!
- 68. bla-bla-bla ... bla-bla-bla ... ” fellesblankett” ” belastningsbunt” ” tilbakeført anvisning” ” tvangsavstemt hevet giroutbetalingsbunt” Domeneekspert Domeneekspert
- 69. ” fellesblankett” ” belastningsbunt” ” tilbakeført anvisning” ? ” tvangsavstemt hevet giroutbetalingsbunt”
- 70. ” fellesblankett” ” belastningsbunt” ” tilbakeført anvisning” ” tvangsavstemt hevet giroutbetalingsbunt” ” Common payment form”? ” Forced matched cashed bundle of payment cheques”…? ” Reversed cheque”…? ” Debiting bundle”…?
- 71. ” fellesblankett” ” belastningsbunt” ” tilbakeført anvisning” ” tvangsavstemt hevet giroutbetalingsbunt” ” Common payment form”…? ” Forced matched cashed bundle of payment cheques”…? ” Reversed cheque”…? ” Debiting bundle”…?
- 74. Kontekst: overordnet prosess
- 75. Kontekst: overordnet prosess ” Management’s view” tid Spesifisering Realisering 25% ferdig 50% ferdig 75% ferdig 100% ferdig Systemtest Godkjenning Leveranse: prod
- 76. Kontekst: overordnet prosess Spesifisering og Realisering og Test Godkjenning Akseptansetest Iterasjon #1 #2 #3 #4 #n • • • tid Leveranse: prod kopi-prod... • • • ” Developer’s view”
- 77. Kontekst: overordnet prosess Spesifisering og Realisering og Test Godkjenning Akseptansetest #n ? ? ? • • • tid Iterasjon • • • Leveranse: ? #1 #2 #3 #4
- 78. Kontekst: overordnet prosess Spesifisering og Realisering og Test Godkjenning Akseptansetest • • • tid #n Iterasjon • • • Leveranse: ? ? ? ? #1 #2 #3 #4
- 79. Kontekst: overordnet prosess tid
- 80. Kontekst: overordnet prosess
- 81. Kontekst: overordnet prosess Forsinkelser!
- 86. Flere gode grep… hadde ikke tid til å argumentere for disse Ikke endre open source tredjepartskomponenter uten at det foreligger konkrete planer om å gi det tilbake til det eksterne prosjektet! Det holder ikke bare å ha det som et ønskelig mål! Bruk en Wiki som overordnet prosjektweb, men husk å utpeke en redaktør med ansvar for informasjonsarkitekturen! Ikke gå utenfor standard konfigurasjonsmuligheter for tredjepartskomponenter! Legg viktig prosjektdokumentasjon som kravbeskrivelser mm. VCS! Definer en katalogstruktur for prosjektdokumentasjon, ikke bare for kildekode! Ha daglige stand-up-møter for teamet! ... Flere gode grep… hadde ikke tid til å argumentere for disse Ikke endre open source tredjepartskomponenter uten at det foreligger konkrete planer om å gi det tilbake til det eksterne prosjektet! Det holder ikke bare å ha det som et ønskelig mål! Bruk en Wiki som overordnet prosjektweb, men husk å utpeke en redaktør med ansvar for informasjonsarkitekturen! Ikke gå utenfor standard konfigurasjonsmuligheter for tredjepartskomponenter! Legg viktig prosjektdokumentasjon som kravbeskrivelser mm. i VCS! Definer en katalogstruktur for prosjektdokumentasjon, ikke bare for kildekode! Ha daglige stand-up-møter for teamet! ...
Editor's Notes
- JA, Velkommen til ”Gode og ikke fullt så gode grep når prosjektet blir stort)! Det som ligg bak den lett salgbare tittelen e erfaringa fra STAY, som e BBS sitt store omleggingsprosjekt for tida
- Og her e det i ska snakke om: Først litt om BBS – så litt overordnet om STAY-prosjektet, før I bynne på erfaringan Og der har I tenkt å drøfte følgende... [klikk] Og som en advarsel: det bli ingen kodelinja å se! DESSVERRE! Ja, sorry assa! ------------------------------------- (Andre ting I ikkje ska snakke om e: Tekninsk arkitektur Open-source komponenter ... ) ( For å gjøre presentasjonen mest mulig interessant og ”convenient” for dokker oppmøtte så har I prøvd å samle opp nåkken av dem viktigste erfaringan punktvis, som gode grep , og ikke-fullt-så-gode grep (eller kanskje direkte dårlige grep – det er litt opp til dokker å tolke). Dokker får ta det for det det e, men det e i hvert fall min egen liste over ting som I ska argumentere for å få inkludert i neste større programvareprosjekt som i ska delta på... Den lista vil fram tid til annen dukke opp her [klikk] ) ( For mange av dokker vil denna presentasjonen muligens inneholde mye av typen: ”detta har I hørt før..”, ”jaja, detta e selvfølgeligheter…” Hvis så, så greit nok, men da kan dokker jo spør dokker sjøl om koffor dokker høra detta igjen! – og igjen – og igjen! ) ( I ska prøve å være så objektiv som mulig – og ska melde fra når I entra den mer subjektive spekulasjonsfasen… )
- Lynraskt om me sjøl : I heite Eirik Torske og e utvikler på BBS og ha vært det sia 2004 STAY er det absolutt største prosjektet I har vært borti til no – Og det bli litt av konteksten for denna presentasjonen – Sjokket av å komme fra små oversiktlige prosjekter til et stort prosjekt som nærmest virke på en som en egen levende organisme (med eget værsystem) I hadde en hypotese før STAY som var vel nåkkå sånn som… [klikk]
- … Og denna hypotesen har ikkje blitt motbevist under arbeidet med STAY i hvert fall ------------------------------------------------------------------------------------------ ( Med ”kodekvalitet” mener jeg (akkurat her ihvertfall ) stort sett ikke-funksjonelle egenskaper som vedlikeholdbarhet, skalerbarhet, ytelse, … )
- BBS vi e ca. 700 ansatte og holder til oppe på Rommen
- Det e mange som tror at BBS e statlig eller sånn halv-statlig – det e BBS ikkje – vi e heleid av diverse banker i Norge BBS sin oppgave e å tilby tjenesta til bankan – det være se finansielle, til sikkerhetsmessige og administrative Og tjenesta basert på felles bankinfrastruktur e særlig aktuelle – her e et knippe slike eksempla… I ska ikkje si nåkkå meir her, anna enn at detta har BBS holdt på med detta her sia 1972… -> utvikling og drifting av store forretningskritiske datasystem ---------------------------------------------------------------- [til overs] ( For dem aller fleste av disse tjenestan e det vill konkurranse for slike tjenesta, fra inn- og utland ) (Og et av dem e NICS) (Et svært sentralt system som kjøre oppe på BBS e NICS) (BBS utvikler og drifter NICS på konsesjon fra Norges Bank (Alle betalingstransaksjoner i Norge (mellom banker på et visst nivå) må på en eller annen måte gjennom NICS – I ska gå gjennom en betalingsktransaksjon om litt...))
- PROSJEKTET har fått betegnelsen STAY
- ...og e et moderniseringsprosjekt og tar mål av seg å erstatte samtlige stormaskinsystema med nye systema basert på UNIX/Java Og vi ska etter planen være sånn ca halvveis...
- Dem funksjonelle krava var (i hvert fall i bynnelsen) ansett å være ganske så veldefinerte [klikk] All eksisterende funksjonalitet skulle også være tilstede i dem nye systeman. [klikk] Men det e jo alltid nokkå som kjem i ettertid… bokstavelig talt seilende inn fra høyre Dette e en stor utfordring å håndtere -> I ska snakke om kravinnsamling litt seinere… ------------------------------------------------------- ( Fra å være det aller enkleste scenarioet – kopier et eksisterende system (enklere enn ny applikasjon), går det til å bli det aller vanskeligste! )
- OK – la oss starte på erfaringan… først ska I snakke om storskala utviklingsinfrastruktur Her e prosjektet sin størrelsesordenen pr i dag… Men det har ikkje bestandig vært slik. Vi starta opp utvikling for litt over to år sia – med ett team og tre utviklera Og vi starta å kode med følgende standard verktøytopologi [klikk]
- Og siden detta e et GRØNN presentasjon skal I ta detta kronologisk i detalj: Her e en utvikler med sitt lokale utviklingsmiljø, sin IDE Her sitt’n med sine test-drevne mikroiterasjona – skriv test, test, skriv kode, test, skriv mer kode, test, skriv en ny test, o.s.v. [klikk] Når han eller hun e fornøyd, publiser koden til versjonskontrollsystemet [klikk] ------------------------------------------------------------------------ ( Å benytte en eller annen form for Test-Driven Development e så grunnleggende og nødvendig at I ikkje legg det på lista over grep (engang) Å utvikle programvare i denna størrelsesordenen uten automatiserte tester vil I (nesten) kalle hasardiøst, kanskje t.o.m. useriøst! (Argumenta for det kan tas i pausa) Så – test-drevet utvikling er en forutsetning!) [klikk]
- I kommer til å si CVS – og da meine i VCS sånn generelt – I kommer også til å benytte CVS/Subversion-sjargong… OK, enhetstesting skjer lokalt… når det gjeld integrasjonstester så kjøres enten bygging/deployment lokalt, gjerne integrert i IDE – eller så kan man manuelt bygge og deploye til diverse driftsmiljøsystemer – Det være se systemtestmiljø, preprod-miljø, prod-miljø, … [klikk] Detta e å anbefale på grunn av at man bør få erfaring med reelle kjøremiljøet på et tidlig tidspunkt. Der vente det bestandig overraskelsa - og dem bør man få så tidlig som mulig! ...så det e scenariet I no tar med videre…
- Men utviklern e jo ikkje aleine – så vi legg på nokken fleire... I STAY så økte antallet utviklera fra 3 til 60 utviklera på ca. 7-8- måna [klikk] … og så begynne kodebasen å vokse [klikk] Det første problemet med denna måten å jobbe på er at det skalera ikkje, arbeidsmessig – og I tenke ikkje på mengden kode som gjør responstiden for ”updates” og ”commits” treg,eller nåkkå sånn… Nei, nei – det er rett og slett praktiske problemer med å jobbe med så mange Java-klasser og Java-pakker samtidig [klikk] Vi begynte derfor ganske umiddelbart å modularisere koden vår. En modul er en et (frittstående) koherent samling av Java-pakker – Man samler Java-pakker i moduler av samme årsak som man samler Java-klasser i Java-pakker. En Java-modul er rett og slett en super-pakke - og manifesterer seg normalt som en JAR-fil Det minska skogen av Java-klasser og -pakker – koden blir mer håndterlig og synlig. I tillegg: Så e moduler er mer synlig i en arkitektur – det blir enklere med storskala-design Forenkle kodegjenbruk … man kan partielt bytte ut kode på en mer oversiktlig måte For eksempel kan man oppnå mer fleksibel deployment -> moduler spesialtilpasset testing og driftsmiljø, for eksempel Og da deployer man ikke kode som ikkje e i bruk heller (Hvis man har fulgt ”Dependency Inversion Principle” -> Depend upon Abstractions. Do not depend upon Concretions) (Enklere å forholde seg til for en utviklingsorganisasjon med flere utviklingsenheter (team)) Dessuten gir denna kildekodemodulariseringa gir også utviklere valget: Ska I jobbe med kildekodeavhengigheta eller binær-avhengigheta, byte-kode? Hvilke moduler ska i refactorere og endre, og hvilken kode vil I ha mer avstand til og kun behandle som tredjepartsbiblioteker? Multimodul-utvikling har I hørt argumentert for på dem siste to åra her på JavaZone ihvertfall Så I ska ikkje si nåkkå meir om det – det e en bra ting ----------------------------------------------------------- (En erfaringsprat fra Telenor-prosjekt for to år sia, og Mr. Malcolm Sparks som snakka om ”Modularity” i fjor) (binæravhengigheter øke bygghastigheten betraktelig, Da treng man ikkje skanne tusenvis av klasser når man sitt å kompilera og testa og kompilera og testa…)
- Så la oss legge det første gode grepet inn i oppsummeringslista: Etabler en modulstruktur! … burde nesten vært inkludert i Java-språket – der skjer ting i Standard Edition 7 – Dolphin Og dokker har vel alle skjønt fargekodan - grønt for bra og rødt for dårlig
- ( Det der ska forestille multimodul-organisering av koden i VCS...) For å få til multimodulutvikling, der man virkelig HAR valget mellom kildekodeavhengigheter eller binæravhengigheter (bytekode-avhengigheter), måtte vi starte med å deploye våre egne moduler (JAR-filer) til et felles modul-repository (sammen med resten av tredjepartsavhengighetene ligger). På grunn av den store dynamikken og parallelliteten i utviklingsarbeidet må disse JAR-filan ha en svært fleksibel releasehåndtering. Samtlige modula e jo under ”heavy construction”! Og forandres fra minutt til minutt … I ska straks komme tilbake til et byggeverktøy som støtte denna måten å jobbe på ;-) [klikk] Her har vi fått med et felles artefaktrepository… Nå er det to nye problemer som har dukka opp 1) Den første e manglende kvalitetssikring av innsjekket kode. Hva som skal legges i ordet ”kvalitet” når det gjelder kildekode skal jeg overlate til andre og definere. Men som et minimum må kode kompilere og testa kjøre uten å feile . Videre kan det handle om statisk kodeanalyse, for eksempel overholdelse av kodeformateringsregler og fastsatte programmeringsidiomer . -> Hos oss: Det tok ikke mer enn noen dager før den første koden som ikke kompilerte dukket opp i VCS! Men felles artefakt-repository introduserer enda et problem: 2) Kildekode i CVS og modulan repository er to forskjellige integrasjonspunkter, avhengig av om man velger kildekodeavhengighet eller binæravhengighet -> mulig kodedivergens -> Hos oss: Det tok ikke mer enn en ukes tid i ett eneste lite team før moduler i repository var utdatert i forhold til VCS-kildekode! Og jammen dukket det ikke opp av og til logikk moduler som ikke var sjekket inn i CVS ennå heller…)
- Og la det være heilt klart! Troen på det gode mennesket hjelper ikke her
- Da treng man sårt ”Continuous Integration” -system Som funke som følger: Når kode sjekkes inn blir: En clean checkout av koden foretatt Koden kompileres Og testene blir kjørt Og… kanskje anna kvalitetssikring… I tillegg til kvalitetssikring av innsjekket kode så oppdateres artefakt-repository med siste kodeversjon av modulen, kalt SNAPSHOT. Samtidig som dette blir implementert, bør man begrense adgang til repository -> dette for å øke sikkerhet og integritet til alle JAR-filer der! Hvis feil blir oppdaga må det varsles – ...ska komme tilbake til det
- Her er Continuous Integration lagt til… [klikk] Også stenge vi adgangen til artefakt-repository... For oss så ble dette ad-hoc-organisert pr team pr modul i begynnelsen. Det fungerte sånn noenlunde så lenge modulene var i et beskjedent antall – at modulene ble utviklet av samme team hjalp også veldig på. Ved ehh ”uoverenstemmelser” var det stort sett bare å henvende seg til sidemann eller rope ut i rommet – og iverksette et tiltak umiddelbart etter en rask avklaring av ansvarsforhold... MEN: Når flere team etablerte stadig flere moduler... DA knakk dette så det sang! [klikk] Og det er på grunn av modulavhengigheter…
- Her er en illustrasjon av modultre – noen av dem vi har… Når man gjør endringer i en overliggende modul e det ikkje tilstrekkelig å kompilere/teste denne modulen alene – Alle nedstrøms moduler må også kontrolleres – selvsagt! I tillegg hadde vi tilfeller med sykliske avhengigheter – særlig i begynnelsen, før modulstrukturen ”liksom hadde satt seg”, dukka disse opp ( Også oppgraderinger av tredjepartskomponenter (Spring/Hibernate/Commons X) kan knekke byggen Dette på grunn av felles avhengighetsdeklareringer (”dependencies”) )
- Problemet med modulavhengigheter kan løses på denne måten -> ved å gjenta kvalitetssikringsdelen for alle nedstrøms modulavhengigheter Og detta tilsi også at CI-infrastrukturen må sentraliseres/ konsolideres
- Her er sentralisert, felles CI-infrastruktur lagt til
- Neste mulige problem er manuelle deployment-rutiner. Det vil være mulig å inkludere lokal uinnsjekket kode i EAR/WAR-filer som blir deployet.
- En måte å unngå det på er å automatisere deployment. Det implementeres ganske enkelt ved å utvide ansvaret for CI-server til å omfatte bygging og deployment av WAR/EAR-artefakter mot aktuelt driftsmiljø ... OK – det va litt krav til bygg-relatert infrastruktur og design. Når det gjelder CI-verktøy som vi benytta på BBS så ska I ikkje komme så mye inn på det her no – vi har et internt utvikla system, men vi e litt usikker på videre strategi... Enten så må videreutvikling av det interne systemet forankres eller så må vi kikke etter en ekstern løsning. Poenget er at en ny løsning må tilfredstille kravan som I no har skissert opp her. Jo flere krav som ikke er tilfredstilt, jo dårligere grep vil det bli. Det dukka stadig fleire CI-systema opp der ute – både open source-baserte som CruiseControl, Luntbuild, Continuum… … og kommersielle som Anthill, QuickBuild, Pulse, Maestro... Og sist no TeamCity fra IntelliJ-produsenten Jetbrains...
- Men I e ikkje heilt ferdig med Continuous Integration – No ska I si litt om erfaringa ved daglig bruk…
- En første mulige konsekvens : e faktisk at alarmen fra CI blir ignorert og/eller ikke forstått [klikk] Botemiddel: Tilbakemeldingen må enkelt kunne tolkes . Man må kunne forstå hva som er galt, hva som har forårsaket det og ikke minst hvem som er den ansvarlige. [klikk] Tilbakemeldingen bør sendes ut til ALLE utviklere (og andre interessenter for den del…). Den som føler kallet (som oftest den som forårsaket knekken, men ikke nødvendigvis) melder fra at feilen blir gransket og er under oppretting.
- Vi har for det meste benytta en ganske prosaisk tilbakemeldingskanal: mail -> det kan jo også dreie se om sirena, blinkende lys og elektrosjokk Her er et eksempel på tilbakemeldingsmail der man ser at det er en feil på gang... [klikk]
- Mailen viser også: Hvilke moduler feil e oppstått [klikk]
- * Og kem som e ansvarlig [klikk]
- ...og enda litt lenger ned: Hvordan feilen har oppstått [klikk]
- Og førstemann-til-mølla-prinsippet gjelder for å ta ansvar for kode-fiks – men som regel e det samme person som har brekt koden, bør i hvert fall være det Her e et eksempel på en tilbakemeldingsmail om at en fiks er på vei, distribueres til alle… Stressnivået/irritasjonsnivået synker raskt ned når en slik mail kommer
- Hvis ingenting skjer bør man purre! Det bør være lav terskel for denna type samhandling...
- Et annet problem er hvis tilbakemeldingene kommer for tregt [klikk] Hvis det går over la oss si over 20 min. etter en ”committ” før tilbakemelding kommer, blir man lei av å vente på tilbakemeldingene. Man mister fokus, begynner å tenke på andre ting, begynner å jobbe med nye endringer. Dessuten er det stor sannsynlighet at nye endringer er ”committa” i mellomtiden, noe som gjør tilbakemeldingene vanskeligere å tyde. Andre feil kan også maskere dine feil. [klikk] En måte å angripe problemet på e å sette krav til selve CI-verktøyet [klikk] Hvis man ikke klare å oppnå det, må man rett og slett innføre tidskrav for testan Det e mye som kan tunes for å få ned test-tid (se nedenfor) Til nød så må man prioritere mellom testan i en modul, lage en test-suite med de viktigste testene som inkluderes i CI-bygg Resten av testan kan for eksempel kjøres nattlig... -------------------------------------------------------------------------------- Verktøy: K jør kun det som er nødvendig i en bygg – unngå unødvendig ”checkouts”, kompileringer, testkjøringer og artefakt-bygginger for”nedstrøms” moduler av den modul VCS-endringen har funnet sted Testoppsett: maven.junit.fork=false, JUnit test suites, test fixtures (som lastes én eneste gang), begrens bruken av Spring- og Hibernate-konfigurasjoner, hindre test-redundans (mock alle steder unntatt ett), … ------------------------------------------------------------------------------- (Dette er et sentralt poeng (og observasjon) -> hvis man etterstreber en ”agil” metodikk MÅ man ha verktøy som understøtter den høye graden av dynamikk, deltagelse og endringsvillighet som agil metodikk predikerer. Hvis ikke blir metodikken bare en vits!) (-> Kom tilbake til det faktum at tester må kunne ”skrus og vris” på, muligens av andre enn den utvikleren som opprinnelig har designet/implementert testen. Et argument for å sette de samme krav til vedlikeholdbarhet og dokumenterbarhet på testkode som på produksjonskode.)
- Byggen har to tilstander: enten er den grønn/OK – eller så er den rød/knekt! Erfaringen er: Byggen må være minst mulig knekt! Hvis den er knekt størstedelen av en aktiv utviklerdag minsker effektiviteten betraktelig. Man blir også frustrert! Generelt sett dårlig for prosjektmoralen! [klikk] Botemiddel: Deaktiver problematiske tester (X-prefix i aktuelle JUnit testmetode, maven.test.skip=true) Ved problematiske feil er det best å deaktivere testene så de ikke holder byggen knekt i lengre tid.
- Så e det problemet med uavklart ansvarsforhold for ”utviklingsinfrastruktur” Versjonskontrollsystem og Continuous Integration-maskiner er sentral infrastruktur! All form for nedetid betyr stort sett uproduktiv tid. Når 60 utviklere ikke får gjort noe konstruktivt så e det DYRT. [klikk] OFTE… e ansvarsforhold for denne type infrastruktur uformell, og sett på som mindre viktig Det e ikkje bra – det bør ses på som produksjonsmiljøer, like viktig som andre forretningskritiske systema [klikk] Driften av denne infrastrukturen må opp på et såpass formelt nivå at kontinuerlig overvåkning utføres. Vedlikeholdet bør være et definert ansvarsområde for en eller flere utviklere. I STAY hadde vi ikkje fokus på verken maskinvarebiten eller vedlikeholdsbiten av dette før over et år hadde gått… Med ditto frustrasjona ------------------------------------------------------------------------------------ Detta e svært viktig og kan ikke understrekes godt nok! ( Kanskje overleveres til profesjonell drifting (IT-avdeling eller driftsavdeling). )
- Til slutt vil i slå et slag for nokkå som vi har begynt med i dem siste månan i STAY, nemlig personlig oppfølging etter alvorlige bygg-knekker – Det e mange måta å håndtere varsling om bygg-knekk på… Detta e en ekte de-briefing -måte å gjør det på... [klikk] Hos oss er det Johannes Brodwall som har rollen som seriøs-og-litt-skummel-mann-med-hatt som kommer på besøk til Bjørn Nordlund i rollen som ansvarlig ”bygg-knekker” Det som blir diskutert er blant annet: Hva gjorde du feil? Kunne du unngått dette? Hva har du lært? … og kanskje også hjelper til med å fikse feilene OG – det e svært viktig at detta foregår på saklig og profesjonell måte… [klikk]
- IKKE SLIK! [klikk]
- I henvisa ellers til en tråd på javaBin-forumet hvor oppfølging og straffetiltak mot av ”CI-knekkera” blir diskutert... Mange kreative forslag der
- Så la oss legge det inn i oppsummeringslista! Etabler bygg-rutiner – automatiserte sådan – ( Inkludert oppfølging av versjonskontrollserver, continuous integration og artefakt-repository ) Daglig oppfølging må til! ( Her e forankring helt sentralt for hvor effektivt dette blir! )
- Med det samme I e i gang… Og I ska ikkje gå rundt grøten her, men bare inkludere Maven i lista over gode grep… Vi har brukt Maven fra dag 1 som primært byggeverktøy i STAY – og det har vi gode erfaringa med Maven støtta ting som vi har snakka om: Multimoduler, SNAPHOT-releasa og artefakt-repository (Det var vel Maven som gjorde at vi kunne prøve på det in the first place...) Ellers er ting som man uansett måtte ha standardisert, standardisert – og gjort det på en helt akseptabel måte Det gjelder navngivning, prosjekt-layout, o.s.v. Og bruk Maven2 – Maven2 tar standardiseringa enda lenger enn Maven1, retter opp en del inkonsistens, bedrer konfigureringa betraktelig og e mye raskere VELDIG BRA! ( Maven bør være et de-facto byggeverktøy, bruk Maven på mest mulig standard måte, skreddersy/konfigurer minst mulig – så blir verden enklere for oss utviklere. Detta e et steg fremover! )
- OK, da ska I snakke om kravinnsamling… [klikk]
- I STAY har vi det slik som det ofte e – To relativt markante gruppa: utviklere med manglende kunnskap om domenet og domeneeksperter med manglende kunnskap om teknologien Vi har hatt domeneeksperter representert og tilgjengelig i utviklingsteaman heldigvis ( , selv om det har vært i noe varierende grad ) For domenet og kravene er komplekse. Kravan ligg gjemt i noen hundre tusen kodelinjer i eksisterende stormaskinsystemer. Og så e det: * Standarder som endrer seg * Juridiske bestemmelsa * 20 års kommunikasjon med banker og andre eksterne interessenter I tillegg (som nevnt) kom en rekke nye krav etter initielt analysearbeid da man så muligheten til å endre på en del eksisterende særegenheter, inkonsistens, redundans og irritasjonsmomenter… Vi benytte Use-Case (UC) til kravbeskrivelse – og pr i dag finnes det over 200 UC…
- Vi har spesifisert krava via automatiserte testa. Og vi har gjort det på to forskjellige måta: [klikk] 1) En måte vi har prøvd å gjøre det på e via en ganske strikt mapping mellom UC og test – her e JUnit brukt som verktøy [klikk] 2) En annen metode vi har prøvd e å se på UC som veiledende beskrivelser (mer som en ”story”) og spesifisert kravan i detalj i tabellform – her e FitNesse brukt som verktøy Og I vil kalle detta for kravtesta heretter. Kravtesta fokusere ikke på fingranulær oppførsel eller integrasjon mellom systemkomponeneter, men utelukkende på krav, funksjonelle og ikke-funksjonelle
- For å ta JUnit-baserte kravtester Motivasjonen her var at UC ble sett på som statiske, samt at det var Java-omskolering av domeneeksperter på gang… Vi hadde en rekke hypotesa før vi satte i gang... Som dokker kan se her … så hvordan har det gått med dem hypotesan [klikk]
- Erfaringan e som følger: * Siden kravene endret seg stadig (og ikke minst FORSTÅELSEN av kravene) falt håpet om måling av fremdrift sammen umiddelbart! * All form for domeneeksperter som bruker Java-kildekode har det ikke blitt noe av foreløpig (mye på grunn av arbeidspress…) * …mens dem to siste hypotesan har holdt for så vidt greit Men den strenge UC-test-mappingen føra til nåkkå meir problematisk [klikk]
- Siden mappingen er såpass strikt har det ført til at testene har påvirket UCene [klikk]
- Detta e litt farlig [klikk]
- Det har medført mye jobb i å synkronisere UC og tester (endringer av krav -> endringer i UC -> endringer i test) det igjen kan medføre incitamenter på å ikke endre UC i den grad de faktisk bør... dette kan igjen kan medføre at nødvendige store kodeendringer utelates/utsettes utviklere får et sterkt eierskap til UC ( Dette er ikke problematisk i seg selv – kanskje også nødvendig p.g.a. mangel på tilgjengelige domeneekspert-ressurser ) Da e faren at UC blir kunstig tekniske p.g.a. den sterke knytningen mellom kravbeskrivelse (UC) og tester (JUnit-kode) Og detta kan svekke muligheten for involvering fra ikke-tekniske domeneeksperter siden dem får problemer med å skjønne ka som står i UC! Uten sterk involvering fra domeneeksperter/oppdragsgiver mister man raskt kontinuitet og fokus på kravan (og stedet for kan implementasjonsdetalja komme mest i fokus) Man skal ikke skrive UC for å lage tester, man skal beskrive hvordan systemet skal oppføre se, og reagere på ytre stimuli! Man kan godt starte med JUnit-baserte kravtester for å angripe krevbeskrivelsene på en top-down test-drevet måte – Men man må stoppe i tide. ( Når tiden begynner å gå til å synkronisere UC og tester har man gått for langt. ) Og aller mest sentralt: Ved JUnit-baserte kravtester får man ikke feedback fra domeneeksperter siden de ikke forstår Java -> Be Careful! [klikk]
- Så FitNesse-baserte kravtester Først litt om FitNesse... FIT er et testverktøy som muliggjør deklarering av testdata i Office-dokument FitNesse er et overbygg på FIT, som inkluderer en full Wiki for å legge inn testdata ...I antar alle her hva på BOFen ” Executable specifications: Keeping Fit at work”, med Trond Arve Wasskog og Nils Chr. Haugen I går kveld…?
- Men uansett… raskt om virkemåten: * Man putter tekstlig data inn i en Wiki, via Wiki-format * Detta blir tolket og man får generert HTML – slik som detta utklippet vise * Men man får også tolket dataene via litt ”reflection magic” og overført dem til testa skreve i Java * Alt etter hvordan du har laget disse FitNesse-Java-test-klassan så kan du enten putte test-data INN eller sjekke at OPPGITTE forventa data faktisk stemme overens med ka test-klassan får etter test-kjøring Her e en typisk utklipp fra en FitNesse-test – innlesing… [klikk]
- Prosessering… detta føre bare til et kall på en Java-test-metode [klikk]
- Og verifisering! [klikk]
- Vi hadde følgende hypotester når vi satte i gang... Tja, egentlig ikkje så mange. For min egen del skjønte I ikkje heilt kossen I skulle sette det hele opp og komme i gang… Og det va en overgang fra å jobbe med JUnit-baserte kravtesta Man bli her tvunge til å legge vekk implementasjons-perspektivet, og heller fokusere på krav og tenke black-box! Og det tror I e nyttig!
- Så, ja, det e litt jobb med å få det opp å kjøre Men når det først e oppe å går, så har vi sett følgende konsekvenser: * Synliggjør testene (black-box, tabellform) * Synliggjør testdata (black-box, tabellform) * Øker tilgjengeligheten på tester og testdata (web) * Standardiserer testdata, både format og innhold Her ligger kravspesifikasjonen på en webside for alle og se, og ikke nok med det – alle kan til enhver tid endre/legge til ny testdata og kjøre testene på ny!! Altså verifisere at systemet fungerer som det skal. Testdata legges inn på en enkel måte via Office-dokumenter eller direkte i Wiki Dette klarer ikke-tekniske domeneeksperter å få til, enkelt! -------------------------------------------------------------------------------- ( En Wiki bør alle prosjekter ha uansett )
- Her e dem to metodan lett oppsummert: FitNesse: Command Line Test Runner – Regresjonstesting Øker domenekunnskapen 3) Tydelighet, leselighet, tilgjengelighet... 4) Endring av scenarioer og innhold 5) Trygghet gjennom bruk, leselighet -> bra kandidat for systemtest, akseptansetest (andre JUnit-basert kandidater DDStep, JBehave, mm)
- Det handle om ikke å redusere domeneekspertene sin mulighet for å jobbe effektivt med kravspesifsering Med for tekniske use-case og uleselige JUnit-testa så begynte detta og skje Detta e en åpenbart dårlig idé! … invertert blir det for eksempel [klikk]
- Det handle om å engasjere domeneeksperter og oppdragsgivere i spesifisering av systemoppførsel --------------------------------------------------------------------------------------------------- Man kan godt starte med JUnit-baserte kravtester for å angripe krevbeskrivelsene på en test-drevet måte – Men man må stoppe i tide. Når tiden begynner å gå til å synkronisere UC og tester har man gått for langt. Da må man straks gå over til en mer visualisert måte å lage kravtester på, for eksempel ved å bruke FitNesse. Det gir videre innsikt i løsningsdomenet er min erfaring, fordi man må virkelig jobbe med å destillere ut input og output / aksjon og reaksjon Man blir tvunget til å se på systemet som en black-box, og det er nyttig. Man får raskt noen a-ha-opplevelser og finner raskt ut om man har implementert unødvendig stuff…
- Med det samme vi e inne på å stenge domeneeksperter ute... [klikk] Domain-Driven Design-boka av Eric Evans hadde stor innflytelse på oss i 2004 – og forhåpentligvis fortsatt. Domain-Driven Design sier: ”how-how, fint med smidighet og koding, testing og deployment fra dag 1 – men ikke glem modelleringen da!” Domain-Driven Design er objektorientert design + overordnede design/pattern-begreper + begrepsapparat for organisering og gjennomføring av programvareprosjekter. Med det sterke fokus på domenemodell og domenebegreper, blei vi i STAY tidlig enige om å prøve å etablere felles kodebase for felles begreper. Både rett og rimelig det; Bank og Penger og Kontonummer og sånt... I Domain-Driven Design er domenebegreper hellige – ”the ubiquitous language” / allestedsnærværende språket står sentralt Teorien e at hvis man skalte og valte med domenebegreper fører det bare med seg økt kompleksitet med påfølgende misforståelsa Så diskusjonen kom fort: skal vi oversette begrepene man bruker daglig? [klikk] Det vi endte opp med var å ivareta norske begreper både i dokumentasjon og også i kode...
- Og det føre til følgende ting…
- Men – alternativet kan bli mye verre! Når man oversetter norske domenebegreper må vi spørre oss om vi virkelig kan gjøre det! * Er domenebegrepene veletablerte ? ( kvaliteten på domenebegrepene) Hvor lenge har begrepene eksistert? Hvem fant på begrepene? Hvordan oppsto begrepene? * Er domenebegrepene i utstrakt bruk ? ( utbredelsen av domenebegrepene) Hvem bruker domenebegrepene? ...kun interne når de bruker datasystemet? ...kun interne i arbeidssituasjon? ...i kommunikasjon med kunder? ...i standarder? ...i kontrakter? ----------------------------------------------------------------------------------- * Er det noen som kan tegne og forklare domenet i organisasjonen? * Er det noen i organisasjonen som har et bevisst forhold til domenet i det hele tatt?
- Når vi oversetter domenebegreper lager vi i realitet en ny domenemodell Personlig så hva i svært skeptisk til å bruke norske språk i kode - det ser ganske kårni ut Men etter å ha tenkt litt på det da… ->Her ska vi lære oss et nytt problemområde, med sine, begreper, egenskaper, regler, sammenhenger, assosiasjoner... Og det først vi gjør? Vi oversetter primære begreper til engelsk!?! Hallo! Det er vel å introdusere unødvendig kompleksitet...? [klikk]
- Ett, ganske svakt argument etter min mening, e at det bli lettere for ikke-norskspråklige utviklera og forholde seg til koden Men, det e heller ikkje sikkert, for: Vi må innse at vi, de fleste av oss i hvert fall snakker god engelsk, men ikke flytende engelsk Hvis vi oversetter, kan de bli direkte feil! Og da har vi gjort vondt verre [klikk]
- I tillegg gjelder akkurat samme problem fortsatt for alle utviklerne, man må oversette kodebegreper med dagligbegreper. Å det må skje i realtime, så lenge som applikasjonen vedlikeholdes… [klikk] I e i hvert fall veldig glad for at I slepp og forholde me til denna type oversettelsa på daglig basis… Det e rett og slett for vanskelig for me … I har ikkje nok domenekunnskap … I snakka ikkje engelsk bra nok Detta e nokkå som må behandles varsomt
- Igjen handle det om å ikke stenge domeneeksperter ute... …sagt på en annen måte [klikk]
- Dette gir ikke stygg kode – dette er å ta domeneeksperter/oppdragsgiver/bruker på alvor!
- Så har I lyst å avslutte med litt mer prosess I går vel kanskje litt over i den meir spekulative delen no I STAY så har vi en intern overordnet prosess. Det e for så vidt ikkje nokkå galt med den – den beskriver det som man må utføre i et programvareprosjekt. Problemet (eller utfordringa) e at den e definert i et dokument på ikkje så mange sid’an – og det er store muligheta for å tolke ting på egne måta... [trykk] Her e en illustrasjon fra dokumentet – den kjenner vel dem fleste igjen – kjent og kjær – arven fra RUP – variasjona over et tema... ;-) Her e vertikale sekvensielle faser, samt horisontale aktiviteter som e mer eller mindre tilstede i samtlige faser… alt etter…
- Så ska I være litt frekk og sette ting på spissen... [klikk] Detta kan være en måte som styringsgrupper og upper management ser prosessen ( Det e for så vidt forståelig at dem ser det slik – dem e jo interessert i to ting – kor langt har vi kommet og kor lenge til vi e ferdig, Samt, gjennomføre vi prosjektet strukturert nok til at vi klare å forsvare ISO-godkjenninga ved neste Veritas-inspeksjon... )
- Mens dette kan være en måten utvikleran helst vil kjøre prosessen på Detta e ganske forskjellig – fryktelig forskjellig… [klikk fram og tilbake mellom de to variantene] Forventningan til prosjektgjennomføring e faktisk ikkje i nærheten av hverandre! MEN, det e jo utviklerteamene som e dem utførende elementan i prosjektet – så kossen har det gått gjennomføringsønsket? Vi har ikkje fått delploya applikasjoner til relle driftsmiljø i den grad vi hadde håpet på... [klikk]
- 2 grunna til det: * Problemet er når faseoverganger er forbundet med organisasjonsstruktur ...eller at veien mot prodsetting av kode må krysse flere avdelinger med management-lag imellom * Infrastruktur Så spørsmålet e da – [klikk] – hva skal man da levere ved iterasjonsslutt? Vi har prøvd med code-reviews, aktivitetesplanlegging, o.s.v. Men UANSETT, etter min mening, uten prodesetting (eller ihvertfall deployment på reell infrastruktur/driftsmiljøer) så forvitrer motivasjonen for iterasjoner siden dem miste all mening [klikk]
- … og da e man tilbake i klassisk ad-hoc evolusjonær utvikling i en forssefall-setting
- For å kompensere har vi prøvd å skvise alle fasene sammen til en iterasjon for å oppnå reell deployment Siden prosjektparametre som funksjonalitet og kvalitet er spikret – og man prøver å redusere tid, så er det bare prosjektressurser man har å kompansere med Det går en stund, men så... [klikk]
- [klikk]
- [klikk] Så ende det med det uunngåelige – forsinkelser!
- I ska ikkje heilt si årsaken til at de e blitt som det har blitt for oss i STAY, men vi jobba i hvert fall i en slags ”smidig fossefalls hybrid-prosess” ” Og det e ikkje alltid at en hybrid bli i det beste fra begge verdener – det kan også fort bli en bastard!” Et eksempel er fossefallsmetodens manglende iterative leveranser, koblet med iterative metoders avslappede up-front analyse og dokumentasjon... Kevlin Henney var inne på dette i går - at dette ikke kommer av seg selv - han kalte dette FRAGILE DEVELOPMENT Et godt grep for å unngå dette er å prøvekjøre minst et agilt prosjekt i organisasjonen før oppstart på et større ett! [klikk] -------------------------------------------------------------------------------------------------------------------- Teknikk 1: Planleggingsspillet [ delvis ] Teknikk 2: Parprogrammering [ lite ] Teknikk 3: Små iterasjoner [ ehhh… tja, vel – egentlig ikke ] Teknikk 4: ”Continuous Integration” [ ] Teknikk 5: Enkelt design [ ] Teknikk 6: Testing [ ] Teknikk 7: Omskriving [ ] Teknikk 8: Felles kodeeierskap [ ] Teknikk 9: Jevn fart [ …prøver så godt vi kan ] Teknikk 10: Lett tilgjengelig kunder [ ] Teknikk 11: Kodestandard [ ] Teknikk 12: Metafor [ ]
- Det er mange grunner til at dette bør gjennomføres: * Opplæring * ”Finne sin agile stil” – Det er ikke slik at man bare kan slenge på agile prinsipper og metoder så ordner alt av seg selv * Og ikke minst – validering av plattform, og designkomponenter Når man klare å få til hyppige produksjonssettinger, eller øve på det i mer eller mindre realistisk grad – først da er alle nødvendige interessenter engasjert på en tilstrekkelig måte! Og først da er organisasjonen moden! Og først da er infrastruktur og arkitektur!
- Her e samtlige, etter min meining, GODE GREP, som I no har drøfta Så da e det åpning for spørsmål…
- Her e relaterte og anbefalte foredrag som enda ikkje e avholdt… TAKK FOR ME!