Codebeoordelingsoefeningen: hoe gebruik je collegiale toetsing om je analyse- en technisch oordeelsvermogen te ontwikkelen?

Een ontwikkelaar opent een pull request om een ​​kortingsberekening toe te voegen aan een afrekenservice. De tests slagen en de diff is klein. Een reviewer keurt het binnen twee minuten goed met "LGTM". Drie maanden later moet een teamgenoot dezelfde functie aanpassen en ontdekt dat prijsregels, afronding en toegang tot de database op één plek gecombineerd worden. Niemand kan met zekerheid zeggen wat er wel en niet is toegestaan.

Dit is een illustratief scenario, geen gedocumenteerd incident. Het laat zien wat peer code review moet opleveren wanneer het als leeractiviteit wordt gebruikt: een reviewer die een plausibele wijziging ziet, het probleem (dat nog geen bug is) herkent en het op een manier uitlegt waarop de auteur actie kan ondernemen.

Deze handleiding is bedoeld voor engineering enablement leads en engineering managers. Het laat zien hoe je dit kunt ontwerpen. code review oefeningen Die vaardigheden worden doelgericht ontwikkeld, in plaats van te hopen dat reviewers ze uit de wachtrij oppikken. Het behandelt het prestatieprobleem, de te diagnosticeren hiaten, hoe de voorbereiding en oefening gestructureerd moeten worden, een uitgewerkt voorbeeld en hoe te controleren of de vaardigheid ook in echte reviews wordt toegepast. Laat senior engineers elk geval, defect en criterium valideren voordat je het gebruikt.

Wat zijn codebeoordelingsoefeningen?

Code review-oefeningen zijn gestructureerde oefentaken waarbij een ontwikkelaar een voorbereide wijziging beoordeelt, uitlegt wat hij of zij heeft gevonden en waarom dit belangrijk is, en feedback krijgt op de kwaliteit van die uitleg. Ze verschillen van de reviews die je team dagelijks uitvoert. De wijziging is van tevoren gekozen, de aandachtspunten zijn bekend en het doel is om de reviewer te verbeteren in plaats van de wijziging te implementeren.

Faktenüberblick

1. Beschrijf het prestatieprobleem

Begin met de taak, in één zin: gegeven een wijziging, legt de beoordelaar uit wat hij/zij heeft gevonden, waarom het belangrijk is en wat de auteur eraan zou kunnen doen. "Uitleggen" is het cruciale woord. Een probleem signaleren is de helft van de vaardigheid. Het zo verwoorden dat een collega met een andere mening het kan begrijpen, afwegen en ernaar kan handelen, is de andere helft.

Onderzoek naar moderne codebeoordelingen ondersteunt het idee om verder te kijken dan alleen het opsporen van bugs. In een onderzoek bij Microsoft observeerden, interviewden en enquêteerden Bacchelli en Bird ontwikkelaars en managers. Ze ontdekten dat het vinden van defecten nog steeds de belangrijkste motivatie voor een beoordeling was, maar dat beoordelingen minder over defecten gingen dan men verwachtte. Beoordelingen leverden ook andere voordelen op, zoals kennisdeling, teambewustzijn en alternatieve oplossingen. De onderzoekers beschreven het begrijpen van code en wijzigingen als het belangrijkste aspect van een beoordeling.Bacchelli en Bird, ICSE 2013Het betreft een onderzoek naar de teams van één bedrijf, dus gebruik het als reden om te ontwerpen met begrip als uitgangspunt, niet als maatstaf voor jouw eigen aanpak.

De gepubliceerde beoordelingsstandaard van Google wijst in dezelfde richting. Daarin wordt reviewers aangeraden een wijziging alleen goed te keuren als deze de algehele kwaliteit van de code aantoonbaar verbetert, zelfs als deze niet perfect is. Ook staat erin dat review ontwikkelaars iets nieuws kan leren, dus opmerkingen die iemand helpen leren zijn welkom.Google Engineering-praktijkenBeide bronnen beschrijven een beoordeling als een plek waar een oordeel wordt geveld en doorgegeven. Dat is wat je oefeningen zouden moeten oefenen.

