Quali strumenti e metodologie di code review utilizzare per il codice consegnato da un'agenzia?

Quando lanciate tool statici non limitatevi agli standard di formattazione, ma controllate anche le regole SAST orientate alla sicurezza. SQL injection, riferimenti diretti non sicuri a oggetti (IDOR) e punti di validazione dell'input carenti vengono intercettati molto facilmente dalle regole automatiche. Verificate pure la code coverage: se l'agenzia non ha scritto unit test, fare refactoring di quel codice sarà un incubo.

L'anno scorso abbiamo preso in consegna in modo simile il backend di un'app mobile costato 40.000 dollari. Gli scanner automatici davano luce verde xké la sintassi era impeccabile. Due settimane dopo la messa in produzione il db è andato in blocco: l'agenzia nn aveva inserito manco una foreign key o un indice sulle tabelle relazionali. Il tool qst cose nn le vede mai.

Durante la fase di handover abbiamo pagato 2.500 dollari a un architect senior indipendente per una revisione approfondita di 15 ore. Ci ha segnalato 4 gravi errori architetturali che avrebbero bloccato la scalabilità e 8 falle di autorizzazione lasciate scoperte dall'agenzia. Soldi spesi benissimo, ce li siamo ampiamente ripagati.

Nei lavori fatti dalle agenzie non fatevi ingannare troppo dai report dei tool automatici. A volte le agenzie, giusto per non far scattare i warning degli strumenti di analisi, spezzettano le funzioni scrivendo codice apparentemente pulito, ma la business logic è un minestrone. I tool non certificano che il codice funzioni a dovere, dicono solo che rispetta le regole di sintassi.

La primissima cosa che potete fare già da domani: date un'occhiata alla cronologia del repository (git log). L'agenzia ha pushato tutto nel panico negli ultimi 3 giorni, oppure è andata avanti per 4 mesi con commit regolari e messaggi descrittivi? La disciplina nel versioning è il primo indicatore della qualità interna del codice.

Checklist per le consegne delle agenzie: 1) Sono state dimenticate le chiavi API dei servizi esterni dentro al codice? 2) Le licenze delle librerie open source sono compatibili con il vostro uso commerciale? 3) I passaggi per il deployment e l'installazione locale funzionano senza problemi seguendo un unico documento?

secondo me guardate assolutamente se hanno scritto i test. di solito le agenzie con la scusa del "non abbiamo fatto in tempo" non scrivono gli unit test, poi cambi una riga di codice e crolla tutta l'architettura.

abbiate un po' di pazienza con il nuovo collega senior. ereditare il codice scritto da qualcun altro è la cosa più frustrante al mondo per uno sviluppatore. i tool automatici servono almeno a evitare che le discussioni diventino personali, ancorandole a metriche oggettive.

Preso nota, grazie.

Mi chiedo anch'io.

Ti seguo.

Ottimo lavoro. La risposta varia molto in base al settore, non esiste una regola generale.

Lascio una nota, potrebbe servire.

la strada che sembra economica di solito finisce per costare cara e boh quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

se cerchi di cambiare tutto insieme niente si stabilizza. se scrivete qui il risultato, sarà uile anche ad altri.

Dopo aver vissuto questa cosa, il mio punto di vista è cambiato. Il codice senza documentazione di installazione non è tuo anche se ce l'hai in mano.

Se scrivete qui il risultato, sarà utile anche ad altri.

Sono d'accordo.

Lo sentiamo dire da tempo, ma da noi non è mai andata così. Il calendario dei pagamenti va legato alle fasi del lavoro, non alle date.

Io seguirei questa strada.

Sono passato da qui, vi racconto. Un report settimanale scritto sull'avanzamento è molto più utile che chiedere date.

Anche da noi è così. Chiunque abbia fretta su strumenti di code review si blocca nello stesso punto.

Inizia con un piccolo test, non impegnarti subito su tutto. Io seguirei questa strada.