Code review di un software esistente: guida per chi decide

Per fare la code review di un software esistente si parte da una domanda precisa a cui la review deve rispondere, si dà a chi la esegue un accesso in sola lettura a codice, database e configurazione, e si chiede un report con priorità e conseguenze pratiche, non solo giudizi tecnici. Si guardano architettura, dipendenze, sicurezza, database, test e modo in cui il software viene pubblicato. Il risultato è una fotografia di cosa è solido e cosa frena, su cui decidere.

Se hai un gestionale, un'app o una piattaforma scritta da un fornitore esterno, da un freelance o da un ex collaboratore, e non sai bene in che stato sia il codice, alla fine di questa guida saprai cosa preparare, cosa chiedere a chi fa la review e come leggere quello che ti consegna.

Cosa serve prima di iniziare

• Accesso al repository del codice, cioè l'archivio in cui è salvato il software con la cronologia delle modifiche. Se il codice vive solo sul server o sul computer di chi l'ha scritto, recuperarlo è il primo passo.
• Accesso agli ambienti: il server di produzione, e se esiste un ambiente di prova. Basta la sola lettura, o una copia.
• L'elenco dei servizi esterni a cui il software si appoggia (invio email, pagamenti, notifiche, archiviazione file), con chi ne è titolare. Le credenziali non vanno mandate per email: si condividono con un sistema protetto, e solo quelle che servono.
• La documentazione che c'è, anche parziale o vecchia: come si installa, come si pubblica una nuova versione, quali operazioni girano da sole di notte.
• Una persona che conosce il software da utente, disponibile per qualche domanda.
• Un NDA firmato con chi fa la review: leggerà logiche di business, configurazioni e a volte dati di clienti.
• Il contratto con chi ha sviluppato, per sapere cosa puoi condividere. Sul tema c'è una guida dedicata alla proprietà del codice nel software su misura.

Come fare la code review, passo per passo

1. Scrivi la domanda a cui la review deve rispondere. Non "dimmi se il codice è buono", ma "possiamo aggiungere il modulo ordini senza riscrivere tutto?", "perché le pagine si caricano in otto secondi?", "un nuovo team può prenderlo in carico?". A questo punto chi legge il codice sa dove guardare per primo, e tu sai cosa aspettarti.
2. Dai un accesso in sola lettura, intestato all'azienda. Crea un'utenza nominale sul repository e, se serve, una copia del database con i dati personali mascherati. Il risultato atteso è che chi fa la review lavori senza poter modificare nulla in produzione.
3. Fai fare un inventario di cosa esiste. Linguaggi e framework usati e loro versioni, librerie esterne, database, servizi collegati, operazioni pianificate. Alla fine di questo passo hai una mappa del software che spesso in azienda non esisteva.
4. Fai leggere architettura e codice. Come è diviso il software, se le parti sono separate o tutto dipende da tutto, se le stesse regole sono ripetute in dieci punti diversi, quanto è leggibile per uno sviluppatore che non l'ha scritto.
5. Fai controllare sicurezza, database e test. Gestione degli accessi, credenziali nel codice, librerie con vulnerabilità note, struttura delle tabelle, indici, backup, presenza e qualità dei test automatici.
6. Fai verificare come si pubblica una nuova versione. Se esiste una procedura ripetibile o se ogni rilascio è fatto a mano da una persona sola. È il punto che decide quanto è rischioso ogni intervento futuro.
7. Chiedi un report con priorità. Ogni problema con tre informazioni: quanto è grave, cosa succede se non si interviene, quanto è complesso sistemarlo. A questo punto hai un elenco ordinato, non un muro di osservazioni tecniche.
8. Decidi con il report in mano. Discutilo in una call finché ogni punto ad alta priorità ti è chiaro, poi scegli: interventi mirati, un nuovo partner, rifare solo alcune parti.

È lo stesso percorso con cui entriamo su progetti avviati da altri: nel servizio di partner di sviluppo software partiamo da una code review del codice esistente e ti restituiamo una fotografia onesta di cosa è solido e cosa frena, con NDA sempre incluso e accesso al codice nel modo che preferisci tu.

Cosa si controlla e quali segnali preoccupano

Nessun software reale passa tutte le righe senza note: conta sapere quali pesano sulla tua decisione.

Se il fornitore è ancora attivo

