Fagan code inspection

La Fagan code inspection è una metodologia sviluppata da Michael Fagan alla IBM negli anni ’70. La metodologia prevede che un gruppo di esperti esegua una serie di passi per verificare la correttezza del codice sorgente al fine di individuare eventuali errori, incongruenze o altri problemi.
È la più diffusa tra le tecniche di ispezione, nonché la più rigorosa e definita.

Ruoli

Essendo un’attività di gruppo, nella Fagan code inspection vengono identificati diversi ruoli:

• Moderatore: è colui che coordina i meeting, sceglie i partecipanti e ha la responsabilità di far rispettare le regole di cui parleremo tra poco. È di solito una persona che lavora ad un progetto diverso da quello in esame in modo da evitare conflitti di interessi.
• Readers e Testers: non sono persone diverse, semplicemente a seconda dei momenti i partecipanti possono coprire uno di questi due ruoli: i primi leggono il codice al gruppo, mentre i secondi cercano difetti al suo interno. La lettura del codice è una vera e propria parafrasi di esso, ovvero un’interpretazione del codice nella quale si spiega quello che fa ma seguendo comunque la sua struttura.
• Autore: è colui che ha scritto il codice sotto ispezione; è un partecipante passivo che risponde solo a eventuali domande. È simile al ruolo del cliente nell’eXtreme Programming: pronto a rispondere a qualsiasi domanda per accelerare il lavoro degli altri.

Processo

Definiti i ruoli, secondo la tecnica Fagan di ispezione del codice il processo si articola come segue:

1. Planning: in questa prima fase il moderatore sceglie i partecipanti, si definiscono i loro ruoli e il tempo da dedicare alla ispezione, pianificando anche i vari incontri.
2. Overview: viene fornito a tutti i partecipanti materiale sul progetto per permettere loro di farsi un’idea del contesto in cui l’oggetto dell’ispezione si inserisce in ottica della riunione vera e propria.
3. Preparation: i partecipanti “offline” comprendono il codice e la sua struttura autonomamente sulla base anche del materiale distribuito nella fase precedente;
4. Inspection: la vera e propria fase di ispezione. In questa fase si verifica che il codice soddisfi le regole definite in precedenza e si segnalano eventuali problemi o anomalie. Durante l’ispezione, il gruppo di esperti esamina il codice riga per riga, confrontandolo con le specifiche e cercando di individuare errori, incongruenze o altri problemi.
5. Rework: una volta individuati i problemi, l’autore del codice si occupa di correggere i difetti individuati.
6. Follow-up: possibile re-ispezione del nuovo codice ottenuto dopo la fase precedente.

Se la maggior parte delle fasi è abbastanza autoesplicativa, è bene dare uno sguardo più approfondito all’attività di ispezione vera e propria.

Ispezione

Durante la fase di ispezione, l’obiettivo è trovare e registrare i difetti senza correggerli: la tentazione di correggere i difetti è sicuramente fortissima ma non è compito dei partecipanti alla riunione farlo. Ciascuno di loro potrebbe infatti avere le proprie idee e preferenze e metterli d’accordo potrebbe non essere facile: si preferisce quindi che sia l’autore del codice a correggere successivamente i problemi trovati.

Per evitare ulteriormente di perdere tempo sono previste al massimo 2 sessioni di ispezione di 2 ore al giorno, durante le quali lavorare approssimativamente a 150 linee di codice all’ora. Quest’ultimo vincolo è molto variable in quanto cambia in base al linguaggio, al progetto, all’attenzione ai dettagli richiesta e alla complessità.

Una possibilità prevista in questa fase è anche quella di fare “test a mano”: si analizza il flusso di controllo del programma su una serie di casi di test così da verificarne il funzionamento.

Ancora più prominente è però l’uso di una serie di checklist, di cui parliamo nel prossimo paragrafo.

Checklist

Rispetto all’attività di testing, che a partire dai malfunzionamenti permetteva di risalire ai difetti e dunque agli sbagli commessi, il thought-process per le checklist è inverso: si parte dagli sbagli che più frequentemente hanno portato ad inserire determinate anomalie nel codice e si controlla che nessuno di questi sia stato commesso nuovamente.

In letteratura è reperibile la conoscenza di tutto ciò che è meglio evitare poiché in passato ha portato più volte ad avere anomalie nel codice. Tale conoscenza è raccolta in checklist comuni per i vari linguaggi.

Inoltre, l’ispezione del codice funziona così bene anche perché tali checklist possono essere redatte internamente all’azienda, in base all’esperienza passata e alla storia di un determinato progetto. \ Man mano che il progetto va avanti, l’individuazione di un nuovo sbaglio si traduce in un’evoluzione della checklist: dalla prossima ispezione si controllerà di non aver commesso lo stesso errore.

Esempio NASA

La NASA nel suo Software Formal Inspections Guidebook (1993) ha formalizzato circa 2.5 pagine di checklist per C e 4 per FORTRAN.

Sono divise in functionality, data usage, control, linkage, computation, maintenance e clarity.

Di seguito sono elencati alcuni esempi dei punti di tali checklist:

• Does each module have a single function?
• Does the code match the Detailed Design?
• Are all constant names upper case?
• Are pointers not typecast (except assignment of NULL)?
• Are nested #include files avoided?
• Are non-standard usage isolated in subroutines and well documented?
• Are there sufficient comments to understand the code?

Struttura di incentivi

Perché l’ispezione del codice come è stata descritta funzioni bene, occorre prevedere una serie di dinamiche positive di incentivi al suo interno.

In particolare, è importante sottolineare che i difetti trovati non devono essere utilizzati per la valutazione del personale: questo evita che i programmatori nascondano i difetti nel proprio codice, minando la qualità del prodotto.

Dall’altro canto si possono invece considerare per la valutazione di readers e tester i difetti trovati durante l’ispezione, in modo che questi siano incentivati a fare l’ispezione più accurata possibile.

Variante: active design reviews

Purché il processo di ispezione funzioni al meglio le persone coinvolte devono partecipare, ma per come abbiamo descritto l’attività di Fagan Code Inspection nulla vieterebbe ai revisori non preparati di essere presenti ma non partecipare, rimanendo in silenzio e pensando ad altro.

Innanzitutto, per sopperire a questo problema i partecipanti andrebbero scelti tra persone di adeguata esperienza e sopratutto assicurando che nel team vi siano revisori per diversi aspetti nel progetto.

Qualora questo non bastasse, una variante del processo che prende il nome di active design review suggerisce che sia l’autore a leggere le checklist e sollevare questioni all’attenzione dei revisori, chiedendo diverse domande. Essendo presi direttamente in causa, i revisori saranno quindi costretti a partecipare.