EthicSoft Informatica 18 Regole Per Un Buon Software

Scrivere un buon software

di: Silvia Saltarelli
Licenza:
I contenuti di questo articolo sono proprietà intellettuale dei relativi autori e protetti ai sensi dell'art. 1 della legge italiana sul diritto d'autore n. 633 del 22 aprile 1941.
La copia, parziale o integrale, è illegale escluso il caso di citazioni di lunghezza massima di un singolo paragrafo e il cui testo sia completamente incluso in un link a questa pagina.

ok

Un buon prodotto software

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

Ma oltre a controllarne la correttezza, cosa serve perché il software sia buono? Sicuramente impegno, dedizione, concentrazione, solide basi e darsi delle regole per creare un buon programma, piccolo o grande che sia.

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 il coordinamento e la supervisione delle librerie condivise e dei framework.
  • Scegliere per variabili e funzioni nomi brevi ed auto espliciti.

DataBase

  • Assumere un 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.

Latest posts by Silvia Saltarelli (see all)

Licenza:
I contenuti di questo articolo sono proprietà intellettuale dei relativi autori e protetti ai sensi dell'art. 1 della legge italiana sul diritto d'autore n. 633 del 22 aprile 1941.
La copia, parziale o integrale, è illegale escluso il caso di citazioni di lunghezza massima di un singolo paragrafo e il cui testo sia completamente incluso in un link a questa pagina.