Tenk at du har jobbet med en applikasjon i flere måneder for å gjøre store datamengder tilgjengelig i et brukergrensesnitt. Du har lagd et utall funksjoner for å kunne manipulere dataene og tilby forskjellige visninger. Flere optimaliseringer er gjort for å kunne gi god ytelse og brukeropplevelse selv med så store datamengder. Du tar med deg applikasjonen for å gjøre en demonstrasjon for brukerne. Et stykke ut i demonstrasjonen sier en bruker: “Dette er fint, men jeg er egentlig bare interessert i avvik og anomalier i dataene...”
I mitt forrige blogginnlegg skrev jeg om Software Craftsmanship, og noe av det jeg håper du sitter igjen med er programvareutviklerens viktigste mål:
“Vårt mål er å løse forretningsproblemer i programvare. Vi bør alltid søke teknologi, teknikker og metodikk som best støtter problemet vi skal løse.”Verdi realiseres gjennom grensesnittene til programvaren vi lager. Det kan være grensesnitt mellom menneske og maskin, eller maskin til maskin. For brukere er grensenittet applikasjonen. Hva som befinner seg på innsiden er irrelevant så lenge det fungerer. I dette innlegget ønsker jeg å minne om (flere har skrevet om teknikken før, men den har sannsynligvis godt av mer oppmerksomhet) en metodikk vi bør ha i arsenalet når vi jobber med ikke-trivielle grensesnitt; Interface First eller Presentation First Development.
Teknikken er basert på en strategi om å begynne i det ytterste laget av programvaren vi skal lage. Slik jobber vi oss utenfra-og-inn, fra det som er verdiskapende til det som bør betegnes som infrastruktur.
Hvorfor jobbe utenfra-og-inn
Jeg liker å tenke på egenskaper ved systemarkitektur langs to akser; horisontalt og vertikalt. La oss se på potensielle fordeler ved å jobbe grensesnitt først langs disse to aksene.Den horisontale aksen definerer et systems funksjonalitet, eller systemets kontaktflate mot omgivelsene. Det er ikke sikkert våre brukere mener databaseskjemaets representasjon av data er en meningsfull abstraksjon, og hvordan vi lagrer data bør ikke diktere presentasjonen. Ved å begynne arbeidet utenfra, ofte i et brukergrensesnitt, kan vi bekrefte vår forståelse av problemet vi skal løse. Vi kan sørge for at vi lager den riktige funksjonaliteten, og dekker det viktigste først. Vi får realisert verdi og redusert risiko på et tidlig stadium.
Den vertikale aksen definerer de tekniske løsninger et system består av, fra det ytre grensesnitt til en eller annen datarepresentasjon. Det er langs denne aksen vi snakker om laginndeling, og av og til kanskje lar kompleksiteten ta overhånd? Hva er et minimum av teknisk infrastruktur for en typisk forretningsapplikasjon? Når bestemmer vi oss for hvilke typer teknologi, moduler og rammeverk vi bruker? Robert Martin sier at vi har en tendens til å gjøre det altfor tidlig, og at dette påvirker arkitektur i negativ retning. Som programmerer har du kanskje hørt om mantraet YAGNI. Har du tenkt på hvorfor vi har fått dette uttrykket? Vi programmerere har en tendens til å være spekulative, vi tror vi kommer til å trenge en implementasjon av <funksjonalitet X>, og bruker derfor verdifull tid på noe vi kunne utsatt til behovet faktisk oppstår. Ved å implementere et system utenfra-og-inn, kan vi bygge arkitektur rundt use caser og legge til infrastruktur når det identifiseres som en nødvendighet.
Hvordan komme i gang?
Mange er nok kjent med verdien av å gjøre low-fidelity prototyping for å billig kunne identifisere et effektivt brukergrensesnitt. Prøv også å implementere skjermbildene først! Der grensesnittet behøver data fra en tjeneste eller persisteringsmekanisme, definerer vi et grensesnitt og lager fasader som gir oss data å jobbe med selv om underliggende mekanismer ikke er ferdige. I teorien skal dette tillate oss å implementere applikasjonen ferdig før vi har besluttet hvordan vi skal lagre dataene vi jobber med! Det gir applikasjonsutviklerne den fordelen at de ikke behøver vente til teamet som leverer tjenester og data er ferdige, så lenge man har blitt enige om en kontrakt på forhånd.I praksis kan vi ha begrensninger som gjør at vi ikke velger å følge dette fullt ut, men poenget er likevel verdt å kommunisere. Målet til komponenter som understøtter applikasjoners grensesnitt bør være å levere det som skal til for at grensesnittene fungerer, og ingenting mer. Det er vanskelig å få til dette ved å begynne med et datalag.
