Fem ting å huske på når man holder på med software-arkitektur

Det hender lille Oslo får besøk av store tenkere innenfor IT-bransjen, for eksempel når de skal holde en presentasjon på en Meetup*. Denne gangen hadde Oslo Software Architecture (OSWA) besøk av Kevlin Henney, som skulle prate om fem ting han mener er viktig å huske på når man holder på med arkitektur.

Kevlin Henney prater fort med mange eksempler og digresjoner, så man bør følge godt med for å få med seg alle poengene. Fyren har fantastisk god humor og jeg er sikker på at om han blir lei av å prate om fag, kan han fint holde stand-up.

Denne kvelden skulle han prate om fem ting du bør huske på når du holder på med software-arkitektur. Dette er ting man lett kan når man drukner i best practices. Disse prinsippene kom han frem til sammen med en venn i en høyst uformell setting. Nøkkelordene ble economy, visualization, space, symmetry og emergence.

Economy
Lag det du trenger ellers blir det ikke forstått og brukt. Er det for komplisert så vil ingen bruke det. Poenget illustrerte han ved å dra opp kildekoden til et interface i et gammelt system. Det var en slags iterator med haugevis av metoder for å navigere seg i en distribuert samling av data. Han refererte til Iterator i Java SE API-et som et eksempel på et interface som har god økonomi: den består av kun de tre metodene man trenger for å iterere en samling av data.

Visualization
Du skal kunne se hva du lager. Det du lager eller bygger er kode, og det er i utgangspunktet lite synlig. Resultatet av kode er programvare som brukeren kjører og har lite til felles med kode, helt til bruker får en feilmelding som viser kode. Det er ikke denne typen visualisering du ønsker.

En mindre opplagt måte å visualisere på er å bruke en ordsky som viser de mest brukte programmeringsordene i kodebasen. De store ordene i eksempelet han viste var public, if/else, true og false. Blant de små ordene var class og private. Da kan man forestille seg at dette er en lite objektorientert programvare og heller mer strukturert programmering med masse tilstands-flagg.

En kjent måte å visualisere arkitektur på er ved hjelp av UML-diagrammer, men for at det skal være en effektiv visualisering må detaljnivået være riktig og figuren ryddig og strukturert.

Tester er kanskje den vanligste måten å visualisere på, da får du ikke bare en visualisering av om koden virker, men også hvordan den er brukt og kan brukes. Men da er viktig ikke bare å lage testene, de må også kjøres ofte og automatisert for at de skal være verdifulle.

Konsekvensen av dårlig eller manglende visualisering kan ha katastrofale følger. Han mente at noe av grunnen til testoppskytingen av Ariane 5 feilet, var på grunn av en bug som kunne vært avdekket med bedre visualisering av koden.

Space
Space er nært knyttet til hvordan man strukturerer konseptene i koden. Du ønsker deg et rom som er ryddig og oversiktlig. Mangler dette så klarer du ikke å ha hele løsningen i hodet. Og får du ikke plass til et konsept i hodet, er det for komplisert. Et komplekst system er utfordrende å forholde seg til enten du er en bruker eller ønsker å endre det.

Symmetry
API og arkitektur må være symmetrisk ellers blir det vanskeligere å bruke og forstå. F.eks. hvis noe er symmetrisk trenger du ikke huske hele API-et så godt og dermed blir det lettere å bruke. Han klaget over at JUnits assertEquals ikke har assertNotEquals, noe som er et eksempel på hvor det hadde vært naturlig med symmetri.

Emergence
Emergence behavior dreier seg om å få implisitt oppførsel gjennom interaksjon med komponenter slik at du slipper å beskrive  oppførselen. Et eksempel kan være; om Ola baker kaker og legger dem i esker. Kari forsegler kake-eskene. Da hadde det vært ønskelig å slippe å måtte følge dem opp slik at de gjør det i riktig rekkefølge. Emergent behavior vil da være et samlebånd hvor du plasserer Ola foran Kari. Da oppnår du samme effekt uten å måtte fortelle og følge dem opp. Dette prinsippet henger sammen med økonomi. Det er bedre økonomi at komponenters interaksjon gir en implisitt oppførsel enn å gjøre det eksplisitt.

Et viktig poeng han hadde med arkitektur, er at du ikke må tro du er ferdig når du har beskrevet arkitekturen, eksempelvis via diagrammer. Det er en kontinuerlig oppgave hvor du prøver og feiler underveis i prosjektet.

En interessant påstand han kom med den kvelden er at suksessen til en gruppe ikke er avhengig av hvor høy IQ deltakerne har, men heller hvor forskjellige deltakerenes meninger er. Han sa også at kvinner er med på å øke intelligensen i grupper. Han ønsker derfor å fordele kvinner slik at det er minst en i hver gruppe.

Han avsluttet presentasjonen med å si at dette ikke er fasit for alle og anbefalte oss å gjøre det samme som han hadde gjort: Å sette opp 5 nøkkelprinsipper vi ønsker å forholde oss til. En kortere og noe eldre versjon av presentasjonen Five Considerations for Software Architecture og anbefales for interesserte. Han har også en publisert forskningsartikkel om temaet som kan lastes ned mot betaling.

Meetup er en samling av folk med tilsvarende interesser som møtes for å dyrke disse interessene.