Kodgranskning, håll det enkelt och lättsmält

Det finns flera olika anledningar till att man använder sig av kodgranskningar i mjukvaruutveckling. Några vanliga exempel är p.g.a. säkerhetskrav, kvalitetskrav eller för att bidra till kunskapsspridning inom ett team.

Vanligvis kan en kodgranskning ske som ett mellansteg innan ändringar accepteras in i en kodbas, t.ex. innan en pull- eller merge-request accepteras.

Det är här som exempelvis andra medlemmar i ett team ska läsa och förstå ändringen för att sedan kunna ge feedback i form av ett godkännande eller nekande. Om ändringen inte går att förstå eller om något är felaktigt kan man självklart ställa frågor eller föreslå förändringar. Men varje extra steg gör också att hela processen tar mer tid och energi från deltagarna.

Drar man paralleller till metodiker inom agil utveckling så kan man kanske se kodgranskning som en feedback-loop som riskerar att bli väldigt långsam. Om det är möjligt kanske man vill minska loopen genom att synka med teamet ofta eller kanske rentutav par- eller mobbprogrammera tillsammans.

Skall man genomföra kodgranskningar bör ett viktigt mål vara att göra granskningen så pass tydlig och enkel som möjligt.

Vid en granskning behöver en granskare åtminstone ta ställning till följande:

  • Förståelse (Går det att förstå vad ändringen gör?)

  • Korrekthet (Är denna ändring korrekt utifrån problembeskrivingen?)

Båda dessa punkter blir svårare och svårare ju mer komplicerad ändringen är. Håll därför ned komplexiteten på det enklast möjliga sättet: Genom att bryta ner ändringarna i mindre bitar.

Att bryta ner ändringarna i mindre och mer hanterbara delar är inget nytt. Denna förmåga är välgrundad inom DevOps-sfären och empiriskt bevisad att den bidrar till en högre utvecklingstakt. Läs mer

Så, gör det tydligt vad en granskare bör fokusera på i en kodändring.
Håll det enkelt och lättsmält.

Tips: Håll ändringar separata

En vanlig anledning till att kodändringar kan vara svåra att förstå är att man gör flera ändringar samtidigt. Även om ändringarna är helt funktionellt separata så måste man som granskare ta till sig och förstå om de olika delarna av koden faktiskt påverkar varandra. Om ändringarna inte påverkar varandra, gör det då tydligt genom att granska dem separat.

Tips: Försök arbeta mot mindre och tydligare ändringar

Även om det leder till fler kodgranskningar så borde de sammanlagt ta mindre tid och samtidigt vara enklare att förstå och ta till sig.

Föregående
Föregående

Academy Master Program Cloud Security

Nästa
Nästa

DevOps-loopen och "Release on Demand"