«Principle of least surprise» referer til at brukere, eller i vårt tilfelle utviklere, ikke skal bli overrasket over hvordan noe fungerer.
Metaprogrammering er ofte assosiert med det motsatte.
Jeg vet ikke hvor mange ganger jeg har hørt utviklere snakke ned .NET namespacet System.Reflection, nettopp på grunn av dette.
Mystiske .NET MAUI forklart: - Ikke for alle
"Gull"
Akkurat System.Reflection er kanskje mitt favoritt namespace, “and whats not to like”:
All den vakre koden vi skriver beholder masse metadata om typene man lager, hva slags metoder, properties og andre medlemmer som er på typene og masse annet snadder. Og alt dette kan vi skrive i kode som kan lese og finne ut masse om programmet som kjører.
Dette er gull hvis man for eksempel ønsker å se på egenskaper på typer som for eksempel holder PII (Personal Identifiable Information), som du kan benytte i rapportering og til og med automatisere håndteringen av fjerning av PII ved logging eller kryptering ned til databasen.
Dykker man litt dypere i .NET så ser man enda flere muligheter til å ikke bare plukke opp metadata, men også generere kode. Dette kan jo da gjøre det lettere å for eksempel «slå på» sikkerhet på typer basert på namespace eller lignende på kryss, og på denne måten få til en “zero trust” tilværelse.
Med .NET Platform Compiler SDK, også kjent som Roslyn APIs, så kan vi til og med gjøre alt på compiler nivå. Det har jo da fordelen av at det ikke går utover performance ved runtime.
En annen ting med compile-time er at man da kan generere andre ting utfra koden, for eksempel PII-rapporter, eller som vi gjør; TypeScript-kode for hele API-surfacen vår, med enda bedre match på typer enn hva en Swagger til TS kodegenerator typisk vil gi.
Færre sikkerhetshull i JavaScript-kode enn i Java og .NET
Kommer langt med README.md
Tilbake til “principle of least surprise”. Jeg er helt enig; det å sette seg inn i en ny kodebase, og koden på sett og vis ikke gjør det man forventer, er bare frustrerende.
Men betyr det at vi ikke skal kunne benytte oss av ting som kan potensielt gjøre løsningene våre sikrere, gjøre oss mer produktive og sørge for at vi leverer mer helhetlig og konsekvent som team?
Dokumentasjon og onboarding tror jeg er nøkkelen for å kunne benytte metaprogrammering og litt strøssel med magi. Man kommer langt med en god README.md fil i repoet og gjennomgang for nye utviklere.
«Selvfølgelig, det er tradeoffs og absolutt alt kan ende opp med å bli en kraftig pistol å skyte seg selv i foten med.»
Vi omgir oss allerede av en hvis grad av magi med ting som kommer fra tredjepart, bare i ASP.NET blir jo ting automagisk konfigurert for oss i større og større grad, og vi velger å syns det er greit nettopp fordi det er godt dokumentert og kommunisert, IMO. Etter min erfaring er det slik at det er en fremmed ting til å begynne med og etterhvert så vil man bare ha mer.
Selvfølgelig, det er tradeoffs og absolutt alt kan ende opp med å bli en kraftig pistol å skyte seg selv i foten med, så man må bruke det omhu. Teamet må være komfortabel med det, og man må se reell forbedring ved å dra nytte av metaprogrammering.
Jeg er såpass glad i dette at jeg endte opp med å prøve å fange alle scenariene jeg har benyttet selv gjennom min karriere i en bok som er på vei ut butikkhyllene i disse dager.
#JustInTimeForSummer :)
Ha en fabelaktig god sommer, og tenk litt meta (nei, ikke den metaen).