È il caso più comune e anche il più delicato sul piano dei rapporti. Una code review non è un'accusa: è un controllo che molte aziende fanno a scadenze regolari, come la revisione di un'auto. Presentala così, e chiedi al fornitore di partecipare alla call iniziale per spiegare le scelte fatte. Molte decisioni che sembrano strane hanno un motivo, come una scadenza stretta o un requisito cambiato a metà strada: non sempre è colpa di qualcuno.

Dagli anche la possibilità di leggere il report e di rispondere. Se la review porta a un cambio, la guida su come cambiare fornitore software spiega come gestire il passaggio senza fermare il lavoro.

Se il codice l'ha scritto un ex collaboratore o un freelance

Qui il problema principale è la conoscenza che se n'è andata con chi ha scritto il software. La review pesa di più sull'inventario: dove gira davvero il software, quale versione del codice corrisponde a quella in produzione, quali account sono intestati a quella persona. Capita che il repository sia fermo da mesi mentre in produzione gira una versione modificata direttamente sul server: va scoperto subito.

Chiedi che il report includa una documentazione minima ricostruita durante la lettura: come si avvia il software, come si pubblica, quali operazioni automatiche esistono.

Se il software è stato generato in buona parte con l'AI

Il codice scritto con gli assistenti AI spesso funziona alla prima prova ma ha punti deboli ricorrenti: controlli di sicurezza solo nell'interfaccia, chiavi di accesso nei file, logiche ripetute in più punti con piccole differenze, nessun test. La review si concentra lì e su cosa succede quando gli utenti crescono. Cosa guardare nel dettaglio è nella guida sulla revisione del codice AI da parte di esperti, e per questi progetti esiste anche un servizio dedicato di audit del codice AI.

Cosa ricevi alla fine

Una code review fatta bene ti lascia in mano tre cose.

• Una sintesi per chi decide, in linguaggio comprensibile: in che stato è il software, quali sono i tre o quattro punti che contano, cosa conviene fare adesso e cosa può aspettare.
• Un elenco dettagliato dei problemi, ognuno con gravità, conseguenza pratica e indicazione di quanto è complesso intervenire. È il materiale che userà chi metterà le mani nel codice.
• Una mappa del software: componenti, dipendenze, servizi esterni, ambienti, procedura di rilascio. Resta all'azienda, qualunque cosa tu decida.

Immagina un'azienda di distribuzione con quindici dipendenti e un gestionale ordini scritto anni fa da un freelance. La review potrebbe dire che la logica dei listini è solida e ben separata, che il database non ha indici sulle tabelle più grandi (da qui la lentezza) e che i backup esistono ma non sono mai stati provati. Con un quadro così la decisione non è "tenere o buttare", ma un ordine di interventi.

Errori comuni

Chiedere una review senza una domanda. Il risultato è un elenco lungo di osservazioni tecniche, tutte vere, nessuna utile per decidere. Rimedio: scrivi la domanda al primo passo e chiedi che il report risponda prima a quella.

Leggere il report come un voto. Un software con molte note non è da buttare, uno con poche non è perfetto. Rimedio: guarda le priorità e le conseguenze, non il numero dei problemi.

Decidere di riscrivere tutto subito dopo. Il codice in uso contiene anni di regole ed eccezioni che nessuno ha scritto altrove. Rimedio: riscrivi solo le parti che il report indica come un freno reale, e tieni quelle solide.

Chi siamo

Obly è un'agenzia di sviluppo software su misura con sede a Casale Monferrato (AL) che progetta gestionali, app e integrazioni fra sistemi aziendali, e lavora anche su codice scritto da altri. Entriamo con una code review iniziale, poi con un primo task piccolo e una presa in carico graduale, con un project manager unico e ore mensili che si scalano senza vincoli di durata. Lavoriamo, tra gli altri, con Node.js, Laravel, React, Next.js, Flutter, WordPress, PostgreSQL, MySQL e Supabase, e per le agenzie senza reparto sviluppo consegniamo in white-label.

Quanto tempo serve e qual è il passo successivo

Il tempo di una code review dipende da tre cose: quanto è grande il software, quanto sono completi gli accessi che riesci a dare e quanta documentazione esiste. Se prima vanno recuperati codice e credenziali, la parte più lunga è spesso quella.

Una volta deciso cosa fare, il passo naturale è stabilire chi seguirà il software da qui in avanti e con quale piano di manutenzione del software aziendale. Se vuoi far leggere il codice del tuo software prima di decidere, o valutare una presa in carico, puoi parlarne con noi dalla pagina partner di sviluppo software oppure contattarci raccontando cosa hai e quale domanda ti serve chiudere.