Com a enginyer de programari més jove, sempre vaig fer un comentari amb els comentaris que vaig rebre per aprendre a convertir-me en un codificador millor. Però quan va arribar el moment per intentar la meva primera revisió de codi, em vaig adonar que la meva experiència no m’havia preparat per estar a l’altra banda.
Vaig desenvolupar un cas greu de síndrome impostor, espiralant cap avall amb preguntes: he de comentar aquesta línia de codi o no val la pena? Hauria de trobar articles per donar suport a tots els comentaris? Es bloquejarà el lloc aprovant-ho? Em detestaran? D’acord, admeto que espiralle força ràpidament. Però, després de parlar amb alguns companys de treball, sabia que no estava sol a les meves preocupacions.
Els enginyers de programari juvenils es podran llençar a la revisió de codis amb un supòsit anàleg a "saps llegir un llibre perquè sàpigues com escriure un llibre, cosa que no és veritat", diu Jessica Rudder, enginyer en experiència de GitHub.
Hi ha expectatives que vénen amb la revisió del codi, i el procés pot comportar un efecte nerviós. Així que vaig entrevistar set altres enginyers de programari per recollir consells sobre com crear una mentalitat de revisió.
1. Penseu en l’impacte general
Generalment, una bona sol·licitud d’atracció (PR) només ha d’afectar una part confinada de la base de codis. Tanmateix, l’àmbit limitat no ha d’impedir que penseu en el canvi de codi en el context de la base de codis més gran.
Nigel Munoz, ex enginyer de pila completa de The Muse i actual enginyer de programari autònom, anima el revisor a pensar "com afecta aquest canvi a la imatge més gran i més petita". Tenint en compte que la imatge més gran inclou trobar qualsevol deute tècnic: buscar codi. que es repeteix, no és modular o no s'adhereix a les convencions estàndard més recents, a més d'analitzar les modificacions de l'arquitectura del codi base.
Sam Donow, desenvolupador principal de Hudson River Trading, creu que "no hi ha res massa gran ni massa petit per comentar-lo. Els suggeriments per a petites millores podrien conduir a millores més a diverses parts de la base de codis. "
Podeu utilitzar un comentari de PR sobre GitHub per proporcionar comentaris positius, així com indicar on el codi pot diferir de les convencions estàndard del marc React.
Per exemple, durant una de les meves ressenyes de codi, vaig rebre un comentari que certes propietats d’un component React eren confuses, cosa que va provocar preguntes més àmplies sobre com s’estava utilitzant el component. En última instància, he tret les propietats del component original i he creat un component separat per aclarir el comportament de cadascuna i assegurar-me que es podrien utilitzar en més llocs.
2. Considereu la seguretat
No oblideu que alguns canvis poden afectar més que la base de codis. Timó recomana valorar si un usuari "pot utilitzar aquesta funcionalitat per assetjar algú o podria abusar del sistema". Per exemple, si la nova característica de la sol·licitud d'atracció inclou l'entrada de l'usuari, busqueu injecció SQL, accés a dades, scripts de llocs creuats i altres vulnerabilitats de seguretat.
3. Centrar-se en els errors
Els seus companys col·laboradors de codis, per molt robòtics que semblin, són humans, i els humans poden trencar o oblidar les funcionalitats. Així doncs, assegureu-vos que “reviseu les proves amb la mateixa importància que la resta del codi”, aconsella Abhishek Pillai, responsable de tecnologia de Teachers Pay Teachers. "Evitaran nous errors i serveixen com a forma de documentació a qualsevol altra persona que treballi en això en el futur".
Llegir les proves us pot ajudar a comprendre la funcionalitat d’una nova característica i veure els diferents casos que introduirà, mentre que analitzar les proves us pot ajudar a assenyalar casos que falten i trobar funcions que no figuren en aquest PR. Si no hi ha proves incloses al canvi de codi i semblen rellevants, convé sol·licitar-les dins de la revisió.
Però les proves no ho són tot. "No feu massa fe en el sistema", adverteix Donow. "Només perquè es facin proves no vol dir que no hi hagi errors".
També podeu "executar l'aplicació localment per provar-la funcionalment i assegurar-vos que funciona. Si no funciona, aleshores no té sentit revisar-ho ”, diu Ryan Verner, desenvolupador de programari de 8th Light. Tot i que alguns revisors no creuen que les proves manuals haurien de formar part del procés de revisió del codi, en part a causa del temps que triga, Verner creu que és una manera ràpida de determinar si haureu d’invertir més temps revisant, així com una estratègia per ajudar a reduir. el creixement d'un error enrere.
4. Ser un jugador d’equip
El tòpic adquireix un nou significat a l’hora de revisar el codi. "Aprofiteu-vos per revisar perquè és el codi de tots", diu Verner, que defensa una sensació de "propietat col·lectiva". Vostè, com a crític, hauria de treballar per protegir els resultats posteriors dels errors que es facin més grans amb l'objectiu de donar-li el seu. l'equip menys treballa en la línia.
Pillai utilitza gifs per celebrar els PRs aprovats i llestos per combinar els seus companys d'equip.
Al mateix temps, Charles Luxton, responsable de tecnologia de The Muse, anima el revisor a comprendre i recordar les prioritats de l'equip. Amb els terminis i desacords que s’aproximen ràpidament, de vegades es crea un article per fer per a l’endarreriment que garanteixi que es realitzarà millores en el futur i es plantejarà un comentari sobre el codi en qüestió, mentre que l’ajuda de banda necessita. mantenir feliç el vostre equip.
Finalment, preguntar-se si el codi tindria sentit a algú que s’acabava d’incorporar a l’equip i que el llegís durant les primeres setmanes ajudarà a que el vostre codi sigui llegible i comprensible.
5. Utilitzeu el procés d'aprenentatge i compartició de coneixements
El procés de revisió proporciona a tots els implicats un lloc per aprofundir en la base de codis, idiomes, marcs i bones pràctiques.
Matt Jeffery, responsable de tecnologia de The Muse, aconsella al revisor que "entengui els canvis arquitectònicament. Una manera és llegir els noms de fitxers ja que ajuden a donar context. Per exemple, si busqueu un canvi en la capa d'accés a les dades. sabeu que no esteu relacionant-vos amb la lògica comercial ni la interfície d'interès.
Podeu utilitzar un comentari de PR sobre GitHub per compartir documentació.
Quan apreneu dels canvis de codi, també teniu l'oportunitat de compartir coneixements. "El millor és explicar la vostra opinió i recolzar-la amb documentació", diu Luxton. Els enllaços que proporcioneu articles de prova i articles de confiança no només ajuden al revisor i al redactor de codis a explorar diferents enfocaments ja que prenen una decisió final, sinó que reforcen el seu coneixement de la programació.
Tot tenint en compte aquests consells, recordeu també que revisar és un moment per exercir les habilitats de la vostra gent. "Dóna a la gent el benefici del dubte que pensessin en el seu enfocament i assenyalar diferents possibilitats mentre intenta dissipar la defensiva", afirma Rudder. "Deixo comentaris a tot arreu i emprenyo un comentari: aquí teniu el millor, aquí és el que es pot millorar, aquí heu de canviar abans de fusionar-nos".
Amb aquest tipus d’enfocament, no només protegiràs la base de codis contra l’endeutament tecnològic, les amenaces de seguretat i els errors, sinó que també crearàs el teu equip.
