Libro pubblicato

Ho provveduto a pubblicare su Lulu.com il libro nel quale sono raccolte le considerazioni, e i post scritti in questo blog sulla programmazione C++. Il libro è disponibile al seguente collegamento ipertestuale:
http://www.lulu.com/spotlight/MaxShire

In formato Ebook con immagini.

Efficienza

Alcune persone ritengono che le ottimizzazioni premature per un sistema sono la radice di ogni male. Al contrario, l'efficienza deve essere tenuta a mente durante gli sforzi di progettazione ed implementazione. Comunque non significa che il progettista deve preoccuparsi delle micro efficienze, ma deve considerare l'efficienza di primo ordine. La migliore strategia per produrre efficienza è la pulizia e una progettazione semplice. Solo questo tipo di progettazione può rimanere relativamente stabile durante il ciclo di vita del progetto, e serve da base alla calibrazione delle performance. Evitare il gigantismo che si nota nei progetti di grandi dimensioni è essenziale. Troppo spesso le persone aggiungono delle funzioni “solo in caso che”, e finiscono per duplicare o quadruplicare le dimensioni del programma, ed il tempo di esecuzione ne soffre. La cosa peggiore è che sistemi troppo elaborati, sono difficili da analizzare, e diventa difficile distinguere le componenti evitabili da quelle inevitabili. Quindi l'analisi di base e l'ottimizzazione viene scoraggiata. L'ottimizzazione deve essere il risultato delle analisi e delle misure delle performance, non una modifica a caso del codice. Specialmente per sistemi di grandi dimensioni le intuizioni del programmatore o del progettista non fanno da guida per l'efficienza del sistema. E' importante evitare costruzioni inefficienti di per sé, e attenzione nell'ottimizzare un livello accettabile di performance. Similarmente, è importante minimizzare l'uso di costrutti e programmi non portabili, in quanto condannano il programma ad essere eseguito su vecchi (meno potenti e/o più costosi) computer.  

Manutenzione del software

La parola “manutenzione” è fuorviante in quanto suggerisce un'analogia con l'hardware; ma il software non ha bisogno di essere lubrificato, né vi sono parti in movimento che si usurano, o vi sono crepe nelle quali l'acqua possa accumularsi, e fare ruggine. Il software può essere copiato esattamente, ed inviato a lunga distanza con un costo quasi nullo.

Le attività che sono note come manutenzione del software sono in realtà ri-progettazioni e re-implementazioni che avvengono durante il normale ciclo di sviluppo. Quando la flessibilità, l'estensione e la portabilità sono enfatizzate durante la progettazione, le sorgenti tradizionali dei problemi di manutenzione sono coinvolti direttamente.

Come i test, la manutenzione non deve essere ritardata o separata dallo sviluppo principale del sistema. In particola, è importante avere una certa continuità nel gruppo di persone coinvolte nel progetto. Non è facile trasferire la manutenzione ad un gruppo di persone nuove che non hanno avuto collegamenti con i progettisti e gli sviluppatori originali. Quando sono necessari cambiamenti di grandi dimensioni, ci deve essere enfasi nel trasferire le conoscenze e la comprensione della struttura del sistema attuale alle nuove persone coinvolte. Se la “squadra manutenzione” si domanda quale sia l'architettura del sistema e vien lasciata da sola a domandarsi come debbano essere fatte le modifiche e la loro implementazione, la struttura si deteriora rapidamente sotto il peso delle nuove patch locali. La documentazione tipicamente deve includere i dettagli necessari per aiutare le nuove persone a comprendere le idee ed i principi chiave.

Testing

Un programma che non è stato testato non funziona. L'ideale di progettare e verificare un programma funzionante in prima battuta non è ottenuto per la maggior parte dei programmi. Dobbiamo puntare verso l'ideale, ma non dobbiamo pensare che queste verifiche siano semplici.

“Come testare?” - E' una domanda alla quale non si può dare una risposta generale; “Quando testare?”, invece ha una risposta semplice, presto ed il più spesso possibile. Le strategie di prova possono essere generate come parte della progettazione e degli sforzi d'implementazione, o sviluppate in modo parallelo ad essi. Ritardare un testing serio sino al termine dell'implementazione è una prescrizione data per consegne ritardate e rilasci incompleti.

