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.