Varför ska vi granska kod?

by Calle Tuvesson - 22/08/2016 - 15:44

Att uveckla mjukvara involverar ofta fler människor som jobbar i ett team. Under tiden som mjukvaran växer i kod så gäller det att hålla samtliga medlemmar i teamet à jour. Det gäller även att hålla kodbasen fri från buggar och annat oönskat beteende. Bästa sättet att göra detta är genom att granska kod med så kallade code reviews.

Varför granska kod?

Så, varför ska vi bry oss om att granska kod? Frågan bör istället omformuleras till "Vad är fördelen med att granska kod?". Fördelarna är flera:

- Hitta buggar tidigt, billigare att åtgärda fel tidigt i projektet
- Korrekt kodstandard, kodgranskning säkerställer att koden följer de standarder som finns.
- Lära ut och dela på kunskapen, medarbetare får bättre förståelse för kodbasen.

Att uföra en code review innebär att man granskar den kod som skrivs. Detta görs ofta under projektets gång för att tidigt upptäcka fel och för att alla i arbetsteamet ska veta vilka förändringar som görs i koden.

En code review utförs när en utvecklare antingen är klar med en isolerad beståndsdel – t.ex. att en användare ska kunna ladda upp en profilbild – eller när ett fel (en "bugg") betraktas som löst. När man utför en kodgranskning så kollar man efter flera olika saker för att säkerställa kvalité och att syftet med koden uppfylls, följande områden granskas:

- Finns det några logiska fel?
- Uppfyller implementationen den tekniska kravspecifikationen?
- Följer den skrivna koden givna kodstandarder?

Ovanstående är sådant som en dator kan ha svårt att upptäcka och korrigera själv och behöver därför mänsklig handpåläggning för att förhindra fel.

Varf%F6r%20ska%20vi%20granska%20kod

Code reviews i praktiken

För några månader sedan arbetade jag och Olof, som också är utvecklare hos oss på Odd Hill, på ett långtgående projekt som ställde höga krav på kvalité och tillförlitlighet. Därför togs det beslut på att all kod som skrevs skulle granskas. Arbetet delades upp i tre olika områden, innehållshantering, kontohantering samt försäljning.

De olika områdena delades upp i mindre beståndsdelar och funktioner. När en beståndsdel ansågs som färdigutvecklad av den ena utvecklaren, granskades koden av den andre för att ett par nya och fräscha ögon skulle se koden. Mer än ofta kunde förslag på förbättringar ges och flertalet buggar kunde elimineras.

I slutet av projektet märkte vi att varje minut vi spenderade på att granska kod betalade tillbaka sig tiofalt.

Det här är bara ett exempel av många där vi på Odd Hill märkt en förbättring av kvalitén i ett projekt vid införandet av s.k. code reviews. Vi kan verkligen varmt rekommendera arbetssättet för alla som arbetar med kod i produktion.

written by

Odd Hill