In qualità di sviluppatore iOS, ho esaminato migliaia di righe di codice dei miei colleghi. Come la programmazione, la revisione del codice ti fa sentire intelligente o completamente stupido.

Ciò è dovuto ai principali problemi con le revisioni del codice:
1. Le persone non sanno veramente perché rivedono il codice.
2. Le persone non recensiscono le cose giuste.
3. Le Pull Request non sono revisionabili.

In questo articolo, ci concentriamo sul motivo per cui esaminiamo il codice.

Alcuni dei motivi

Ho posto questa domanda a molti candidati durante i colloqui, ottenendo una gamma molto diversificata di risposte. Le persone spesso rivedono il codice perché è una buona pratica ben nota senza approfondire il motivo per cui in realtà è una buona pratica.

Per capire perché esaminiamo il codice, la migliore domanda che possiamo porci è: perché dovremmo volere che qualcun altro esamini il nostro codice?

Ecco alcuni dei motivi:

• Vogliamo sapere se il codice può essere compreso da qualcuno diverso da noi.
• Vogliamo identificare altre aree confuse, come nomi di variabili, classi, metodi, ecc.
• Vogliamo un altro paio di occhi che ci ricordi se abbiamo dimenticato qualcosa (ad esempio, abbiamo cambiato il nome di una variabile all'ultimo minuto e qualche difetto di progettazione è diventato evidente).
• Vogliamo imparare dai nostri colleghi se è possibile adottare un approccio migliore per risolvere lo stesso problema.
• Abbiamo commesso un errore di battitura e chiamato una variabile `tmoato` invece di `pomodoro`, quindi ora una classe che contava le verdure sembra invece evocare divinità Maya.

Se osservi attentamente l'elenco, potresti notare che ci sono solo due elementi nell'elenco che richiedono effettivamente più persone.

Questa è una particolarità delle revisioni del codice. Nella maggior parte dei casi, quando crei una Pull Request, sei la persona migliore per esaminarla. Noterai errori di battitura e praticamente tutto ciò che hai dimenticato.

Gli sviluppatori non sono soli in questo. Gli scrittori fanno lo stesso.

È noto che Stephen King passa attraverso tre bozze prima di inviare un romanzo all'editore. Dalla prima alla seconda bozza, non chiede nemmeno feedback ma la rivede lui stesso.

Ti suona familiare?

Provaci.

La prossima volta che crei una Pull Request, rivedila prima da solo. Quindi chiedi a qualcuno di esaminarlo. Probabilmente evidenzieranno feedback preziosi per te, come aree difficili da comprendere o decisioni sbagliate durante la progettazione delle API.

Capire perché

Quando rivedi il tuo codice, puoi facilmente identificare la maggior parte degli errori di battitura, dei test mancanti o degli errori di base. Tuttavia, se credi che la parola "capo" sia scritta "chef", parlerai comunque di cuochi quando vorrai parlare di leader. Un altro paio di occhi può aiutarti a trovare gli ultimi dettagli che rifiniscono il tuo codice.

Detto questo, se quando rivedi il codice, commenti solo le aree che qualcuno potrebbe rivedere da solo, probabilmente stai perdendo il punto.

Le revisioni del codice riguardano l'ottenere feedback, chiarezza e assicurarsi che ciò che capisci possa essere compreso dagli altri.

Qual è il prossimo?

Ora che sai perché esaminiamo il codice, dobbiamo capire meglio cosa deve essere rivisto e come dovrebbe essere fatto. Ho fornito alcune delle risposte in questo articolo, ma approfondirò fornendo esempi specifici.

Puoi seguire Volvo Cars Engineering se desideri ricevere aggiornamenti su quando sarà disponibile il prossimo articolo. In questo modo, aiuti anche molti ingegneri a condividere approfondimenti e apprendimenti.