Linee guida per l'archiviazione di codice di qualità
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 Creazione ed esecuzione di unit test per il codice esistente.
Utilizzare strumenti di analisi del codice.
Il modo più semplice per intercettare preventivamente i bug 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 Analisi della qualità del codice gestito tramite analisi del codice.
Verifica della qualità del codice C/C++ tramite analisi del codice e Analisi del codice di database per migliorare la qualità del codice.
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 Creare un elemento 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 Pianificazione e rilevamento di progetti.
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 Compilazione dell'applicazione.
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 Creazione ed esecuzione di unit test per il codice esistente.
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 (Progettazione classi).
Revisionare il codice esistente.
I bug spesso sono concentrati in moduli specifici. Se il nuovo codice non presenta problemi ma include alcuni moduli del codice precedente contenenti bug, 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 Analisi della qualità del codice gestito tramite analisi del codice.
Verifica della qualità del codice C/C++ tramite analisi del codice e Analisi del codice di database per migliorare la qualità del codice.
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.