Design

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare

Design er en pågående jobb som programmerer. Det handler om å ta stilling til hvilke undersystemer som kan skilles ut som selvstendige komponenter, hvordan disse skal kommunisere, og på et lavere nivå, hvilke datastrukturer og abstraksjoner vi trenger. Målet med ethvert design er å finne en robust løsning som slår en god balanse mellom fleksibilitet, og kost i form av hvor lang tid det tar å komme i mål.

Et godt design tåler å få nye, uventede krav stilt mot seg uten å kollapse; altså at man må skrive om hele eller store deler av løsningen for å komme i mål. Et godt design tar også hensyn til at systemet skal driftes og leve videre etter at det første utviklingsprosjektet er over.

Mange Kodemakere har hatt rollen arkitekt i prosjekter, og i denne rollen har man det formelle ansvaret for det overordnede designet i systemet. Også de av oss som ikke har hatt den formelle rollen arkitekt har mange tanker og meninger om programvaredesign, noe som både kommuniseres til våre omgivelser i det daglige såvel som gjennom foredrag på konferanser og andre fagsamlinger.

Våre anbefalinger

The reuse dilemma

Johannes Brodwall tar et oppgjør med utviklernes oppheng i gjenbruk av kode. Kan det bli for DRY? Les artikkelen

React: Rethinking best-practices

Pete Hunt, en av hodene bak JavaScript UI-rammeverket til Facebook og Instagram, React, forteller om tankene bak. Foredraget fra JSConf.eu 2013 utfordrer en del etablerte sannheter og presenterer en måte å tenke på web-frontend-programmering på som sammenfaller med klassisk UI-programmering og som virkelig fokuserer på separation of concerns. Se foredraget

On the Spectrum of Abstraction

Rich Hickey har noen fantastiske talks. Han snakker om generelle prinsipper, og gir deg ofte noen nye konsepter og ord du kan bruke til å tenke med rundt programmering.

Det er ikke ofte jeg ser talks av andre enn Hickey som har denne typen øye-åpnende innhold, men dette er en. Det er litt knot og kluss i starten, men det tar seg veldig opp. Han introduserer noen spissede begreper (power vs usefulness / properties) og bruker de til å snakke om abstraksjonnivåer på en veldig interessant måte. Mye godt tankemateriale her. Anbefales! Se foredraget

Inventing on principle

Fantastisk foredrag av Brett Victor. Programmering er et kreativt yrke. Det er antageligvis mye lettere å være kreativ dersom man kan ta, se, observere og endre helt fritt og dynamisk på et kjørende program. Hadde det ikke vært digg å kunne spole tilbake det du nettopp gjorde i appen din, endre noen parametere og så kjøre på nytt. Kanskje tom for å sammenligne. Dette foredraget var bl.a med på å inspirere mye av tankene rundt verktøy som Light Table og programmeringspråket Elm Se foredraget

The Future of JavaScript MVC Frameworks

David Nolen, Clojurescript-superstjerne, forteller om sitt ‘Om’, Clojurescript-API over Facebook’s React. Om går enda noen skritt fra hva React tilbyr ved å servere hele pakka med immutable datastrukturer og et funksjonelt API. Artikkelen viser samtidig hvordan dagens mest populære MVC-rammeverk for JavaScript er langt fra å tilby en tilfredstillende løsning på problemene vi som frontendutviklere møter. Les artikkelen

Dance you Imps!

Uncle Bob Martin skriver et knallgodt innlegg om hvordan ORM-er ikke egentlig er ORM-er. Dette sitatet oppsummerer på mange måter hovedpoenget:

«What is a data structure? It’s a bunch of public data with no methods. Compare that to an object which is a bunch of public methods with no visible data. These two things are the exact opposites of each other!» Les artikkelen

Programming Antiobjects