2. Stel de leer- en contexthiaten vast.

Vergelijk de opdracht met wat er in je huidige programma wordt geoefend en beoordeeld.

1. Wordt in de huidige praktijk gebruikgemaakt van de daadwerkelijke taak? Als nieuwe reviewers leren door een stijlgids te lezen en vervolgens daadwerkelijke pull requests te beoordelen, oefenen ze met echt werk zonder een veilige omgeving waarin ze fouten kunnen maken. Als de beoordeling een quiz is over review-etiquette, meet deze het onthouden van de regels, niet het vermogen om ze toe te passen op een wijziging.
2. Wat is de cognitieve belasting? In de herziene taxonomie van Bloom valt het beoordelen of een ontwerp deugdelijk is en het afwegen van de voor- en nadelen ervan onder de niveaus 'analyseren' en 'evalueren', terwijl het voorstellen van een betere structuur het niveau 'creëren' bereikt. Als je oefeningen alleen vragen stellen als "wat doet deze code?", blijven ze steken bij begrip. Onze handleiding voor Leeractiviteiten afstemmen op de taxonomie van Bloom. Dit laat zien hoe je de activiteit kunt afstemmen op het niveau.
3. Is er iets anders dan vaardigheid dat in de weg staat? Controleer de beschikbare tijd voor reviews, de tools, de verantwoordelijkheden en de teamnormen. Als reviewers slechts vijf minuten per pull request hebben, zal geen enkele oefening een doordachte uitleg opleveren. Als auteurs elke opmerking als kritiek opvatten, zullen reviewers hun bevindingen afzwakken totdat ze uiteindelijk niets meer zeggen. Meld deze oorzaken aan de mensen die ze kunnen oplossen.

3. Ontwerpvoorbereiding, oefening en feedback

Wijs aan elke fase een aparte taak toe.

Voorbereiding. Controleer wat reviewers nodig hebben voordat ze beginnen: de checklist van het team, de ontwerpprincipes waarop deze is gebaseerd en hoe ze een diff in hun tooling kunnen lezen. Houd dit in eigen tempo en kort. Een controle achteraf bevestigt alleen de vereisten en is geen bewijs dat iemand daadwerkelijk kan beoordelen.

Praktijk. Gebruik voorbereide wijzigingen met een klein aantal vooraf ingestelde aandachtspunten van verschillende aard: een correctheidsfout, een onderhoudbaarheidsprobleem zoals de gemengde verantwoordelijkheden in het openingsvoorbeeld, een onduidelijke naam of een ontbrekende test, en wat code die in orde is. Vraag de reviewer om de opmerking te schrijven die hij of zij zou achterlaten, de aandachtspunten te rangschikken en aan te geven welke aanvullende informatie hij of zij zou willen. De praktische les van CodeRefinery laat zien hoe dit in zijn werk gaat: mensen openen een pull request met een kleine typefout en een grotere fout, en beoordelen deze vervolgens als collega.CodeRefinery, Oefenen met codebeoordeling). Bouw die van jou op basis van je eigen codebase, zodat de conventies en afwegingen echt zijn.

Feedback. Koppel het aan de beslissingen die de beoordelaar heeft genomen. "Je hebt het afrondingsprobleem opgemerkt, maar je opmerking luidde 'dit ziet er verkeerd uit' zonder te specificeren welke invoer de fout veroorzaakt" is nuttiger dan "2 van de 4 gevonden".

Live input of asynchrone beoordeling? Live feedback is vooral waardevol wanneer een probleem onduidelijk is en reviewers leren van de uitleg van een senior engineer over waarom ze het wel of niet zouden aankaarten. Asynchrone review is voldoende om opmerkingen te vergelijken met een geannoteerde beoordeling door een expert.

4. Werk een realistisch voorbeeld uit.