Quando è possibile il sistema deve essere progettato specificatamente per essere facile da verificare; in particolare i meccanismi di test possono essere inclusi all'interno del sistema stesso. A volte non viene realizzato a causa della paura di creare costi eccessivi ed una ridondanza non necessaria del codice quando si tratta di fare test di consistenza di grandi strutture dati. Questa paura è mal riposta, in quanto l'eccesso di codice necessario per i test, può essere rimosso prima della consegna del sistema. I commenti sono qualcosa di utile in questo caso. Più importanti di una serie di test è l'idea che la struttura di un sistema debba avere una possibilità ragionevole per convincere noi stessi e i nostri clienti che possiamo eliminare gli errori attraverso un controllo statico, una analisi statica e le verifiche. Quando una strategia per una tolleranza all'errore viene sviluppata, una strategia di test può essere sviluppata come complementare e vicina al relativo aspetto del sistema completo. Se la fase di testing viene scartata durante la progettazione, durante i test, quindi poco prima della consegna, potrebbero risultare problemi di manutenzione. L'interfaccia tra le classi e le loro dipendenza sono un buon punto per iniziare a lavorare sulla strategia di test.

Determinare quanto verificare è di solito difficile. Comunque, poche verifiche sono un problema più comune rispetto all'eccesso; esattamente quante risorse debbano essere allocate per i test confrontandoli con la progettazione e l'implementazione dipende dalla natura del sistema. Comunque come regola di massima, si suggerisce di allocare più risorse all'inizio dello sviluppo del sistema per verificarlo. I test inoltre devono essere focalizzati sui problemi che hanno conseguenze disastrose e che occorrono con frequenza.

Uso dei modelli

Quando si scrive un articolo, è necessario trovare un modello adatto da seguire. Piuttosto che cercare di trovare articoli che trattano lo stesso argomento. Bisogna trovare una struttura adatta all'argomento trattato. In questo modo è possibile modificare il testo in modo da aggiungere frasi, informazioni e dettagli in modo logico, senza dover alterare la struttura di tutto l'articolo. L'uso di sistemi già esistenti per realizzare nuovi progetti è la norma piuttosto che l'eccezione in tutte le forme di costruzione creativa. Quando è possibile, la progettazione e la programmazione devono essere basate su lavori precedenti. I limiti di questa libertà consente al programmatore di basare la propria attenzione solo su pochi argomenti alla volta. Iniziare un progetto principale, “dalla bozza su carta” può essere divertente. Comunque spesso una descrizione più attenta di questo fenomeno è “ubriacante” e il risultato conduce a progetti alternativi lasciati a metà. Avere un modello non è una costrizione e non richiede che il modello sia seguito fedelmente; libera semplicemente il designer dal considerare un aspetto del progetto alla volta.

L'uso dei modelli è inevitabile, in quanto il progetto verrà sintetizzato dall'esperienza di tutti i progettisti. Avere un modello esplicito rende la scelta di un modello una decisione cosciente, fa assunzioni esplicite, definisce un vocabolario comune, fornisce una struttura iniziale per il progetto, e aumenta la probabilità dei progettisti di ottenere un comune approccio. Naturalmente la scelta del modello iniziale è un passo importante in fase di progettazione e spesso può essere fatto solo dopo una ricerca di modelli potenziali e attenta valutazione delle alternative. Inoltre in molti casi è adattabile solo dopo una comprensione delle modifiche necessarie per adattarlo alle idee particolari della nuova applicazione.

La progettazione del software è complessa, bisogna cercare maggior aiuto possibile. Non bisogna rifiutare l'uso di modelli con sdegno liquidandoli come “imitazioni”. L'imitazione è una forma di appiattimento, ma l'uso di modelli provenienti da precedenti lavori è d'ispirazione, nei confini definiti dalla legge del copyright, è una tecnica innovativa che funziona in tutte le arre di lavoro. Alcuni definiscono questo uso di modelli come “riuso del progetto”.

E' una buona idea per il progettista conoscere tutte le soluzioni popolari esistenti per una cerca applicazione. Come programmatore si preferisce le soluzioni che abbiano del codice associato ad esse come esempio concreto. Le persone che usano delle soluzioni standard spesso usano un vocabolario specializzato per comunicare tra loro stesse.

Sfortunatamente questo può diventare un linguaggio privato che tende ad escludere degli estranei dalla comprensione; è essenziale assicurare una comunicazione adatta tra le persone coinvolte nelle diverse parti del progetto, e anche con la comunità dei progettisti e programmatori nell'insieme. Ogni sistema di grandi dimensioni che ha successo è la ri-progettazione di un sistema di minori dimensioni. Non esistono eccezioni a questa regola. L'esempio più prossimo che si possa fare è quello di sistemi che hanno fallito e sono rimasti impanatati per anni con grandi costi, poi eventualmente sono diventati successi negli anni successivi alla loro data di completamento. Questi progetti casualmente e spesso inavvertitamente, hanno dapprima costruito una rete di sistemi non funzionanti, quindi sono stati trasformati in un sistema funzionante, e finalmente la ri-progettazione ha raggiunto gli scopi iniziali. Questo implica che è una follia progettare grandi sistemi direttamente dalla bozza. Maggiori sono le dimensioni del sistema da costruire, maggiore importanza avrà il modello con il quale si lavora. E per sistemi di grandi dimensioni, il solo modello accettabile deve essere un sistema più piccolo ma funzionante e simile ad esso.

