Teknologiblogg

Vi ønsker kreative utviklere, utviklere som kan se problemer fra flere vinkler og forme løsningen på problemene. De fleste utviklere ønsker også å bidra til å forme løsningen de lager. De ønsker å tenke kreativt og komme frem til løsninger på problemer. Samtidig ønsker arkitektene gjerne å rettlede dem til å lage en løsning i tråd med visse arkitekturprinsipper. Denne jobben er ikke lett, og den faller gjerne på personen med rollen løsningsarkitekt eller teknisk arkitekt i prosjektet. Jeg har selv hatt denne rollen flere ganger, og har sett både vellykkede og mislykkede forsøk på akkurat dette. Hvordan kan man så dokumentere, og ”forkynne” god arkitektur i prosjekter?

En måte å dokumentere arkitektur på er å benytte seg av retningslinjer. Wikipedia definerer retningslinje (guideline) slik

A guideline is any document that aims to streamline particular processes according to a set routine. By definition, following a guideline is never mandatory (protocol would be a better term for a mandatory procedure). Guidelines are an essential part of the larger process of governance.

Med andre ord vil retningslinjene være et dokument som forteller utviklerne hvordan de skal løse problemet, samtidig som de må være generelle nok til å kunne benyttes på flere lignende problemstillinger. Som definisjonen sier er det aldri påkrevd å følge retningslinjene, noe som kan føre til at utviklerne ikke følger dem. Min erfaring tilsier at dette garantert vil skje dersom retningslinjene er dårlige, om de fører til mye unødvendig arbeid eller dersom utviklerne føler at de ikke blir hørt ved utarbeidelse av retningslinjene.

Det er mye enklere å få utviklerne på laget "ditt" dersom du lar de være med å utforme løsningen, folk har en tendens til å misjonere for det de har vært med å skape selv. Videre har jeg smertelig erfart at det er veldig vanskelig å få utviklere til å følge retningslinjer bare fordi det er retningslinjer. Retningslinjene må tilføre noe for at de skal bli fulgt og utvikleren må føle at de ”gjør noe riktig”, at de utvikler en god løsning, når de følger retningslinjene. Det må ikke bli slik i et prosjekt at arkitekten svarer ”fordi det er en retningslinje som sier det” når utvikleren spør ”hvorfor gjør vi det slik?”.

Hvordan kan man så dokumentere gode retningslinjer? Jeg har erfart flere måter for dokumentasjon:

1. En side på Wiki eller et dokument en eller annen plass. Man samler alle regningslinjene på wiki, og dokumenterer de som ren tekst der
2. Kode med tilhørende forklaring. Kan kombineres med Wiki der man forklarer problem, løsning og begrunnelse for valgt løsning på Wiki, mens man viser det i praksis ved hjelp av et kodeeksempel

Av disse to har jeg mest positiv erfaring med kode, deretter Wiki og lite positiv erfaring med dokumenter på et fileshare. Wiki gir fordeler i at det er editerbart av alle, lett tilgjengelig og innbyr til samarbeid. Aller best erfaring har jeg med å dokumentere arkitektur i kode, og legge ved forklarende sider på en Wiki der det er nødvendig. Template pattern er effektivt for nettopp dette. Ved å benytte seg av en template/mal i koden innbyr du til å videreutvikle/foredle retningslinjene samtidig som du dokumenterer de på en meget konsis og enkel måte. Det er vrient å misforstå kode, mens det samtidig er svært vrient å formulere seg presist nok i et dokument eller på en wiki-side.

Hvordan kan du da utvikle en mal (template) i koden på best mulig måte? Arkitekten kan selvfølgelig skrive den, sjekke den inn i versjonskontroll og be utviklerne benytte den. Jeg har ikke så god erfaring med dette, noe jeg tror har sin rot i at utviklerne ikke føler seg involvert i prosessen med å utarbeide retningslinjene. ”Parprogrammering” av mal har jeg derimot meget god erfaring med. Man kan for eksempel benytte en code-dojo for å samle de ledende utviklerne i prosjektet til å utvikle malen/retningslinjen i fellesskap. Får man ikke til å utvikle en mal kan man forsøke å utvikle et ”stjerne-eksempel” som kan benyttes til å kikke på når man utvikler løsningen. På denne måten kan man raskt, enkelt og demokratisk utvikle et forslag til arkitektur og kodestruktur for prosjektet ved å involvere utviklerne. Når det er sagt bør man ikke gå så langt at man utvikler egne interne rammeverk for alt mulig (som diskutert tidligere i denne bloggen). Finfin balansegang kreves med andre ord..

Lykke til ;-)