Ter illustratie. Een engineeringmanager dient de casus en de antwoordcriteria te valideren alvorens deze te gebruiken.

De zaak. Een wijziging voegt een kortingsberekening toe aan een afrekenproces. De wijzigingen doorstaan ​​de tests. In één functie worden procentuele en vaste kortingen toegepast, het resultaat afgerond, naar de database geschreven en een gebeurtenis verzonden. Er is één test, voor een enkele procentuele korting.

De taak. De recensent schrijft de opmerkingen op die hij of zij zou achterlaten, rangschikt de aandachtspunten en geeft aan wat hij of zij moet weten voordat hij of zij goedkeuring verleent.

Een eerste poging. "Ziet er goed uit, de test is geslaagd. Misschien opsplitsen?" De recensent heeft iets opgemerkt, maar heeft niet gezegd wat, waarom het belangrijk is of wat er moet gebeuren. De auteur kan hier niets aan doen.

Feedback en opnieuw proberen. De begeleider vraagt: wat zou een toekomstige wijziging van deze functie kunnen verstoren? Wat zou u de auteur willen laten toevoegen voordat u de wijziging goedkeurt? Bij de herkansing wordt gevraagd om een ​​specifieke opmerking bij elk punt van zorg, met de reden en een suggestie.

Een serieuzere poging. "De functie past twee soorten korting toe, rondt af, slaat op en publiceert een gebeurtenis. Een wijziging in de afronding kan dus tegelijkertijd invloed hebben op wat we opslaan en wat we publiceren. Ik zou willen vragen of de prijsregels in een aparte functie geplaatst kunnen worden die we zelfstandig kunnen testen. De huidige test dekt alleen een percentagekorting. Ik zou een vaste korting en een order die het totaal op nul brengt, willen. Ik weet niet zeker of de gebeurtenis moet worden geactiveerd wanneer het totaal nul is, dus ik zou de auteur hierover willen raadplegen." Merk op dat deze opmerking het probleem benoemt, de reden aangeeft, een concrete suggestie doet en aangeeft wat de reviewer niet weet.

5. Beoordeel de capaciteit en plan de overdracht.

Bewijs van bekwaamheid wordt geleverd door de uitvoering van een nieuwe verandering die de beoordelaar niet eerder heeft gezien. Beoordeel de nauwkeurigheid van de bevindingen en de bruikbaarheid van de uitleg. Een eenvoudige beoordelingsmatrix gebruikt een schaal van 0 tot 2 per criterium:

Ankers: 0 betekent afwezig of niet onderbouwd, 1 betekent gedeeltelijk met relevante weglatingen en 2 betekent volledig en gerechtvaardigd op basis van overeengekomen criteria. Definieer kritieke fouten afzonderlijk, bijvoorbeeld het goedkeuren van een wijziging met een risico op gegevensverlies, zodat een goede algemene score een kritieke fout niet kan verbergen. Pas de criteria aan in overleg met de engineeringmanager; deze rubric is een eerste voorstel, geen gevalideerde gereedheidsnorm. Zie onze handleiding voor meer informatie over de onderbouwing van de score. Interactieve oefeningen ontwerpen met nuttige feedback.

Plan voor de overdracht. Controleer na de oefening een paar weken later een steekproef van de daadwerkelijke beoordelingen van de beoordelaar, aan de hand van dezelfde criteria. Vergelijk deze met een nulmeting van vóór de training en definieer vooraf de doelgroep en de timing. Kijk naar andere veranderingen die in dezelfde periode hebben plaatsgevonden, zoals een nieuw beoordelingsinstrument of een personeelswijziging, voordat u de oefeningen crediteert.

6. Voer de oefening live of in je eigen tempo uit met AhaSlides.

Je kunt de oefening in een workshop uitvoeren of de beoordelaars er zelfstandig mee laten werken. In een live sessie kun je de voorbereide wijziging laten zien en interactieve dia's gebruiken voor de discussie.