Il ciclo di Sviluppo

Sviluppare un sistema è un'attività iterativa. Il suo ciclo principale è formato da ripetuti passi attraverso la sequenza:

1. Esaminare il problema;
2. Creare un progetto generale;
3. Trovare componenti standard (e personalizzarli per il progetto);
4. Creare nuovi componenti standard (personalizzarli per il progetto);
5. Costruire il progetto.

L'analogia da usare, è la linea di assemblaggio di un'auto. Per il progetto in generale, deve esistere il design della nuova auto da creare. Poi si passa alle caratteristiche da fornire alla nuova auto definendone le proprietà nel dettaglio. Decidere quali proprietà sono volute, o fornire una linea guida di quali proprietà si vuole ottenere. Se ben realizzata questo tipo di lavoro viene svolto da una sola persona illuminata, e spesso viene chiamata vision. E' abbastanza comune per progetti privi di obbiettivi chiari di fallire per l'una o l'altra ragione. Il primo passo da considerare è quali componenti sono disponibili nell'inventario aziendale, o acquistabili da fornitore. I componenti trovati devono quindi trovare posto nella realizzazione della nuova auto, ma posso anche non essere del tutto adatti. Tuttavia si può pensare che “al successivo lancio”, i componenti saranno stati modificati per adattarsi all'auto. Ad esempio si può trovare un motore delle dimensioni adatte, ma che sia di potenza minorata. Il fornitore del motore potrebbe aggiungere una turbina per compensare alla potenza mancante, ma ciò non deve influenzare il disegno di base del motore.Nel caso dello sviluppo del software le classi polimorfiche e i templates sono utilizzati come componenti personalizzabili. Tuttavia non è facile creare estensioni arbitrarie a queste classi senza previsione o cooperazione da parte del gestore di queste classi. Da notare che questo modello di sviluppo funziona solo quando si ragiona a lungo termine; se il vostro orizzonte riguarda solo il prossimo rilascio del software, la creazione e la manutenzione delle componenti standard non ha senso. Questo tipo di organizzazione riguarda compagnie la cui vita abbia la durata di molti progetti, le cui dimensioni richiedano l'investimento in questa attrezzatura extra (per la progettazione, programmazione, gestione dei progetti) e formazione ( di programmatori, progettisti e manager). Si tratta di una struttura base di una fabbrica di software. Inoltre i componenti standard non possono essere considerati come universali. Puntare all'universalità in un progetto iniziale è la ricetta sicura per il fallimento; uno dei motivi per la creazione del ciclo di sviluppo è quello di ottenere esperienza.

Il processo di Sviluppo

Lo sviluppo del software è un processo iterativo ed incrementale. Ogni passo del processo è rivisto ripetutamente durante lo sviluppo, ed ogni revisione rifinisce il prodotto finale. In generale, il processo non ha un inizio ed una fine. Quando si progetta e implementa un sistema, si comincia da una base formata da librerie, progetti e applicazioni scritte da altri. Quando si finisce si lascia il grosso della progettazione e del codice ad altri per essere rifinito, e portato su altri sistemi. Naturalmente ogni progetto specifico ha un inizio e un termine, ciò è importante per definirne l'obiettivo e le dimensioni nel tempo. Comunque la pretesa di cominciare da zero può causare seri problemi. Inoltre la pretesa di una data di consegna inderogabile causa seri problemi ai propri successori. Il processo di sviluppo è formato da tre livelli:

• Analisi, definire l'obiettivo del problema da risolvere
• Progettazione, creare una struttura generale del sistema
• Implementazione, scrivere e verificare il codice

Si ricordi la natura iterativa di questo processo, in quanto i tre livelli non sono in ordine: Da notare che alcuni aspetti maggiori del programma di sviluppo non sono in livelli separati perché si tratta di processi pemeabili tra loro.

• Sperimentazione
• Verifica con test
• Analisi della progettazione ed implementazione
• Documentazione
• Gestione

La “gestione” del software è quella che ha maggiori iterazioni nel processo di sviluppo; è importante che analisi, progettazione ed implementazione non siano troppo staccate tra loro nel programma di sviluppo, e le persone coinvolte condividano le proprie conoscenze e comunichino effettivamente. In progetti di grandi dimensioni, spesso non accade. Gli individui si spostano da un livello all'altro durante il progetto, il solo modo di trasferire queste informazioni è la testa delle persone. Tuttavia le compagnie tendono a creare delle barriere tra i progettisti di maggiore calibro come protezione dal licenziamento, e per esempio, coloro che sono semplici programmatori. Le persono dovrebbero essere incoraggiate a condividere le informazioni tra loro, attraverso una etichetta con un grado di formalità appropriato.