Code review: perché serve a chi ha un sito o un'app

Gestisce un sito, un negozio online o una piccola app. Qualcuno ha scritto il codice: un collaboratore esterno, un amico, un'agenzia che nel frattempo è sparita, oppure lei stesso dopo qualche weekend di tutorial. Funziona, più o meno. Ma non sa dire se è solido o tenuto insieme con il nastro adesivo. Una code review è un secondo sguardo da parte di qualcuno che non l'ha scritto, e risponde a questa domanda prima che un piccolo problema diventi costoso.

Quando conviene una revisione

• Prima di pagare un lavoro finito. La revisione mostra se il codice ricevuto è ragionevole o pieno di scorciatoie.
• Quando prende in mano un progetto. Il codice ereditato senza documentazione è una scatola nera finché qualcuno non lo spiega.
• Quando qualcosa continua a rompersi. Un modulo che a volte non funziona, una pagina lenta, un errore che ritorna dopo ogni correzione.
• Prima di un lancio o di una grande promozione, quando un bug costa soldi veri.
• Quando scrive codice da sé e vuole capire cosa fare meglio.

Cosa trova una revisione

Chi fa la revisione legge il codice riga per riga e cerca:

• Bug: logica che fallisce in certi casi, come un carrello vuoto, una data a fine mese o un nome con l'apostrofo.
• Punti rischiosi: password scritte nel codice, dati inseriti dagli utenti usati senza controlli, messaggi di errore che rivelano troppo.
• Punti deboli: codice che funziona oggi ma si romperà quando crescerà il traffico o verrà aggiornata una libreria.
• Leggibilità: nomi poco chiari, funzioni lunghe e codice ripetuto che rendono ogni modifica futura più lenta e più cara.

I problemi sono ordinati per importanza, così sa cosa correggere prima e cosa può aspettare.

Cosa non fa una revisione

Una revisione legge e spiega il codice; non lo esegue sul suo server e non testa il sito online. Non è un audit di sicurezza completo né un test di carico. Consideri le correzioni suggerite come proposte: chi si occupa del progetto dovrebbe testarle una per una prima di metterle online.

Come scegliere cosa inviare

Raramente serve l'intero sito. Scelga le parti che contano di più:

• Dove girano i soldi: checkout, pagamenti, prezzi e sconti.
• Dove gli utenti scrivono qualcosa: registrazione, accesso, moduli di contatto e di ricerca.
• Dove c'è il problema: il file o la funzione dietro l'errore che vede.

Qualche centinaio di righe dal punto giusto dicono più di migliaia di righe di tutto.

Come preparare il codice

• Tolga i dati segreti. Sostituisca password, chiavi API e dati dei clienti con segnaposto come PASSWORD_HERE.
• Indichi il linguaggio e la versione, per esempio PHP 8 o JavaScript con React.
• Descriva cosa deve fare il codice in una o due frasi semplici.
• Copi il messaggio di errore esatto, se c'è, per intero.
• Dica su cosa concentrarsi: il bug, la velocità, la leggibilità o i punti rischiosi.

Come usare il risultato

Condivida la revisione con chi si occupa del codice e concordate l'ordine delle correzioni, partendo da quelle critiche. Se non è una persona tecnica, il riepilogo in linguaggio semplice la aiuta a fare le domande giuste e a valutare le risposte.

In sintesi

Una code review è uno sguardo indipendente che trova bug, punti rischiosi e punti deboli prima dei suoi clienti. Se ne desidera una, ordini una code review: incolla fino a 100, 400 o 1.000 righe e descrive cosa non va e riceve una spiegazione scritta di cosa fa il codice, un elenco di problemi ordinati per importanza e frammenti corretti da testare nel suo progetto. Il pagamento viene sbloccato solo dopo che lei ha accettato il lavoro.