1. Kies antwoord Voor de vraag "Welke zorg zou u als eerste aankaarten?", waarbij de voorgestelde zorgen als opties dienen. Toon de spreiding voordat u uw eigen rangschikking onthult.
2. Open Ended voor "schrijf de reactie die je zelf zou achterlaten". Recensenten kunnen hun eigen formulering vergelijken met die van anderen, en dat is waar de uitlegvaardigheid tot uiting komt.
3. Schaal voor "hoe ernstig is dit?", zodat de groep kan zien waar de oordelen verschillen en kan bespreken waarom.

Voor beoordelaars die niet aanwezig kunnen zijn, kan dezelfde reeks in eigen tempo worden doorlopen, waarbij de geannoteerde expertbeoordeling na elk antwoord wordt getoond. Beschouw elke bewering over code-uitvoering, integraties of AI-functies als onbevestigd totdat u deze met uw eigen materiaal hebt getest.

Als u ook reviewers traint op door AI geschreven code, raadpleeg dan onze bijbehorende handleiding over AI-gegenereerde training voor codebeoordelingDat bericht ging over het controleren van gegenereerde output. Dit bericht gaat over hoe mensen elkaars werk beoordelen en hoe ze hun bevindingen toelichten.

Mogelijke beperkingen die kunnen blijven bestaan

• Tijd voor een evaluatie. Een doordachte reactie kost meer tijd dan "LGTM", en deadlines dwingen tot een korte versie.
• Teamnormen. Als feedback wordt opgevat als persoonlijke kritiek, zullen beoordelaars hun bevindingen afzwakken of helemaal laten vallen.
• Dekking van de zaak. Eén oefening illustreert een aantal aandachtspunten. Een score geeft niet in het algemeen het oordeel van een beoordelaar weer.
• Transfer. Prestaties in een werkplaats zijn niet hetzelfde als prestaties in een drukke wachtrij, dus bekijk ook echte recensies.

Benoem deze punten vroegtijdig aan de sponsors en plan afzonderlijke oplossingen. Oefeningen verbeteren wat een beoordelaar kan zien en uitleggen. Ze creëren niet de tijd of de normen.

Veelgestelde vragen

Wat zijn codebeoordelingsoefeningen?

Het zijn voorbereide oefentaken waarbij een ontwikkelaar een wijziging met bekende aandachtspunten beoordeelt, de opmerkingen opschrijft die hij of zij zou maken en feedback krijgt over de nauwkeurigheid en bruikbaarheid ervan. Het doel is om de vaardigheden van de beoordelaar te ontwikkelen, niet om de wijziging daadwerkelijk te implementeren.

Hoe beoordeel je of het oordeel van een recensent is verbeterd?

Geef ze een nieuwe wijziging die ze nog niet hebben gezien en beoordeel de bevindingen en de uitleg aan de hand van afgesproken criteria. Controleer vervolgens enkele weken later een steekproef van echte beoordelingen. Een quiz over beoordelingsregels bevestigt alleen de vereisten.

Gaat peer code review voornamelijk over het vinden van bugs?

Het vinden van fouten blijft een belangrijke drijfveer, maar een onderzoek bij Microsoft wees uit dat beoordelingen minder over fouten gingen dan verwacht en ook zorgden voor kennisdeling en teambewustzijn. Ontwerp oefeningen die uitleg en begrip belonen, naast het tellen van fouten.

Waar te beginnen

Kies één soort wijziging die je team vaak evalueert. Schrijf de prestatieomschrijving, vraag een senior engineer om één wijziging voor te bereiden met drie of vier vooraf vastgestelde aandachtspunten, en stel een beoordelingsschema op met drie criteria, een schaal van 0 tot 2 en een lijst met kritieke fouten. Test dit met een kleine groep en vergelijk hun volgende echte evaluaties met de basislijn.

Om te zien hoe een evaluatieoefening live met je eigen team kan worden uitgevoerd en daarna in eigen tempo kan worden hergebruikt, kun je AhaSlides bekijken.