Als junior software-ingenieur heb ik altijd commentaar op code-review doorgenomen dat ik kreeg om te leren hoe ik een betere coder kon worden. Maar toen het tijd werd om mijn eerste codebeoordeling te proberen, besefte ik dat mijn ervaring me niet had voorbereid om aan de andere kant te staan.
Ik ontwikkelde een ernstig geval van bedriegersyndroom, dat naar beneden liep met vragen: moet ik commentaar geven op deze coderegel of is het het niet waard? Moet ik artikelen vinden die elke opmerking ondersteunen? Zal ik de site laten crashen door dit goed te keuren? Zullen ze me haten? Oké, ik geef toe dat ik vrij snel spiraal. Maar nadat ik met collega's had gesproken, wist ik dat ik niet alleen was in mijn zorgen.
Junior software-ingenieurs kunnen worden overgeheveld naar code review met een veronderstelling die analoog is aan "je weet hoe je een boek moet lezen, zodat je weet hoe je een boek moet schrijven, wat niet waar is", zegt Jessica Rudder, een ervaringsingenieur bij GitHub.
Er zijn verwachtingen die gepaard gaan met het beoordelen van codes en het proces kan zenuwslopend zijn. Dus heb ik zeven andere software-ingenieurs geïnterviewd om tips te verzamelen over hoe je een beoordelingsmindset kunt bouwen.
1. Denk na over de algehele impact
Over het algemeen heeft een goed pull-verzoek (PR) alleen gevolgen voor een beperkt deel van de codebasis. Het beperkte bereik mag u echter niet beletten om na te denken over de codewijziging in de context van de grotere codebase.
Nigel Munoz, een voormalige full-stack ingenieur bij The Muse en een huidige freelance software-ingenieur, moedigt de recensent aan om na te denken over "hoe deze verandering het grotere en kleinere beeld beïnvloedt." Gezien het grotere beeld het vinden van enige technische schuld omvat - zoek naar code dat is herhaald, niet-modulair, of houdt zich niet aan de meest recente standaardconventies - evenals analyse van wijzigingen in de architectuur van de codebasis.
Sam Donow, een kernontwikkelaar bij Hudson River Trading, is van mening dat “er niets te groot of te klein is om op te reageren. Suggesties voor kleine verbeteringen kunnen leiden tot grotere verbeteringen in meerdere delen van de codebasis. ”
U kunt een PR-commentaar op GitHub gebruiken om positieve feedback te geven en om aan te geven waar de code kan verschillen van standaardconventies van het framework React.
Tijdens een van mijn eigen codebeoordelingen ontving ik bijvoorbeeld een opmerking dat bepaalde eigenschappen van een React-component verwarrend waren, wat bredere vragen opriep over hoe de component werd gebruikt. Uiteindelijk heb ik de eigenschappen van de oorspronkelijke component verwijderd en een afzonderlijke component gemaakt om het gedrag van elke component te verduidelijken en ervoor te zorgen dat beide op meer plaatsen konden worden gebruikt.
2. Overweeg beveiliging
Vergeet niet dat sommige wijzigingen meer van invloed kunnen zijn dan alleen de codebase. Rudder beveelt aan te evalueren of een gebruiker "deze functionaliteit kan gebruiken om iemand lastig te vallen of het systeem kan misbruiken." Bijvoorbeeld als de nieuwe functie in het pull-verzoek gebruikersinvoer bevat, zoeken naar SQL-injectie, gegevenstoegang, cross-site scripting en andere beveiligingsproblemen.
3. Focus op bugs
Je mede-code-bijdragers - hoe robotachtig ze ook lijken - zijn menselijk, en mensen kunnen functies breken of vergeten. Dus zorg ervoor dat u "de tests met hetzelfde belang bekijkt als de rest van de code", adviseert Abhishek Pillai, een technisch leider bij Teachers Pay Teachers. "Ze zullen nieuwe bugs voorkomen en dienen als een vorm van documentatie voor iedereen die hier in de toekomst aan werkt."
Het lezen van de tests kan u helpen de functionaliteit van een nieuwe functie te begrijpen en de verschillende gevallen te bekijken die het zal introduceren, terwijl het analyseren van de tests u kan helpen om ontbrekende gevallen aan te wijzen en functies te vinden die niet in deze PR zijn opgenomen. Als er geen tests zijn opgenomen in de codewijziging en deze relevant lijken, is het gepast om deze binnen de beoordeling aan te vragen.
Maar tests zijn niet alles. "Vertrouw niet te veel op het systeem", waarschuwt Donow. "Alleen omdat tests zijn uitgevoerd, betekent dit niet dat er geen bugs zijn."
Misschien wilt u ook 'de app lokaal uitvoeren om deze functioneel te testen en te controleren of deze werkt. Als het niet werkt, heeft het geen zin verder te evalueren, ”zegt Ryan Verner, een softwareontwikkelaar bij 8th Light. Hoewel sommige recensenten niet vinden dat handmatig testen onderdeel moet zijn van het codebeoordelingsproces - deels vanwege de tijd die het kost - vindt Verner dat dit een snelle manier is om te bepalen of u meer tijd moet besteden aan het beoordelen en een strategie om te helpen beperken de groei van een bugs-achterstand.
4. Wees een teamspeler
Het cliché krijgt een nieuwe betekenis als het gaat om het herzien van code. "Neem de tijd om te beoordelen omdat het ieders codebasis is", zegt Verner, die pleit voor een gevoel van "collectief eigendom." U, als recensent, zou moeten werken aan het beschermen van de achterstand van bugs tegen groter worden met als doel uw team minder werk langs de lijn.
Pillai gebruikt gifs om de goedgekeurde en kant-en-klare PR's van zijn teamgenoten te vieren.
Tegelijkertijd moedigt Charles Luxton, een technisch leider bij The Muse, de recensent aan om de prioriteiten van het team te begrijpen en te onthouden. Met snel naderende deadlines en meningsverschillen in overvloed, soms een to-do item maken voor de achterstand die ervoor zorgt dat er in de toekomst verbeteringen zullen worden aangebracht en in de tussentijd een commentaar op de betreffende code plaatsen is de pleister die je nodig hebt om houd je team gelukkig.
Ten slotte zal het je helpen om de code leesbaar en begrijpelijk te houden als je jezelf afvraagt of de code zinvol is voor iemand die net bij het team is gekomen en deze binnen de eerste paar weken heeft gelezen.
5. Gebruik het leerproces en het delen van kennis
Het beoordelingsproces biedt alle betrokkenen een plek om meer inzicht te krijgen in de codebase, talen, frameworks en best practices.
Matt Jeffery, een technisch leider bij The Muse, adviseert de revisor om "de veranderingen architecturaal te begrijpen. Een manier is om bestandsnamen te lezen omdat deze helpen context te geven. Bijvoorbeeld als u kijkt naar een wijziging in de gegevenstoegangslaag je weet dat je niet te maken hebt met bedrijfslogica of gebruikersinterface. "
U kunt een PR-commentaar op GitHub gebruiken om documentatie te delen.
Wanneer u leert van codewijzigingen, heeft u ook de mogelijkheid om kennis te delen. "Het is het beste om je mening uit te leggen en te ondersteunen met documentatie, " zegt Luxton. De links die u verstrekt naar ondersteunend bewijsmateriaal en betrouwbare artikelen helpen de recensent en codeschrijver niet alleen verschillende benaderingen te verkennen bij het nemen van een definitieve beslissing, maar versterken ook hun kennis van programmeren.
Hoewel u deze tips in gedachten houdt, moet u er ook rekening mee houden dat beoordeling een tijd is om de vaardigheden van uw mensen te oefenen. "Geef mensen het voordeel van de twijfel dat ze over hun aanpak dachten en wijs op verschillende mogelijkheden terwijl ze defensiviteit proberen te verdrijven, " zegt Rudder. "Ik laat overal opmerkingen en een afrondende opmerking achter - hier is wat geweldig is, hier is wat kan worden verbeterd, hier is wat moet worden gewijzigd voordat het samenvoegen."
Met dit soort aanpak beschermt u niet alleen uw codebasis tegen technische schulden, beveiligingsrisico's en bugs, maar bouwt u ook uw team op.
