Come ingegnere informatico junior, ho sempre esaminato i commenti di revisione del codice che ho ricevuto per imparare a diventare un programmatore migliore. Ma quando è arrivato il momento di provare la mia prima recensione del codice, mi sono reso conto che la mia esperienza non mi aveva preparato ad essere dall'altra parte.
Ho sviluppato un caso grave di sindrome da impostore, facendo una spirale discendente con domande: dovrei commentare questa riga di codice o non ne vale la pena? Devo trovare articoli per supportare ogni commento? Arresto anomalo del sito approvando questo? Mi odieranno? Va bene, lo ammetto a spirale abbastanza rapidamente. Ma dopo aver parlato con alcuni colleghi, sapevo di non essere solo nelle mie preoccupazioni.
Gli ingegneri del software junior possono essere coinvolti nella revisione del codice con un'ipotesi analoga a "sai leggere un libro in modo da sapere come scrivere un libro, il che non è vero", afferma Jessica Rudder, ingegnere esperto di GitHub.
Ci sono aspettative che derivano dalla revisione del codice e il processo può essere snervante. Così ho intervistato altri sette ingegneri del software per raccogliere suggerimenti su come costruire una mentalità di revisione.
1. Pensa all'impatto generale
In genere, una buona richiesta pull (PR) dovrebbe interessare solo una parte limitata della base di codice. Tuttavia, l'ambito limitato non dovrebbe impedirti di pensare alla modifica del codice nel contesto della base di codice più grande.
Nigel Munoz, un ex ingegnere full-stack di The Muse e un attuale ingegnere informatico freelance, incoraggia il revisore a pensare a "in che modo questo cambiamento influisce sul quadro più grande e più piccolo". Considerando il quadro più ampio include la ricerca di qualsiasi debito tecnico: cerca il codice che viene ripetuto, non modulare o non aderisce alle convenzioni standard più recenti, oltre ad analizzare le modifiche all'architettura della base di codice.
Sam Donow, uno sviluppatore principale di Hudson River Trading, ritiene che “non c'è niente di troppo grande o troppo piccolo per commentare. Suggerimenti per piccoli miglioramenti potrebbero portare a maggiori miglioramenti in più parti della base di codice ".
È possibile utilizzare un commento PR su GitHub per fornire un feedback positivo e sottolineare dove il codice può differire dalle convenzioni standard del framework React.
Ad esempio, durante una delle mie revisioni del codice, ho ricevuto un commento secondo cui alcune proprietà di un componente React erano confuse, il che ha suscitato domande più ampie su come il componente veniva utilizzato. Alla fine, ho rimosso le proprietà dal componente originale e creato un componente separato per chiarire il comportamento di ciascuno e garantire che entrambi potessero essere utilizzati in più punti.
2. Considerare la sicurezza
Non dimenticare che alcune modifiche potrebbero influire più del semplice codebase. Rudder consiglia di valutare se un utente "potrebbe utilizzare questa funzionalità per molestare qualcuno o abusare del sistema". Ad esempio, se la nuova funzionalità nella richiesta pull include la voce dell'utente, cerca iniezione SQL, accesso ai dati, script tra siti e altre vulnerabilità di sicurezza.
3. Focus su bug
I collaboratori del tuo codice, indipendentemente da quanto possano sembrare robotici, sono umani e gli umani possono rompere o dimenticare funzionalità. Quindi assicurati di "rivedere i test con la stessa importanza del resto del codice", consiglia Abhishek Pillai, responsabile tecnico di Teachers Pay Teachers. "Preveniranno nuovi bug e fungeranno da forma di documentazione per chiunque altro lavori su questo in futuro."
La lettura dei test può aiutarti a comprendere la funzionalità di una nuova funzionalità e vedere i diversi casi che introdurrà, mentre l'analisi dei test può aiutarti a evidenziare i casi mancanti e trovare funzionalità non contenute in questo PR. Se non ci sono test inclusi nella modifica del codice e sembrano pertinenti, è opportuno richiederli durante la revisione.
Ma i test non sono tutto. "Non dare troppa fiducia al sistema", avverte Donow. "Solo perché i test eseguiti non significano che non ci siano bug."
Potresti anche voler “eseguire l'app localmente per testarla funzionalmente e assicurarti che funzioni. Se non funziona, non ha senso rivedere ulteriormente ", afferma Ryan Verner, sviluppatore di software di 8th Light. Sebbene alcuni revisori non ritengano che i test manuali dovrebbero far parte del processo di revisione del codice, in parte a causa del tempo impiegato, Verner ritiene che sia un modo rapido per determinare se è necessario investire più tempo nella revisione e una strategia per ridurre la crescita di un arretrato di bug.
4. Diventa un giocatore di squadra
Il cliché assume un nuovo significato quando si tratta di rivedere il codice. "Prenditi il tempo di rivedere perché è la base di codice di tutti", dice Verner, che sostiene un senso di "proprietà collettiva". Tu, come revisore, dovresti lavorare per proteggere l'arretrato di bug dalla crescita, con l'obiettivo di dare il tuo squadra in meno di lavoro lungo la linea.
Pillai usa gif per celebrare le PR approvate e pronte a fondere i suoi compagni di squadra.
Allo stesso tempo, Charles Luxton, responsabile tecnico di The Muse, incoraggia il revisore a comprendere e ricordare le priorità del team. Con scadenze in rapido avvicinamento e disaccordi abbondanti, a volte creare un elemento da fare per l'arretrato che garantisce miglioramenti in futuro e nel frattempo inserire un commento sul codice in questione è il Band-Aid necessario per mantieni felice la tua squadra.
Infine, chiederti se il codice avrebbe senso per qualcuno che si era appena unito al team e lo stava leggendo nelle prime settimane aiuterà a mantenere il tuo codice leggibile e comprensibile.
5. Utilizzare il processo di apprendimento e condivisione delle conoscenze
Il processo di revisione offre a tutti i soggetti coinvolti un luogo per ottenere maggiori informazioni sulla base di codice, sulle lingue, sui framework e sulle migliori pratiche.
Matt Jeffery, responsabile tecnico di The Muse, consiglia al revisore di "comprendere architettonicamente le modifiche. Un modo è leggere i nomi dei file poiché aiutano a dare contesto. Ad esempio, se stai osservando una modifica nel livello di accesso ai dati sai che non hai a che fare con la logica aziendale o l'interfaccia utente. "
È possibile utilizzare un commento PR su GitHub per condividere la documentazione.
Quando impari dalle modifiche al codice, hai anche l'opportunità di condividere le conoscenze. "È meglio spiegare la tua opinione ed eseguirne il backup con la documentazione", afferma Luxton. I collegamenti forniti a prove a sostegno e articoli affidabili non solo aiutano il revisore e lo scrittore di codice a esplorare diversi approcci mentre prendono una decisione finale, ma rafforzano anche la loro conoscenza della programmazione.
Mentre tieni a mente questi suggerimenti, ricorda anche che la revisione è un momento per esercitare le tue abilità personali. "Offri alle persone il beneficio del dubbio che hanno pensato al loro approccio e indica diverse possibilità mentre cerca di dissipare la difesa", afferma Rudder. "Lascio commenti dappertutto e un commento conclusivo: ecco cosa è fantastico, ecco cosa può essere migliorato, ecco cosa deve essere cambiato prima di unire."
Con questo tipo di approccio, non solo proteggerai la tua base di codice da debiti tecnologici, minacce alla sicurezza e bug, ma costruirai anche il tuo team.
