Mentorointi ja tekninen dokumentaatio
Kehitä junioritiimikavereita pariohjelmoinnilla ja oikea-aikaisella palautteella, kirjoita arkkitehtuuripäätöksistä ADR:t ja ylläpidä ajantasaista dokumentaatiota, johon muut voivat luottaa.
Mentorointi ja tekninen dokumentaatio on ilmainen Frontend Academy-oppitunti CoddyKitissä. Tämä on oppitunti 3/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Frontend Academy-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Frontend Academy-kurssilla on yhteensä 4 oppituntia.
Seniorina tehtäväsi on vahvistaa muita
Senior-tasolla tehtäväsi ei ole kirjoittaa eniten koodia, vaan tehdä tiimistäsi parempi. Ohjaa junioreita, kirjoita tietämystäsi laajentavaa dokumentaatiota, tee opettavia koodikatselmointeja ja muotoile arkkitehtuuria niin, että muut voivat edetä nopeasti ja turvallisesti.
Mentorointi pariohjelmoinnin avulla
Pariohjelmointi on nopein tapa auttaa junioria kehittymään. Istukaa yhdessä tai jakakaa näyttö, ja anna hänen ohjata samalla kun navigoit. Vastusta tarvetta ottaa ohjat käsiisi — selitä ajattelusi ja esitä sokraattisia kysymyksiä.
Sopivan haastavat tehtävät
Anna junioreille tehtäviä, jotka ovat hieman heidän nykyisen osaamistasonsa yläpuolella. Liian helppo tehtävä ei kehitä. Liian vaikea hukuttaa ja turhauttaa. Arvioi sopiva taso: 'Uskon, että pystyt tähän pienellä avulla — voin mielelläni tehdä pariohjelmointia, jos jäät jumiin.'
Koodikatselmointi opetustilanteena
Selitä juniorien PR:issä jokaisen ei-triviaalin kommentin taustalla oleva syy. Linkitä asiaankuuluvaan dokumentaatioon, aiempiin PR:iin tai artikkeleihin. Huono katselmointi: 'käytä useCallbackia'. Hyvä katselmointi: 'Tämä funktio luodaan uudelleen jokaisella renderöinnillä — memo'd-lapselle välitettynä se aiheuttaa tarpeettomia uudelleenrenderöintejä. useCallback memooi funktion. Tässä on esimerkki-PR, jossa teimme näin: #1234'.
Arkkitehtuuripäätösten tietueet (ADR:t)
ADR dokumentoi merkittävän arkkitehtuuripäätöksen: mitä päätimme, miksi, mitä vaihtoehtoja harkitsimme ja mitä kompromisseja hyväksyimme. Tulevaisuuden sinä kiität nykyistä sinää.
# 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: ...Missä ADR:t säilytetään
Säilytä ADR:t repositoriossa hakemistossa docs/adr/ ja numeroi ne juoksevasti. Ne sijaitsevat kuvaamansa koodin rinnalla. Työkaluja ovat adr-tools ja log4brains, joka tarjoaa selattavan verkkokäyttöliittymän.
README:n laatu
Jokainen paketti, kirjasto ja merkittävä toiminnallisuus tarvitsee README:n. Sisällytä siihen: mitä se tekee, miten se asennetaan, miten sitä käytetään (koodiesimerkkien kera), miten siihen osallistutaan, miten testit suoritetaan ja miten ongelmia selvitetään. README-vetoinen kehitys tarkoittaa, että README kirjoitetaan ensin ja toteutus rakennetaan sen määrittelyä vastaavaksi.
Koodin sisäiset kommentit — milloin niitä käytetään
Kommenttien pitäisi selittää miksi, ei mitä. Koodi näyttää mitä tapahtuu. Kommentit selittävät liiketoimintasäännöt, epäselvät kompromissit, linkit tiketteihin tai virheisiin sekä varoitukset sudenkuopista.
// 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++;Toimintaohjeet ylläpitotehtäviin
Dokumentoi toistuvien tai riskialttiiden ylläpitotehtävien suorittaminen: 'Miten Stripe API -avain vaihdetaan', 'Miten epäonnistuneesta käyttöönotosta palaututaan', 'Miten hitaasti vastaavaa API:a selvitetään'. Uudet tiimin jäsenet voivat toimia ohjeiden mukaan ilman, että heidän tarvitsee pyytää sinua apuun.
Elävä dokumentaatio
Vanhentunut dokumentaatio on pahempaa kuin dokumentaation puuttuminen. Päivää dokumentit. Tarkista ne neljännesvuosittain. Poista dokumentit, joita kukaan ei päivitä. Vielä parempi vaihtoehto on luoda dokumentaatio koodista: Storybook komponenteille, TypeDoc API:lle ja OpenAPI päätepisteille.
Teknologiakatsaukset ja brown bag -esitykset
Pidä tiimillesi 20–30 minuutin esityksiä oppimastasi: uudesta kirjastosta, virheenselvitystilanteesta tai hyödylliseksi havaitsemastasi mallista. Se pakottaa sinut jäsentämään ajatteluasi ja opettaa samalla muita.
Psykologisen turvallisuuden rakentaminen
Junioret, jotka pelkäävät kysyä, eivät kehity. Tee 'en tiedä' -ilmauksesta normaali. Luo turvallinen ilmapiiri virheiden tekemiseen — juhlistakaa jälkipuintia, älkää syyllistäkö. Seniorina reaktiosi määrittävät tiimin ilmapiirin.
Sankarillisen koodaamisen ansa
Älä ole se henkilö, joka korjaa jokaisen tuotantohäiriön yksin. Dokumentoi korjaus, tee seuraavalla kerralla pariohjelmointia tiimikaverin kanssa ja automatisoi vian selvitys. Tiimi, joka tarvitsee sankaritekojasi, on haavoittuva.
Pikatarkistus
Mikä on arkkitehtuuripäätöksen tietueen (ADR:n) ensisijainen tarkoitus?
Kertaus: mentorointi ja dokumentaatio
Seniorina vahvistat muita etkä kirjoita eniten koodia. Tee pariohjelmointia, opeta koodikatselmoinneilla ja anna sopivan haastavia tehtäviä. Hakemiston docs/adr/ ADR:t tallentavat, miksi päätökset tehtiin. Jokaiselle paketille tarvitaan README. Kommentit selittävät miksi, eivät mitä. Toimintaohjeet auttavat ylläpitotehtävissä. Elävä dokumentaatio (Storybook, TypeDoc, OpenAPI) on parempi kuin staattinen Markdown. Rakenna psykologista turvallisuutta. Vältä sankarillista koodaamista.
Opi HTML tekoälytuutorin avulla — ilmaiseksi
Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.
- Kurssit
- 41
- Oppitunnit
- 163
Usein kysytyt kysymykset
Onko oppitunti ”Mentorointi ja tekninen dokumentaatio” ilmainen?
Kyllä – oppitunnin ”Mentorointi ja tekninen dokumentaatio” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Frontend Academy-kurssin, päivitä CoddyKit PROhon. Frontend Academy-kurssilla on yhteensä 4 oppituntia.
Mitä opin oppitunnilla ”Mentorointi ja tekninen dokumentaatio”?
Kehitä junioritiimikavereita pariohjelmoinnilla ja oikea-aikaisella palautteella, kirjoita arkkitehtuuripäätöksistä ADR:t ja ylläpidä ajantasaista dokumentaatiota, johon muut voivat luottaa. Harjoittelet Frontend Academy-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.
Tarvitsenko kokemusta aloittaakseni Frontend Academy-opiskelun?
Aiempi kokemus ei ole tarpeen. CoddyKitin Frontend Academy-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 3/4.
Kuinka kauan ”Mentorointi ja tekninen dokumentaatio”-oppitunnin suorittaminen kestää?
Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.
Voinko kirjoittaa ja suorittaa koodia tällä Frontend Academy-oppitunnilla?
Kyllä. Jokainen Frontend Academy-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.
Kaikki tämän kurssin oppitunnit
- Frontend-järjestelmäsuunnittelun haastattelut
- Koodikatselmointikulttuuri ja PR-käytännöt
- Mentorointi ja tekninen dokumentaatio
- Ajan tasalla pysyminen: spesifikaatioiden ja ehdotusten lukeminen