Blogg

code-review

Code reviewing utgjør en betydelig del av hverdagen til utviklere. De fleste er mest kjent med dette gjennom GitHub Pull Requests, hvor man presenterer endringsforslag for kolleger som deretter gir tilbakemelding. Måten man gir og mottar tilbakemeldinger på kan ha stor innvirkning på trivselen i teamet.

Selv om dette har vært en etablert praksis i lang tid, har jeg sjelden sett fokus på hvordan vi behandler hverandre i review prosessen. Mange bedrifter som ellers har omfattende retningslinjer, kan forsømme området som gjelder utvikler-til-utvikler kode-feedback. Dette fører ofte til en organisk dynamikk hvor enkelte dominerer, mens andre føler angst.

Den negative følelsen som mange opplever ved å få arbeidet sitt gransket av kolleger har nylig fått mer oppmerksomhet. Kliniske studier har undersøkt det som kalles Code Review Anxiety. Normativt har man kanskje tenkt at dette er mest vanlig blant juniorutviklere, men det viser seg også å være et vedvarende problem som er utbredt blant seniorer. Noen arbeidsplasser er også mer utsatt for dette enn andre.

Normer for Code Review

I møte med slike friksjoner ble et tidligere team jeg ledet enig om å lage et sett med regler for oppførsel. Jeg har senere introdusert dette temaet hos andre arbeidsplasser og tatt med meg malen videre.

Hensikten med å etablere disse reglene er at dersom alle er enige om en normativ måte å oppføre seg på, vil det både få utviklere til å tenke seg om når de skal gi tilbakemelding, samt skape noe håndfast å referere til dersom noen opplever at oppførsel ikke er i takt med hva man har blitt enig om.

Vi valgte å uttrykke disse reglene med eksempler på "god" og "dårlig" oppførsel, og de ble skrevet på engelsk for enklere overførbarhet. Kanskje noen av disse punktene ikke passer for deg og ditt team, men jeg ønsker gjerne å vise hva vi ble enige om 😌

0. Assume good faith

The zero index of whatever discussion you are approaching should always be that things are done in good faith. Likewise, when you as a developer read your feedback. Assume the person tried to chose their words in good faith.

1. Avoid using emojis and sarcasm to point out an issue

Example (bad): You are quoting a line and you only write 🙄 (eye roll). Also you repeat the same feedback more than once.

Example (good): Explain the benefit of doing this in another way and provide an example

2. Ask questions, give recommendations and suggestions to drive dialogue. Don’t force the developer into a defensive position

Example (bad): You are indicating that something is wrong, but not providing anything for the receiver to respond to

Example (good): You share your observation and suggest an action

3. Avoid presenting a claim as fact

Example (bad): You are claiming there should be no reasons for choosing an older version of something

Example (good): You are claiming it would be better to use a newer version of React, but are open to reasons for why thats not the case here

4. Avoid asking judgmental questions

Example (bad): Even though you are providing detailed feedback of improvement, you are judging the person and not the code

Example (good): You are addressing the code, not the developer, and how it could be improved

5. Don’t be surprised if people don’t know as much as you do

Example (bad): Even though the suggestion is valid, you express almost disbelief that a co-developer did not have the same knowledge as you

Softer wording in the suggestion, and explaining the benefit achieved by using the technique.

6. Try to answer all of the comments, even though you disagree

Example (bad): Remember, people have taken their time to give you feedback. Try to make sure you have addressed everyone before merging, failing to do so might make the commenter feel ignored.

Avluttende

Å etablere klare normer for code reviews kan bidra til en mer positiv og produktiv arbeidskultur. Ved å være bevisst på hvordan vi gir og mottar tilbakemeldinger, kan vi fremme et mer støttende miljø. Jeg oppfordrer alle team til å diskutere og enes om egne retningslinjer for å sikre en sunn og konstruktiv prosess :)

Referanser

• Unlearning toxic behaviors in a code review culture
• 7 tips for better Code Reviews
• Code Review Anxiety Workbook

• Pull Request
• Metode
• Utvikling