Console.log for nye utviklere: slik bruker du logging til å skjønne hva koden gjør

Mange som lærer seg å kode, hopper rett til avanserte rammeverk og verktøy, men sliter likevel med det mest grunnleggende: å forstå hva koden faktisk gjør mens den kjører. Her er enkel logging medconsole.loget av de viktigste hjelpemidlene du har.

I denne artikkelen ser vi på hvordan du kan bruke logging systematisk for å feilsøke, lære og få kontroll på flyten i egne programmer, uansett språk eller verktøy.

Hva betyr det å logge i kode?

Å logge betyr å skrive ut informasjon om hva programmet gjør, til et sted der du kan lese det: en terminal, nettleserkonsoll, en loggfil eller et panel i editoren din. Målet er ikke pene meldinger, men nyttig informasjon som hjelper deg å forstå tilstanden i programmet.

I nettleserutvikling erconsole.log()den vanligste måten å logge på. I andre språk finnes lignende funksjoner, men prinsippet er likt: du skriver ut tekst og verdier underveis i programmet for å se hva som faktisk skjer.

Hvorfor er logging så nyttig for læring?

Når du er ny i programmering, er det lett å tro at du har forstått koden, helt til den gjør noe annet enn du forventet. Logging gir deg et «røntgenbilde» av programmet mens det kjører, slik at du kan sammenligne det du trodde skulle skje med det som faktisk skjer.

Dette gjør tre ting enklere: du ser rekkefølgen på operasjoner, du ser de faktiske verdiene variablene har, og du oppdager tidlig hvor ting begynner å avvike. Det gir raskere læring og færre mysterier.

En enkel strategi: logg før og etter noe viktig

En god grunnregel er å loggerett førogrett etternoe som er viktig: en beregning, et API-kall, en databaseoperasjon eller en funksjon som gjør mye arbeid. Da kan du se både inngangsdata og resultat.

En typisk sekvens kan være: logg input, kjør funksjonen, logg output. Hvis output er feil, vet du at problemet ligger inne i funksjonen. Hvis input allerede er feil, må du lete lenger bak i kjeden.

Gjør loggene dine lett å lese

Mange skriver bareconsole.log(data)og håper de husker hva «data» betyr senere. Det blir fort uoversiktlig. Gi hver loggmelding en kort, tydelig etikett som sier hva du ser på.

Et godt mønster er å kombinere tekst og verdi. I de fleste språk kan du skrive noe tilsvarende dette mønsteret:

Eksempel på god vs. dårlig logging:

• Dårlig:console.log(user)
• Bedre:console.log(‘User after login:’, user)

Når du senere blar gjennom konsollen, kan du raskt se kontekst og slippe å gjette hvilken del av koden loggen kom fra.

Bruk logging til å forstå flyten i programmet

En vanlig feilkilde er at koden ikke kjører i den rekkefølgen du tror. Dette skjer spesielt når du har betingelser, funksjonskall og asynkronitet. Logging er perfekt for å sjekke rekkefølgen.

En enkel teknikk er å nummerere steg i loggen, for eksempel «Step 1:», «Step 2:». Hvis du ser at «Step 3» dukker opp før «Step 2» i konsollen, vet du at det skjer noe asynkront eller at du har misforstått rekkefølgen.

Bruk logging til å sjekke antakelser

Mye feilsøking handler om antakelser: «denne funksjonen kjøres bare én gang», «denne variabelen er aldri tom», «dette API-kallet svarer alltid raskt». Logging lar deg teste slike antakelser uten avanserte verktøy.

Du kan for eksempel logge hver gang en funksjon kalles, eller logge verdien til en variabel før du bruker den. Hvis loggen viser noe annet enn det du forventet, har du funnet et viktig spor.

Typiske mønstre der logging hjelper raskt

Her er noen situasjoner der bevisst logging nesten alltid gir klarhet, spesielt når du er i startfasen:

• Datakonvertering: Logg verdier før og etter parsing, formatering eller typekonvertering.
• Validering: Logg hvilke regler som slår inn, og hvilke felt som feiler.
• Tilstand i apper: Logg når tilstand endres, sammen med gammel og ny verdi.
• API-kall: Logg URL, inputdata, statuskode og en kort del av svaret.

Poenget er å fange de stedene der data skifter form eller betydning. Det er ofte der feil oppstår.

Rydd opp i loggingen før du leverer kode

Det er lett å falle i fellen der man lar alle midlertidige loggmeldinger stå igjen. For læring og eksperimentering er det helt greit, men i kode som skal deles med andre eller kjøres i produksjon, bør du rydde.

En grei vane er å bruke to nivåer: midlertidige loggmeldinger som du sletter når du har funnet feilen, og mer varig logging som er strukturert, bevisst og gjerne samlet i egne hjelpefunksjoner eller et logging-bibliotek.

Utvikle egne vaner for god logging

Etter hvert som du blir mer erfaren, vil du utvikle en egen stil og egne «standardmeldinger». Poenget er ikke å logge mest mulig, men å logge akkurat nok til at du raskt finner ut hvor problemene ligger.

En god øvelse er å ta et lite prosjekt du allerede har, legge inn bevisst, navngitt logging på sentrale steder og så kjøre programmet mens du leser konsollen som en fortelling. Du vil ofte oppdage ting du ikke la merke til før.

Neste steg videre fra console.log

Når du har blitt komfortabel med enkel logging, kan du utforske mer avanserte verktøy som innebygde debuggere, breakpoint-funksjoner i editorer og dedikerte loggbiblioteker. De bygger alle videre på samme idé: synliggjør hva som skjer, når det skjer, og med hvilke data.

Selv da vil du ofte komme tilbake til en enkel loggmelding for å bekrefte en mistanke raskt. Derfor er det verdt å lære seg gode vaner med logging allerede fra første dag.