Et foredrag på OOPSLA-konferansen i 2006 satt tradisjonell objektorientering og simulering litt på hodet. Istedenfor å la objektene leve sitt eget liv og styre seg selv, kan man gi liv til omgivelsene rundt dem. Lukten av Pacman setter seg i spillbrettet, og det er brettet som styrer spøkelsene etter Pacman. Lukten av fotballen sprer seg i gressmatten, og spillerne blir sendt i retning av den. Oppgaven deres blir å sparke ballen vekk fra stanken fra det andre laget. Det gir interessante omganger fotball, særlig hvis det er flere baller på banen. Les artikkel

Simple Made Easy

Det er ikke lett å lage noe enkelt. Rich Hickey snakker om forskjellen på nærliggende (subjektivt lett) og ukomplisert (objektivt enkelt). Og implikasjonene for hvordan du bør tenke rundt software. Se foredraget

Test-driven JavaScript Development

Dette foredraget av Christian Johansen var en grunnene til at jeg i stor grad kastet jQuery-scripting på båten. En inspirerende og lærerik testdrevet sesjon hvor man lager en autocomplete-komponent. Se foredraget

Våre bloggposter

Programming like a pirate

Jeg utfordrer clean-code-prinsippet om å ekstrahere all kode ut i metoder med kun et par linjer. Det er noen fallgruver man bør passe seg for. Les posten

Future proof

Tanker og anbefalinger om hvordan gjøre en applikasjon lettere å jobbe med over tid. Les posten

Hvem og hva er det vi kjemper imot

Problemene vi står overfor med IT-utvikling i offentlig sektor. Les posten

Losing loose coupling

Om verdien ved å begrense hva en applikasjon gjør, å bestemme seg for en implementasjon og funksjonalitet. Les posten

Reuse? Refuse

Gjenbrukbarhet kan føre til lavere kvalitet og dårligere brukeropplevelser. Les posten

Våre presentasjoner

JavaScript design and architecture

En liten inspirasjonsprat om å finne gode abstraksjoner for frontend-programmering Se video Se slides

Test-driven JavaScript Development

En praktisk gjennomgang av TDD i JavaScript. Foredraget er en times live-kode-sesjon der jeg lager et autocomplete/type-ahead søk, test-first. Se video

Readable code

Når det gjelder kode - er lett å lese det samme som god? Se video

Sustainable code - what they don't teach you

En applikasjon koster mer å forvalte enn å utvikle. Likevel blir de fleste kodebaser optimalisert for arbeidet gjort i prosjektfasen før prodsetting. Jeg kommer med noen tanker rundt hva vi kan gjøre annerledes for å gjøre applikasjoner lettere å forvalte. Se video

Smidige utviklere spør ikke om råd

Smidig utvikling handler om å være reaktiv fremfor proaktiv. Istedenfor å analysere i forkant, validerer man antakelsene sine fortløpende. Vi må slutte å be om avklaringer i forkant og heller test ut teoriene våre og sjekke om de faktisk fungerer i virkeligheten. Se video

De første delleveransene skal være stygge

I smidig produktutvikling er det viktig med fortløpende validering av løsningen. Man vil finne potensielle feil raskt. Man skal ikke vente med at applikasjonen er ferdig før man viser den. Det at de første leveransene er mangelfulle er en del av den nødvendige prosessen og må ikke sees som feil. Se video

16 minutter om Pure Functions

Jeg snakker hva, hvorfor og hvordan om Pure Functions, i et utbrudd av entusiasme etter å ha jobbet med en kodebase basert på disse prinsippene et par år. Se video

Open source

Christian utviklet UseCase. Strukturerte abstraksjoner for ikke-triviell programflyt. Biblioteket ble opprinnelig skrevet for å redusere kompleksiett i Ruby on Rails-applikasjoner, men er ikke spesifikt avhengig av Rails. Biblioteket reduserer koblinger mellom modeller og kontrollere, og kan potensielt redusere kompleksiteten i begge betraktelig.