Linee guida per l'archiviazione di codice di qualità
Aggiornamento: novembre 2007
Nell'elenco riportato di seguito sono indicate alcune linee guida per l'archiviazione di codice di qualità.
Operazioni necessarie
Svolgere le operazioni di archiviazione prestando particolare attenzione alla qualità del codice.
Una scarsa qualità del codice durante l'archiviazione comporta inevitabilmente dei problemi nelle fasi successive del ciclo del prodotto. Tenere presente che i team generalmente non correggono i problemi troppo complessi, di difficile soluzione o rilevati in una fase troppo avanzata del ciclo del prodotto.
Utilizzare elenchi di controllo.
Tenere traccia delle tipologie di errori più frequenti e creare un elenco di controllo, composto inizialmente dagli errori più comuni commessi dal gruppo o dal reparto e successivamente personalizzato in base alle proprie esigenze specifiche, per facilitare la verifica del codice futuro.
Effettuare revisioni del codice.
Le revisioni del codice consentono ai programmatori di spiegare e comprendere meglio il codice sviluppato e agli altri di visualizzarlo in una nuova forma.
Scrivere unit test.
Il modo migliore per garantire la qualità consiste nello scrivere test di convalida di dati e algoritmi e verificare che non vengano ripetuti errori già commessi in precedenza. Esistono quattro tipi di unit test:
Unit test positivi: eseguono il codice nel modo previsto e verificano che venga prodotto il risultato atteso.
Unit test negativi: utilizzano intenzionalmente il codice in modo errato verificandone l'affidabilità e la validità della gestione degli errori.
Test di stress: eseguono il codice fino al raggiungimento dei limiti, con l'obiettivo di rilevare errori difficilmente individuabili relativi a risorse, tempificazione e rientro.
Test di inserimento di errori: evidenziano le anomalie rilevate nella gestione degli errori.
Per ulteriori informazioni, vedere Procedura: modificare unit test.
Utilizzare strumenti di analisi del codice.
Il modo più semplice per intercettare preventivamente gli errori consiste nell'aumentare il livello avvisi nel compilatore e utilizzare strumenti di analisi del codice. È fondamentale non ignorare mai un avviso e correggere il codice.
Per ulteriori informazioni, vedere Rilevamento e correzione di errori del codice C/C++ e Rilevamento e correzione degli errori del codice gestito.
Non utilizzare linguaggio inappropriato nel codice sorgente.
Il codice sorgente non deve contenere riferimenti e linguaggio inappropriati in quanto determinate frasi o nomi, in modo particolare riferimenti a entità politiche, potrebbero urtare la suscettibilità dei clienti di alcuni paesi. Verificare quindi che il codice non contenga riferimenti e linguaggio di questo tipo e segnalare gli eventuali errori.
Creare elementi di lavoro.
Completare sempre il lavoro e creare elementi di lavoro per i commenti TODO, REVIEW, BUG e UNDONE. Per ulteriori informazioni, vedere Procedura: aggiungere nuovi elementi di lavoro.
Operazioni da evitare
Funzionalità senza una specifica.
Non scrivere codice senza una specifica. Innanzitutto, scrivere una specifica e sottoporla a revisione. La mancanza di una specifica all'interno del codice non consente al team di lavoro di verificare il funzionamento del codice e di rilevare gli errori e può causare problemi di comunicazione tra colleghi, oltre al rischio di non comprendere appieno le esigenze del cliente e fornire quindi un prodotto di qualità scadente. Per ulteriori informazioni, vedere Progetti Team di Team Foundation.
Raggiungere una fase importante dello sviluppo senza aver effettuato un'impostazione del prodotto.
Il team che si occupa del testing deve avere la possibilità di poter impostare il prodotto sui propri computer, anche se dovesse trattarsi solo di un'impostazione di prova. Per ulteriori informazioni, vedere Cenni preliminari su Team Foundation Build.
Operazioni consigliate
Utilizzare uno stile di codifica uniforme.
Se il codice sviluppato da tutti i componenti del team presenta lo stesso stile, il prodotto sarà caratterizzato da una maggiore leggibilità, uniformità, gestibilità e qualità complessiva. È importante quindi creare delle linee guida e assicurarsi che vengano seguite scrupolosamente dal proprio team. I principali vantaggi derivanti dalla scelta di un determinato stile sono l'uniformità e la facilità nel riconoscere modelli di codifica. Adottare quindi uno stile e utilizzarlo.
Scrivere unit test prima di scrivere il codice.
Lo sviluppo con test preliminare è una metodologia molto importante e la scrittura di unit test preventivi consente di realizzare diversi obiettivi di qualità:
Viene garantita la scrittura di unit test.
Viene garantita una maggiore facilità delle operazioni di testing sul codice che spesso consente di ottenere una migliore coesione del codice e un accoppiamento più debole tra i moduli.
La determinazione della modalità di testing più adatta per una progettazione consente spesso di identificare la progettazione più appropriata per il proprio lavoro.
Per ulteriori informazioni, vedere Procedura: modificare unit test.
Rendere il codice portabile su altre piattaforme.
La progettazione e la codifica ai fini della portabilità rendono il codice più affidabile, anche se non si prevede di renderlo disponibile su un'altra piattaforma. La portabilità del codice presenta i seguenti vantaggi:
Migliore capacità di previsione.
Maggiore chiarezza sui tipi di dati e sulle finalità della progettazione.
Capacità del codice di supportare nuove piattaforme nel futuro.
Effettuare il refactoring del codice esistente in funzioni più piccole.
Il refactoring consente di aggiornare il codice meno recente. Tentare di correggere sistemi meno recenti di grandi dimensioni può essere difficile, in quanto la complessità di alcune interazioni porta ad affrontare con riluttanza anche la modifica di un semplice commento.
Per effettuare un refactoring corretto, è necessario innanzitutto includere attività di unit testing per evitare che vengano introdotti nuovi errori. Successivamente, separare funzioni di grandi dimensioni in insiemi di funzioni più piccole, senza modificare la funzionalità. Le linee guida sono le seguenti:
Ogni funzione più piccola deve eseguire solo un tipo di attività, ad esempio l'interfaccia utente, l'accesso al database, l'interazione COM a una singola interfaccia e così via.
Dopo aver eseguito completamente il refactoring di tutte le funzioni di un sottosistema, è possibile modificare singole funzioni di piccole dimensioni senza influenzare l'intero sistema. È possibile aggiungere, rimuovere o migliorare la funzionalità agendo su una funzione alla volta.
Per ulteriori informazioni, vedere Refactoring di classi e tipi.
Revisionare il codice esistente.
Gli errori spesso sono concentrati in moduli specifici. Se il nuovo codice non presenta problemi ma include alcuni moduli del codice precedente contenenti errori, concentrare la revisione solo su quel tipo di moduli. Se le interconnessioni con il codice precedente sono molto numerose, il refactoring spesso contribuisce alla risoluzione dei problemi. Per ulteriori informazioni, vedere Rilevamento e correzione di errori del codice C/C++ e Rilevamento e correzione degli errori del codice gestito.
Eseguire un'istruzione alla volta tutti i percorsi del codice in un debugger.
Uno dei modi migliori per verificare il codice consiste nell'eseguirlo un'istruzione alla volta in un debugger. In corrispondenza di ogni riga verificare che l'azione prevista si verifichi effettivamente. L'esecuzione in un debugger di tutti i percorsi del codice un'istruzione alla volta è simile a un unit test riga per riga. La procedura è alquanto lunga e monotona, ma consente di verificare in modo efficace il comportamento previsto.
Operazioni non consigliate
Non utilizzare come specifica un documento relativo ai requisiti.
Non tentare di interpretare una specifica da un documento dei requisiti. L'interpretazione personale potrebbe essere diversa da quella del responsabile del programma o del tester. Interpretazioni diverse potrebbero portare a un'implementazione che non soddisfa le aspettative degli altri.