web-intro
  • Introduction
  • Introduksjon
    • Introduksjon
    • Din første nettside
      • Hello World
      • DevTools
  • Grunnleggende webutvikling
    • HTML
      • Elementer
      • Head og body
      • Semantikk
      • Bilder
      • Lenker
      • Knapper
      • DOM-en
    • CSS
      • Selectorer
      • Pseudo-klasser
      • Box model
      • Flyt
      • Layout
      • Responsivt
    • JavaScript
      • Filer
      • Variabler
      • Typer og operatorer
      • Strenger
      • Funksjoner
      • Listeoperasjoner
      • DOM-apiet
      • Promises
      • Async/await
      • Web-APIer
      • ESNext
      • Rammeverk
  • Neste steg
    • Universell utforming
    • React
    • Utviklingsmiljø
      • Dytt det til skyen!
    • Best practices
      • Linting og formatering
      • Code review
      • Keep it simple, stupid!
    • Flere ressurser
Powered by GitBook
On this page
  1. Neste steg
  2. Best practices

Code review

De fleste prosjektene våre (mest sannsynlig alle), har git som versjonskontrollsystem. Uavhengig om det er Bitbucket, GitHub eller hva dere bruker på deres prosjekt: Lag pull requests når du legger til nye features, og la noen code reviewe den før den går i master.

Pull requests er ikke bare viktig for å få tilbakemelding på koden din og for å fange opp potensielle feil, men også for at minst en annen på teamet er klar over hva som går inn i produksjon. Da er det også flere som har ansvar hvis noe mot formodning feiler når det er merget inn, og flere som kan vite hva som muligens forårsaket feilen. Man kan også lære masse av å code reviewe andres pull requests.

Hør hva som er praksis på ditt prosjekt, men vi anbefaler så mye code review som mulig og pull requests (prq) på det aller meste. Det gjelder også de med mer senioritet enn dere! Å ninjae inn endringer i kodebasen uten at noen andre har vært involvert er ukult, uavhengig av hvor lang fartstid man har.

PreviousLinting og formateringNextKeep it simple, stupid!

Last updated 6 years ago