PREMIUM

Template per Code Review

Per tech lead e senior engineer che devono trasformare una review approssimativa in un report strutturato, azionabile e ordinato per gravita: ogni finding ha file, riga, impatto, fix proposto e rischio del fix.

#code-review #sicurezza #performance #qualita-codice #refactoring

Esempio di output

VERDETTO MERGE: BLOCCATO (2 findings Bloccanti, 1 Alto)

SINTESI
- File analizzati: 3 | Findings: 7 (2 Bloccanti, 1 Alto, 2 Medi, 2 Nit)
- Rischio principale: SQL injection nel layer di ricerca.

[SICUREZZA] #1 — Bloccante
File: UserRepository.php:48 | Tipo: SQL Injection (CWE-89)
Evidenza: query costruita per concatenazione con $request->name non sanitizzato.
Impatto: esfiltrazione tabella users tramite input utente.
Fix: usare query parametrizzata / binding.
  // before
  $db->query("SELECT * FROM users WHERE name = '".$name."'");
  // after
  $db->prepare("SELECT * FROM users WHERE name = ?")->execute([$name]);
Rischio del fix: Basso (nessun cambio di firma pubblica).

[PERFORMANCE] #2 — Alto
File: OrderService.php:120 | Tipo: N+1 query in loop
Evidenza: foreach su $orders con ->customer lazy-loaded.
Impatto: 1+N query, latenza lineare sul numero ordini.
Fix: eager load (with('customer')) prima del loop.
Rischio del fix: Basso.

[LEGGIBILITA] #5 — Basso
File: helpers.php:12 | funzione di 80 righe con 4 responsabilita: estrarre in 3 metodi nominati.

TABELLA RIEPILOGO
| # | Dimensione | Gravita | File:Riga | Fix in 1 riga |
|---|-----------|---------|-----------|----------------|
| 1 | Sicurezza | Bloccante | UserRepository.php:48 | Query parametrizzata |
| 2 | Performance | Alto | OrderService.php:120 | Eager load |
| 5 | Leggibilita | Basso | helpers.php:12 | Estrai metodi |

Domande frequenti

Posso usarlo anche senza diff completo, solo con uno snippet?

Si. Funziona sia su un diff/PR sia su un singolo file o snippet. Piu contesto fornisci (linguaggio, framework, vincoli di runtime, dati di esempio) piu i findings su sicurezza e performance saranno precisi. Il prompt impone di non inventare vulnerabilita non dimostrabili dal codice fornito.

Come evito che inventi problemi che non esistono?

I constraints obbligano il modello a citare file e riga per ogni finding e a marcare come 'Da verificare' qualsiasi ipotesi che dipenda da codice non mostrato, invece di darla per certa. I findings senza evidenza nel codice fornito vengono esclusi.

La review distingue tra problemi bloccanti e suggerimenti estetici?

Si: ogni finding e classificato su una scala di gravita (Bloccante, Alto, Medio, Basso, Nit) cosi puoi triagare cosa fixare prima del merge e cosa rimandare. Alla fine ricevi un verdetto di merge esplicito.

Vuoi un template su misura?

Costruiscine uno in poche domande — con la struttura corretta per il tuo standard.

Crea il tuo template