Codebeoordelingen zijn belangrijk omdat ze de kwaliteit van de code verbeteren en uw codebasis stabieler maken. Daarnaast helpen ze programmeurs om relaties op te bouwen en effectiever samen te werken.
Maar het beoordelen van de code van een collega is makkelijker gezegd dan gedaan. Om nog maar te zwijgen van het feit dat het uitvoeren van een reviewproces een nachtmerrie kan zijn voor teamleiders. Daarom leggen we uit waar je op moet letten bij een code review, hoe het code review-proces verloopt en wat de negen best practices voor code review zijn.
Lees mee of spring vooruit naar het deel dat u het meest interesseert:
- Code Review Best Practices
- Peer Code Review Best Practices
- Code Review Best Practices For How to Run a Code Review
- Toepassen Code Review Best Practices Met de juiste tools
- ▶️ Start Your Static Code Analysis Free Trial
Code Review Best Practices
Hier zijn de negen code review best practices:
1. Weet waar je op moet letten bij een code review
2. Bouw en test – voor de review
3. Review code niet langer dan 60 minuten
4. Controleer niet meer dan 400 regels tegelijk
5. Geef feedback die helpt (niet schaadt)
6. Communiceer doelen en verwachtingen
7. Betrek iedereen bij het code-reviewproces
8. Koester een positieve cultuur
9. Automatiseer om tijd te besparen
Peer Code Review Best Practices
We vertellen je de best bewaarde geheimen van peer reviews. Bij peer reviews gaat het om samenwerking, niet om concurrentie.
Volg deze vijf best practices voor peer code review.
Waar moet je op letten bij een code review
Het is belangrijk om aan een review te beginnen als je weet waar je op moet letten. Kijk naar belangrijke dingen, zoals…
Structuur. Stijl. Logica. Prestaties. Testdekking. Ontwerp. Leesbaarheid (en onderhoudbaarheid). Functionaliteit.
Voor sommige zaken – bijvoorbeeld structuur en logica – kun je geautomatiseerde controles uitvoeren (bijv. statische analyse). Maar voor andere zaken, zoals ontwerp en functionaliteit, is een menselijke beoordelaar nodig.
Het beoordelen van code met bepaalde vragen in gedachten kan u helpen om u op de juiste dingen te richten. U zou code bijvoorbeeld kunnen beoordelen op de volgende vragen:
- Begrijp ik wat de code doet?
- Functioneert de code zoals ik verwacht?
- Voldoet deze code aan de wettelijke vereisten?
Door code kritisch te beoordelen – met de vragen in gedachten – weet u zeker dat u op de juiste dingen controleert.
Build en Test – Vóór Code Review
In het huidige tijdperk van Continuous Integration (CI) is het van groot belang om te bouwen en te testen voordat u een handmatige review uitvoert. In het ideale geval, nadat de tests zijn geslaagd, voer je een review uit en implementeer je het naar de dev codelijn.
Dit zorgt voor stabiliteit. En door eerst geautomatiseerde controles uit te voeren, verminder je het aantal fouten en bespaar je tijd in het reviewproces.
Automatisering voorkomt dat u tijd verspilt aan beoordelingen.
▶️ Start uw gratis proefperiode voor statische code-analyse >>>
Bekijk code niet langer dan 60 minuten
Bekijk code nooit langer dan 60 minuten aan een stuk. Na die tijd nemen de prestaties en de aandacht voor details af. Het is beter om vaak (en in korte sessies) te reviewen.
Een pauze geeft uw hersenen de kans zich te resetten. Zo kunt u het met een frisse blik nog eens doornemen.
Door uzelf de tijd te geven om korte, frequente controles uit te voeren, kunt u de kwaliteit van de codebase verbeteren.
Controleer niet meer dan 400 regels tegelijk
Als u te veel regels code in één keer controleert, is de kans kleiner dat u fouten vindt. Probeer elke revisiesessie te beperken tot 400 regels of minder. Het instellen van een line-of-code (LOC) limiet is belangrijk om dezelfde redenen als het instellen van een tijdslimiet. Het zorgt ervoor dat u op uw best bent wanneer u de code controleert.
Door u op minder dan 400 regels te concentreren, worden uw beoordelingen effectiever.
Geef feedback die helpt (niet schaadt)
Probeer opbouwend te zijn in je feedback, in plaats van kritisch. Je kunt dit doen door vragen te stellen in plaats van uitspraken te doen. En vergeet niet om naast je constructieve feedback ook complimenten te geven.
Het persoonlijk geven van feedback (of zelfs het persoonlijk uitvoeren van je beoordeling) helpt je om met de juiste toon te communiceren.
Jouw code zal altijd moeten worden beoordeeld. En je zult altijd de code van je collega’s moeten beoordelen. Als je reviews benadert als een leerproces, wint iedereen.
📕 Verwante bron: Developer Challenge: Zijn uw codebeoordelingen effectief?
Code Review Best Practices For How to Run a Code Review
Het uitvoeren van een codebeoordeling – en ervoor zorgen dat alles goed is beoordeeld – kan een enorme uitdaging zijn.
Volg deze vier best practices voor het uitvoeren van een code review.
Communiceer Doelen en Verwachtingen
Je moet duidelijk zijn over wat de doelen van de review zijn, en ook over de verwachtingen van de reviewers. Door uw reviewers een checklist te geven, zorgt u ervoor dat de reviews consistent zijn. Programmeurs zullen elkaars code beoordelen met dezelfde criteria in het achterhoofd.
Door doelen en verwachtingen te communiceren, bespaart iedereen tijd. Reviewers weten waar ze op moeten letten – en ze kunnen hun tijd tijdens het reviewproces verstandig gebruiken.
Betrek iedereen bij het code-reviewproces
Hoe senior de programmeur ook is, iedereen moet reviewen en gereviewd worden. Iedereen presteert tenslotte beter als hij weet dat iemand anders naar zijn werk kijkt.
Wanneer je reviews uitvoert, is het het beste om zowel een andere engineer als de software architect erbij te betrekken. Zij zien verschillende problemen in de code, zowel in relatie tot de bredere codebase als tot het algehele ontwerp van het product.
Door iedereen bij het beoordelingsproces te betrekken, verbetert u de samenwerking en de relaties tussen programmeurs.
▶️ Start uw gratis Helix Swarm-proefperiode >>>
Kweek een positieve cultuur
Het is belangrijk om een positieve cultuur rondom reviews te stimuleren, omdat ze een vitale rol spelen in de kwaliteit van het product. Het maakt niet uit wie de fout heeft geïntroduceerd. Waar het om gaat is dat de bug is ontdekt voordat hij in het product terechtkwam. En dat moet worden gevierd.
Door een positieve cultuur te stimuleren, zult u uw team helpen beoordelingen te waarderen (in plaats van te vrezen).
Automatiseren om tijd te besparen
Er zijn een aantal dingen die beoordelaars bij handmatige beoordelingen moeten controleren. Maar er zijn ook dingen die automatisch kunnen worden gecontroleerd met de juiste hulpmiddelen.
Statische code-analysers, bijvoorbeeld, vinden potentiële problemen in code door deze te toetsen aan coderingsregels. Door static analyzers op de code los te laten, wordt het aantal problemen dat de peer review fase bereikt, tot een minimum beperkt. Het gebruik van tools voor lichtgewicht reviews kan ook helpen.
Door geautomatiseerde tools te gebruiken, kunt u tijd besparen in het peer-reviewproces. Dit maakt reviewers vrij om zich te richten op problemen die tools niet kunnen vinden, zoals bruikbaarheid.
📕 Verwante inhoud: Hoe u codebeoordelingen uitvoert
Toepassen van best practices voor codebeoordeling met de juiste tools
Als u best practices voor codebeoordeling wilt afdwingen, hebt u de beste tools nodig.
Een betere code review begint met Perforce tools
Perforce heeft tools om uw reviewproces van begin tot eind te verbeteren.
Hoe Perforce Static Analyzers Code Reviews vanaf het begin verbeteren
Perforce Static Analyzers – Helix QAC voor C/C++ en Klocwork voor C, C++, C# en Java – kunnen worden gebruikt om code te analyseren en coderingsfouten te elimineren voordat de code in de peer review-fase komt.
Beiden zorgen ervoor dat uw code voldoet aan de coderingsregels. En het markeert en prioriteert problemen die moeten worden opgelost, zodat programmeurs efficiënter kunnen zijn in het beoordelingsproces.
Reviewers kunnen hun annotaties in de broncode toevoegen – samen met de diagnostische berichten van de Perforce Static Analyzers. En programmeurs ontvangen meldingen wanneer de Static Analyzers problemen vinden die betrekking hebben op hun deel van de code.
Hoe Helix Swarm samenwerking eenvoudiger maakt
Helix Swarm is een webgebaseerde tool voor het beoordelen van code, die wordt meegeleverd met Helix Core. U kunt het gebruiken om reviews te schalen naarmate uw team groeit en de samenwerking tijdens het proces te verbeteren.
Helix Swarm maakt het eenvoudig om reviews uit te voeren door het proces te automatiseren. Teams kunnen deze tool gebruiken om de voortgang te bewaken en te zien welke volledig zijn – en welke nog in uitvoering zijn.
Reviewers krijgen automatisch meldingen over hun taken en een dashboard met hun actie-items. Bovendien kan iedereen eenvoudig samenwerken door direct in de code gesprekken te voeren. Ontdek zelf hoe Helix Swarm u kan helpen.
▶️ Bekijk een Helix Swarm-demo
Enforce Code Review Best Practices With Static Analysis
De statische code-analysers van Perforce – Helix QAC en Klocwork – en Helix Swarm zijn geïntegreerd met Jenkins en andere buildrunners. U kunt dus builds en tests uitvoeren voorafgaand aan uw peer review cycli.
Het gebruik van Perforce code review tools elimineert wachttijd en helpt u beter samen te werken gedurende het proces. Ontdek zelf hoe de Perforce statische analyzers u zullen helpen.
▶️ statische code analyse gratis uitproberen