kode24-klubbens 3.170 utviklere har gjennom sommeren utvikla en fiktiv webapplikasjon sammen; brus.no.
Flertallet har så langt valgt:
- Vue.js som frontend-rammeverk
- Firestore som database
- Firebase for autentisering
- Node.js for API-ene
- DigitalOcean for hosting
"Men ojsann, det viser seg at det er en bug i frontendkoden! Sjefen er i harnisk, du griper etter dine faste verktøy og arbeidsmetoder for å fakke bug-en, spørsmålet er bare: Hva er de?" spurte vi sist.
Her er norske utvikleres svar, på hvilke metoder og verktøy de ville brukt for å håndtere en feil i produksjon.
#1: Verktøy 🔨
Mange av utviklerne har konkrete verktøy å ty til, utover standardverktøyene som "F12 i Chrome".
- Sentry er ganske fint. Med litt forskjellige varslingsregler kan man gjerne agere før det påvirker altfor mange brukere, og ofte fikse feilen før noen rekker å ta kontakt, skriver Alexander Karlstad på kode24-klubben.
- La Sentry rapportere til Opsgenie for å gi beskjed til on-call hvis det er mange som opplever problemet, samt tagge release slik at det blir enklere å finne nye feil, tipser Eirik Stenestø Tenold.
Sentry loggfører feil fortløpende, for eksempel i en webapplikasjon, og du får en kjapp oppsummering av verktøyet her:
Flere nevner også verktøyet Postman.
- Sentry, Postman, Fiddler, console.log, Wireshark, Chrome og remote debugging, oppsummerer Kenneth Hauklien.
Postman lar deg blant annet debugge API-ene dine, og her ser du et eksempel på hvordan det fungerer med GraphQL:
Flere sier også at de har blitt glade i Azure Application Insights, som selv hevder å "automatically detect performance anomalies, and includes powerful analytics tools to help you diagnose issues and to understand what users actually do with your app".
«Bruker Elm. Finnes ikke bugs i produksjon!»
#2: Server-logger 🧾
En god, gammel traver i feilsøking er server-logger, og flere utviklere skriver at de fortsatt sverger til slik rådata.
- Har sjelden behov for å debugge backend-kode i produksjon. Det meste som kan skje er enten ganske åpenbart, eller noe man vet om fra før. Eventuelt kan man se i logger, og teste seg frem til problemet ved å skrive unit-tester som dekker eventuelle teorier man har. Testene kan så debugges i Visual Studio når det er reprodusert, skriver Christian Lundheim.
Nettsida til Hallvard har over 53 millioner poster
Slike logger kan typisk inneholde informasjon om hver forespørsel til serveren din, som data du selv må håndtere.
Eventuelt kan du også her få hjelp av egne verktøy, som går gjennom server-loggene dine for deg.
Eller, selvfølgelig enda bedre, gjøre som Eirik Sletteberg påstår:
- Bruker Elm. Finnes ikke bugs i produksjon!
#3: console.log() ✍
En av de tidligste artiklene våre på kode24 var "Slutt å bruke console.log!". Det var ikke vår oppfordring, men ett av punktene Christian Heilmann hadde for å bli en lykkeligere Javascript-utvikler.
Vi har ikke fulgt oppfordringen selv, og er ikke alene.
- Ingenting slår trioen console.log('test'), console.log('faen'), og console.log('kuk') plassert på tre strategiske steder, skriver Fredrik Alexander de Lange, etterfulgt av en solbrille-emoji.
Han får støtte fra kode24s fagredaktør Jørgen i ukas episode av kode24-timen.
- Det er min favoritt. Eller, jeg gjør "test1", "test2" og "test3", forteller han i podcasten.
- Men av og til skriver jeg bare ut "test" to steder, og da får jeg problemer.
- Slutt å bruke console.log!
7 tips til et lykkeligere Javascript-liv.