Come realizzare un buon software

Un buon prodotto software, come ottenerlo?

Come in tutti i campi, anche nell'informatica un buon prodotto deve funzionare correttamente: Se non va, è completamente inutile.

Un software funzionante può avere livelli di qualità molto differenti a seconda del metodo usato e delle decisioni prese in fase di sviluppo.

Quindi, oltre a controllarne la correttezza, come produrre un software che sia buono? Sicuramente impegno, dedizione, concentrazione, solide basi e darsi delle regole per creare un buon programma, piccolo o grande che sia.

Oltre alle varie tecnologie e alle skill degli sviluppatori, esistono effettivamente regole che, se applicate con consapevolezza e misura, cambiano drasticamente la qualità del prodotto software realizzato, diamogli un’occhiata:

Processo di sviluppo

• Una lista di priorità permette di allocare al meglio le risorse; è fondamentale affrontare gli elementi più importanti per primi.
• Dare priorità  alle parti con più incognite e difficoltà, lasciando quelle più scontate e facili per ultime.
• Studiare la lista delle attività proposte per vedere se vi siano duplicati che suggeriscano l’uso di framework o librerie.

Funzioni

• Suddividere il codice tra le funzioni in base ai “task” o agli “eventi” richiamati dal software.
• Le funzioni più usate devono essere inferiori a 100 righe, con qualche eccezione per le procedure batch.
• Evitare troppi parametri; molti parametri di solito indicano un problema di design o con il particolare linguaggio che si sta utilizzando.
• Se si lavora in un gruppo numeroso, assegnare ad uno sviluppatore esperto o ancora meglio ad un technical leader il coordinamento e la supervisione delle librerie condivise e dei framework.
• Scegliere per variabili e funzioni nomi brevi ed auto espliciti.

DataBase

• Assumere una buon DBA (Amministratore di DataBase) o almeno un buon Data Modeler.
• Le informazioni sugli oggetti del dominio applicativo vanno nel database, non nel codice, questo perché è più facile controllare, cercare, ordinare e filtrare i dati associati a questi oggetti se sono in un database piuttosto che dentro il codice di programmazione.
• Nelle basi di dati seguire le normalizzazioni relazionali; in caso di dubbi per una grande tabella è più performante di due tabelle più piccole.
• Propendere verso l’utilizzo del database per la comunicazione tra funzioni piuttosto che usare variabili condivise.

Usabilità 

• Comprendere il background degli utenti, non solo i requisiti. Sia che si tratti di esperti che di persone nuove sul campo è giusto creare il software in modo che sia utilizzabile e comprensibile da tutti.
• Affiancare ogni campo non banale da compilare con una descrizione o una nota; l’utente che deve inserire informazioni rischia di sbagliare se non è già  esperto del software.

Debug

• Mettere sotto Unit Testing almeno tutte le funzioni core, seguite da tutte le funzioni di input/output da rete o disco, anche se non core.
• Abbondare con i warning e limitare gli errori: Un robusto insieme di warning seguiti dagli unici veri errori permette di localizzare e identificare le cause degli errori in modo facile e veloce.

Documentazione

• Commentare in testa ogni sezione concettualmente autonoma di codice, per rendere tutto più ordinato e capire che cosa fa ogni singola parte del codice sorgente.
• Documentare le ragioni che stanno dietro alle decisioni importanti di progettazione, in modo che si possa risalire all'origine dei problemi in futuro; lo scopo non è quello di incolpare le persone, ma di imparare dagli errori di tutti e trovare una soluzione.

Se si vuole scrivere un buon software e avere la soddisfazione di vedere il nostro lavoro perfettamente funzionante queste sono alcune regole fondamentali da cui prendere spunto.