Læring uten herping
et prinsipp for utvikling av programmer, systemer og produkter
Hvordan gjør vi en ting bedre? Det er et overraskende vanskelig spørsmål med et enkelt svar: vi forbedrer uten å forverre.
Målet er altså:
- kontinuerlig læring og verdiskaping
- uten herping.
Kontinuerlig læring og verdiskaping forutsetter at vi kan forme om virkeligheten. At vi ikke skal herpe det til for folk forutsetter at det vi lager er pålitelig, og at fundamentet det til vi lager står på også er pålitelig.
Å forme om i isolasjon er lett: kast terning og rull ut! Tilsvarende er pålitelighet i isolasjon lett: bare la det være. Utfordringen er hvordan vi får til begge to samtidig.
formbarhet og pålitelighet
Målet er formbar og pålitelig programvare. Vi kan forme om programvaren etter behov, uten at omformingen senker påliteligheten.
Hvordan gjør vi det i praksis med koden vår? Vi har to alternativer:
-
Vi former koden ved å endre eksisterende kode, og passer på at vi ikke brekker ting.
-
Vi former koden ved å legge til ny kode ved siden av eksisterende kode. Påliteligheten er sikret ved at eksisterende, levert oppførsel er uendret.
Jeg foretrekker nummer to, fordi den er lettest. Pålitelighet er løst som default i systemet vårt. Når vi legger til ny funksjonalitet, slipper vi utilsiktet tukling med eksisterende funksjonalitet. Da er det mindre som kan gå galt, og lettere for meg å gjøre jobben min.
additiv programmering
Denne programmeringsdisiplinen kalles additiv programmering av Chris Hanson og Gerald Sussman i Software Design for Flexibility. Det gjør vi ved at vi løser for forgrening rett i systemdesignet, og unngår flere og flere nøstede if-setninger. Hanson og Sussman viser noen eksempler i boka, deriblant generisk dispatch og layering. Generisk dispatch og layering er sinnsykt spennende teknikker, men dekkes ikke i denne teksten.
dataorientert dispatch
Christian og Magnar har etablert en annen dispatch-teknikk i Mattilsynet-kodebasen vår. Benny Andresen omtalte denne som “ekstrem dataorientering”. Alternativt kunne vi snakket om “dataorientert dispatch”. Sidesystemet vårt er et eksempel. Sidedefinisjonene ser slik ut:
{:page/id :pages/statistikk
:page/route ["statistikk"]
:page/render #'render}
Systemet blir additivt fordi nye sider legges til additivt. Ny render-funksjon. Nytt hash-map. Ingen nye if-er.
Sidedefinisjonene gir oss også ett sted å løse siderelaterte problemer. Vi bruker sidedefinisjonene til å lage routeren. Men vi bruker også sidedefinisjonene til å lage sidekartet (“sitemap”).
etterord: Sussman om formbarhet
Software Design for Flexibility (“Programvaredesign for formbarhet”) er kanskje den beste boka om design av programvare som ingen har lest. Java-standarden ble skrevet av Guy Steele, Sussman var veilederen til Steele. Eksemplene i boka er skrevet i Lisp-dialekten Scheme, som Sussman designet. Det gir inngansterskel! Men han valgte ikke Scheme for å være vrang. Han ville formidle rene konsepter og trengte et enkelt språk. Scheme er et av de enkleste språket som finnes.
Personlig ser jeg på Software Design for Flexibility som et mesterverk. Ja, den krever litt innsats for å komme inn i. I liket med de fleste tingene i livet som er verd å gjøre. Og det er greit.
Les heller én tekst som er verdt å lese enn å skumme over ti tekster du egentlig ikke bryr deg om. Hvis du må ha det som kulturelt Clojure-sitat, simplicity ain’t easy. Å lage enkle systemer krever innsats. Å holde systemer enkle krever innsats. Den innsatsen må du velge å legge ned.
etterord: formbarhet og pålitelighet når LLM-er tukler med koden
Industrien vår har sniffet LLM, og volumet på festen er stigende. Folka som danser på stranda har ikke ennå sett søpla som ansamler seg rett bak klippene. Hvorvidt hver og én av oss klarer å nyttiggjøre oss LLM-ene kommer til å bli bestemt av formbarhet og mykhet i kodebasen vår. Kalsifiserer LLM-en kodebasen med vaghet og leoparder som gjør den uleselig? Gjør LLM-en kodebasen upålitelig, og akkumulerer bugs ingen klarer å finne? Eller klarer vi å holde på mykheten og formbarheten? Gråskjegg som Kent Beck og Steve Yeggie sier de får til nettopp det, og oppskriften de gir er ikke å la LLM-en gå amok. Ikke lukk øynene. I stedet, bli enda bedre på formbarhet og pålitelighet i kode. Bli tydeligere API-design og tydeligere teststrategi. Pålitelighet gir formbarhet, og formbarhet lar deg komme videre.
