Oppgave: Dokumentasjonspublisering
Uferdig, TODO:
- Bryt opp til flere sider?
- Opprett utgangspunktrepo
I denne oppgaven skal du bruke prinsippene fra CI/CD for å opprette en GitHub workflow som publiserer dokumentasjon til et programmeringsprosjekt opp mot GitHub pages. Også kjent som Continuous Documentation Deployment.
God dokumentasjon pleier å inneholde følgende:
- Oversikt over prosjektet
- Installasjon
- Bruksinstrukser (kodereferanser / schema)
- Endringslogg (Changelog)
- Lisens
- Credits
Du kan ta utgangspunkt i følgende GitHub repository: (TBD, mangler link)
OBS: GitHub Classroom
Sjekk om du finner en GitHub Classroom link til oppgaven i Teams, eller be om å få det. Ved å besvare oppgaven i GitHub Classroom kan du publisere til GitHub Pages uten å måtte publisere repositoriet.
Hvorfor dokumentasjon?
Fremgangsmåte
For å få mest utbytte av oppgaven anbefales det å følge stegene under.
Det anbefales å bruke mkdocs
og Markdown sider for å gjennomføre oppgaven, men det finnes alltid alternativer!
Sjekk ut lenkene, de er i seg selv gode eksempler på dokumentasjon.
1. Forstå koden
Før man kan skrive dokumentasjon, må man forstå hva formålet bak koden er. Tenk gjennom når du leser koden: Hva, hvorfor og hvordan? Hva gjør koden? Hvorfor ble den skrevet, til hvilket formål? Hvordan kan man ta den i bruk?
2. Konfigurer dokumentasjonstjenesten
Før du skriver dokumentasjon, så kan det være lurt å teste ut noen andre sin dokumentasjon først! Bruk dokumentasjonen til å finne ut hvordan du konfigurerer tjenesten.
Dersom du ønsker å bruke mkdocs, bør du følge dokumentasjonen: https://squidfunk.github.io/mkdocs-material/creating-your-site/
Eller så kan du se den i form av en YouTube tutorial (start fra 3:26, du finner tilsvarende funksjonalitet i PyCharm):
Merk at en YouTube video er ikke alltid like oppdatert, men er ofte enklere å fordøye.
3. Skriv dokumentasjonen
Det kan være lurt å begynne med å skrive tekst i et tekstbehandlingsprogram, eller direkte som en Markdown fil (.md
) i utviklingsmiljøet i en egen docs
mappe. Dersom dokumentasjonen angår kodens funksjoner eller klasser, vil det være lurt å skrive denne direkte i kodefilene i form av docstrings (se under), eventuelt kommentarer.
Din dokumentasjon bør inneholde følgende:
index
- Oversikt over prosjektet, hva er det?Installation
- Hvordan installerer man? (Kan være en del av index)Usage
- Hvordan bruker man? (Kan være en del av index)Code Reference
- Hvordan fungerer koden? Hva gjør de ulike funksjonene? Se også: https://mkdocstrings.github.io/
Eksempel docstring i kode
Det finnes ulike standarder for docstrings, noen av de mest vanlige er Google og Sphinx sin standard, eller NumPy for mer matematiske prosjekter.
I PyCharm er Sphinx brukt som standard docstringformat, som er brukt i eksemplene under.
Se for deg at vi har følgende kode:
og tenk, hvor enkelt er det å forstå koden?
Her er samme kode med en docstring:
Lettere å forstå formålet til koden nå, ikke sant? Merk at koden ville egentlig hatt mer nytte av å brytes opp i mindre funksjoner for å slippe å måtte forklares grundig gjennom en docstring.
Type hinting og variabelnavn er også en form for “dokumentasjon”
I eksemplene er det brukt type hinting i funksjonens parametre, som forteller utviklingsmiljøet hvilke verdier som forventes av funksjonen. Ved å definere tydelige klasser blir man også mindre avhengig av å lese dokumentasjon; koden i seg selv er en del av kommentarene.
Eksempel:
vs.
4. Opprett en GitHub Workflow
Ved å opprette en Workflow fil (under GitHub Actions) kan man lage instrukser til en GitHub Runner, som spinner opp en virtuell maskin og utfører oppgaver for oss. Workflowene må lagres i en egen mappe i repoet: .github/workflows/
og være i .yml
format.
Dersom du allerede har laget en workflow fil via videoen trenger du ikke forholde deg til koden under. Så lenge den blir publisert, så er alt OK! 😄
GitHub Actions kan være skremmende til å starte med, men heldigvis kan du benytte deg av forhåndsdefinerte maler, eller ta utgangspunkt i denne filen, det er lagt inn kommentarer der du kan fritt gjøre endringer. Merk at runneren tar utgangspunkt i mkdocs
:
Om GitHub Workflows
GitHub Workflows kan være skremmende, og ofte krever de mye prøving og feiling. Det er vanskelig å tyde hva de ulike linjene egentlig gjør, eller hvilket formål de egentlig har, som f.eks. ${{ steps.deployment.outputs.page_url }}
.
Det finnes dog bare en måte å bli klokere på dette på, og det er å lese dokumentasjonen 😜
5. Verifiser GitHub Pages
Inne på GitHub repoet skal du nå finne en Environment
fane i menyen, dersom steg 3 var vellykket.
Trykk deg inn på denne for å finne linken til dokumentasjonen din. Fungerer den? Ser noe rart ut?
Dersom alt fungerer, kan du oppdatere repoet til å inkludere en link. Vis derretter dokumentasjonen til en annen og be om tilbakemelding. Er det noe som kan formuleres enklere?
6. Forbedre dokumentasjonen
Dersom du har mer tid, kan du prøve å forbedre dokumentasjonen din etter tilbakemeldingene du har fått.
Du kan også prøve å legge til illustrasjoner, bilder eller annet innhold, the ☁ is the limit!