Frontend Academy · Lektion

Mentorskap och teknisk dokumentation

Utveckla juniora kollegor genom parprogrammering och väl avvägd återkoppling, skriv ADR:er för arkitekturbeslut och underhåll levande dokumentation som andra kan lita på.

Lektion 3 av 415 steg

Mentorskap och teknisk dokumentation är en gratis lektion i Frontend Academy på CoddyKit. Detta är lektion 3 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Frontend Academy, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Frontend Academy innehåller totalt 4 lektioner.

Senioritet handlar om att få andra att växa

På seniornivå är ditt jobb inte att skriva mest kod — det är att göra teamet bättre. Handled juniora utvecklare, skriv dokumentation som skalar din kunskap, gör kodgranskningar som lär ut och forma arkitekturen så att andra kan arbeta snabbt och säkert.

Handledning genom parprogrammering

Parprogrammering är det snabbaste sättet att utveckla en junior utvecklare. Sitt tillsammans (eller dela skärm) och låt personen styra medan du navigerar. Motstå frestelsen att ta över — förklara hur du tänker och ställ sokratiska frågor.

Utmaningar i rätt storlek

Ge juniora utvecklare uppgifter som ligger precis över deras nuvarande förmåga. För lätt = ingen utveckling. För svårt = övermäktigt och frustrerande. Anpassa nivån: ”Jag tror att du kan klara det här med lite hjälp — jag arbetar gärna tillsammans med dig om du kör fast.”

Kodgranskning som undervisning

Förklara varför bakom varje icke-trivial kommentar i juniora utvecklares PR:ar. Länka till relevant dokumentation, tidigare PR:ar eller artiklar. Dålig granskning: ”använd useCallback”. Bra granskning: ”Den här funktionen skapas om vid varje rendering — när du skickar den till ett memo:iserat barn orsakar det onödiga omrenderingar. useCallback memorerar den. Här är ett exempel på en PR där vi gjorde detta: #1234”.

Architectural Decision Records (ADR:er)

En ADR dokumenterar ett viktigt arkitekturbeslut: vad vi beslutade, varför, vilka alternativ vi övervägde och vilka avvägningar vi accepterade. Ditt framtida jag kommer att tacka ditt nuvarande jag.

# ADR-0007: Use TanStack Query for server state

Date: 2026-05-01
Status: Accepted

## Context
We currently scatter useEffect+fetch+useState patterns across the app.
Cache invalidation is inconsistent, race conditions cause stale data.

## Decision
Adopt TanStack Query (@tanstack/react-query v5) for all server state.

## Consequences
+ Built-in caching, deduplication, optimistic updates.
+ Standard pattern across team.
- Adds ~13KB gzipped.
- Team needs to learn query keys conventions.

## Alternatives Considered
- SWR: smaller, but fewer features (no mutations).
- Apollo Client: overkill (we don't use GraphQL).
- Custom hook: doesn't solve cache invalidation.

## References
- React Query docs: ...

Var ADR:er finns

Förvara ADR:er i docs/adr/ i repot och numrera dem i ordningsföljd. De finns tillsammans med koden de beskriver. Verktyg: adr-tools och log4brains för ett webbaserat gränssnitt som går att bläddra i.

README-kvalitet

Varje paket, bibliotek och större funktion behöver en README. Ta med: vad den gör, hur den installeras, hur den används (med kodexempel), hur man bidrar, hur tester körs och hur man felsöker. README-driven utveckling: skriv README-filen först och bygg sedan enligt den specifikationen.

Inline-kommentarer i kod — när ska de användas

Kommentarer ska förklara varför, inte vad. Koden visar vad. Kommentarer förklarar: affärsregler, icke-uppenbara avvägningar, länkar till ärenden och buggar samt varningar om fallgropar.

// BAD: comment restates the code
// Increment counter by 1
counter++;

// GOOD: comment explains business context
// Stripe webhook can arrive twice — increment only if signature is fresh.
// See: https://stripe.com/docs/webhooks/best-practices#idempotency
if (!seen.has(event.id)) counter++;

Runbooks för operativa uppgifter

Dokumentera hur återkommande eller riskfyllda operativa uppgifter ska utföras: ”Så roterar du Stripe API-nyckeln”, ”Så återhämtar du dig efter en misslyckad driftsättning”, ”Så felsöker du ett långsamt API-svar”. Nya teammedlemmar kan följa instruktionerna utan att behöva kontakta dig.

Levande dokumentation

Föråldrad dokumentation är sämre än ingen dokumentation alls. Datera dokumenten. Granska dem varje kvartal. Ta bort dokumentation som ingen uppdaterar. Ännu bättre: generera dokumentation från koden (Storybook för komponenter, TypeDoc för API:er och OpenAPI för endpoints).

Teknikföredrag och brown-bags

Håll 20–30 minuter långa föredrag för teamet om sådant du har lärt dig: ett nytt bibliotek, en felsökningsberättelse eller ett mönster du haft nytta av. Det tvingar dig att strukturera dina tankar och lär samtidigt andra.

Skapa psykologisk trygghet

Juniora utvecklare som är rädda för att ställa frågor utvecklas inte. Normalisera ”jag vet inte”. Skapa en miljö där det är tryggt att göra misstag — uppmärksamma efteranalysen, inte skulden. Som senior utvecklare sätter dina reaktioner tonen för teamet.

Fällan med heroiskt kodande

Var inte personen som ensam löser varje produktionsincident. Dokumentera lösningen, arbeta tillsammans med en kollega nästa gång och automatisera diagnostiken. Ett team som behöver dina hjälteinsatser är skört.

Snabb koll

Vad är det huvudsakliga syftet med en Architectural Decision Record (ADR)?

Sammanfattning: handledning och dokumentation

Senioritet = att få andra att växa, inte att skriva mest kod. Arbeta i par; lär ut genom kodgranskning; ge utmaningar i rätt storlek. ADR:er i docs/adr/ fångar varför beslut fattades. README-filer för varje paket. Kommentarer förklarar varför, inte vad. Runbooks för operativa uppgifter. Levande dokumentation (Storybook, TypeDoc, OpenAPI) slår statisk markdown. Skapa psykologisk trygghet. Undvik heroiskt kodande.

Gratis att börja

Lär dig HTML med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
41
Lektioner
163

Vanliga frågor

Är lektionen ”Mentorskap och teknisk dokumentation” gratis?

Ja – hela texten till ”Mentorskap och teknisk dokumentation” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Frontend Academy, kan Ni uppgradera till CoddyKit PRO. Kursen i Frontend Academy innehåller totalt 4 lektioner.

Vad lär jag mig i ”Mentorskap och teknisk dokumentation”?

Utveckla juniora kollegor genom parprogrammering och väl avvägd återkoppling, skriv ADR:er för arkitekturbeslut och underhåll levande dokumentation som andra kan lita på. Ni övar på Frontend Academy med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Frontend Academy?

Du behöver inga förkunskaper. Utbildningen i Frontend Academy på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.

Hur lång tid tar lektionen ”Mentorskap och teknisk dokumentation”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Frontend Academy-lektionen?

Ja. Varje Frontend Academy-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Systemdesignintervjuer för frontend
  2. Kodgranskningskultur och bästa praxis för PR
  3. Mentorskap och teknisk dokumentation
  4. Håll dig uppdaterad: läs specifikationer och förslag
← Tillbaka till Frontend Academy