5 vragen & antwoorden over code review - Eaglescience
  • 12 juni 2020

5 vragen & antwoorden over code review

5 vragen & antwoorden over code review

5 vragen & antwoorden over code review 1000 1000 Eaglescience

Een code review levert inzichten op over de kwaliteit van bestaande code, en brengt bijvoorbeeld verborgen risico’s en kwetsbaarheden en aan het licht. Hierdoor kan onder andere de kwaliteit en levensduur van de code verhoogd worden en bovendien is kwalitatief betere code ook efficiënter te onderhouden. De combinatie van ervaring, expertise en het gebruik van specialistische technieken maakt ons de juiste partij voor het uitvoeren van code reviews.

Meer weten? Lees dan onderstaande vragen & antwoorden!

5 vragen & antwoorden over code review

  1. Wat is een code review?

Een review is een ‘assessment’ van een (software) product, meestal bestaat dit uit een stuk code. Het is vergelijkbaar met het reviewproces in de wetenschap: een peer (dus een andere developer) gaat na of het klopt, of er aan afspraken wordt voldaan en of de kwaliteit voldoende is.

  1. Wat hebben wij in huis waardoor we een goede code review kunnen doen?

Eaglescience heeft jarenlange ervaring met het bouwen van (complexe) softwareproducten. Het reviewproces is een standaard onderdeel van onze werkwijze, wij zijn daardoor ervaren in het geven van feedback over door andere geproduceerde code. We hebben ervaring met verschillende technieken, architecturen en domeinen, waardoor we weten wat wel en niet werkt. Dit gaat over de voorkant en achterkant van een app of website, maar ook procesmatig zoals agile ontwikkelwijze en processen.

  1. Wat zijn de voordelen van een code review?

De voornaamste voordelen van een code review zijn nieuwe inzichten die vaak leiden tot flinke verbeteringen in het product. Denk bijvoorbeeld aan veiligheid en schaalbaarheid van de software. Bovendien neemt de onderhoudbaarheid bij kwalitatief betere code significant toe.

Vooral bedrijven die een project outsourcen en geen kennis in huis hebben over softwareontwikkeling zijn gebaat bij een code review. Hiermee wordt de stand van zaken en kwaliteit in kaart gebracht door een onafhankelijke partij. Vervolgens kan er beslist worden of ingrijpen noodzakelijk is of dat er verder ontwikkeld kan worden met de softwareleverancier.

De code review kan ingezet worden als second opinion, bijvoorbeeld als softwareleverancier X aangeeft dat een oplossing niet mogelijk, te duur of te complex is. Wij kijken dan vanuit onze ervaring of wij een alternatief zien.

Voor een MVP (minimum viable product) versie van een product kan gekeken worden of dit productwaardige code is, en niet tegen problemen aangelopen zal worden als de code onderhouden/uitgebreid gaat worden, of door meer gebruikers gebruikt zal worden.

  1. Hoe verloopt een code review?

De eerste stap is dat wij met een softwareontwikkelaar op hoog niveau door de code gaan. Vervolgens zal een senior ontwikkelaar van Eaglescience de code op verschillende criteria beoordelen.

Bijvoorbeeld:

  • Architectuur: het in kaart brengen van componenten en architectuur van software (bijv: zijn het microservices of is het een monolitische architectuur). Hoe is er omgegaan met de knelpunten van de architectuur?;
  • Gebruikte technieken (past de taal- en techniekkeuze bij het project of doel?);
  • Complexiteit van code (leesbaarheid, opdeling, scheiding van verantwoordelijkheden en kwaliteit domeinmodel);
  • Kwaliteit van documentatie (zowel code documentatie als externe documenten);
  • Kwaliteitsbewaking op code (style checks, automatische checks op achterstallige versies van libraries);
  • Automatische tests en dekkingsgraad;
  • Deployment (bv: is het makkelijk om uit te rollen, wordt er een ontwikkelstraat gebruikt, wordt Docker gebruikt of wordt een cloudplatform gebruikt);
  • Schaalbaarheid (hoe schaalt de applicatie en wat zijn mogelijke bottlenecks?).

Tenslotte wordt er een rapport geschreven met aanbevelingen.

  1. Wanneer kan de code review plaatsvinden?

In principe kan een review op elk moment plaatsvinden, zodra er materiaal is om naar te kijken. Meestal is het in een latere fase, waarbij er al code aanwezig is om te bekijken maar nog niet werkend hoeft te zijn. Het kan echter ook eerder, bijvoorbeeld in de ontwerpfase om de keuzes te reviewen.