Francesco Prelz
INFN - Sezione di Milano
Il corso è articolato in 19 lezioni di 2 ore, più un semirario sugli scripting language. Ogni lezione termina con un "esercizio" di programmazione, che viene ripreso e commentato la volta successiva. Gli stessi esercizi vengono ripresi in Laboratorio. E' utile riuscire a pensare all'esercizio proposto fra una lezione e l'altra, attraverso la frequentazione dell'aula, oppure utilizzando il proprio computer domestico. A tal scopo è disponibile, per chi non avesse la possibilità di installare Linux sul PC di casa, un kit di 3 floppy disk e un CD che permettono di ottenere un ambiente di sviluppo adatto per la soluzione degli esercizi di programmazione senza toccare il sistema installato. Il kit dovrebbe funzionare senza interventi su qualunque PC (dal 386 in su, ma sul 386 è decisamente lento) dotato di scheda video VGA, Mouse PS/2 e CD-ROM IDE.
Laboratorio...
Probabilmente nessuno dei programmi che verrà sviluppato durante questo corso richiederà un serio sforzo di progettazione, perché l'intero progetto sarà sotto il controllo di ciascuno (= una sola persona alla volta). La situazione, per certi versi ideale, nella quale una sola persona controlla un intero progetto software è spesso (e in modo sempre crescente, anche nel campo della programmazione "applicata" alla ricerca scientifica) impossibile da realizzare.
Esistono valide approssimazioni di questa situazione: nei progetti di grandi dimensioni si tendono ad "incapsulare" le funzioni, prima definendo in modo chiaro le interfacce di comunicazione, e poi assegnando lo sviluppo delle funzioni stesse ad un piccolo gruppo di sviluppatori molto affiatati. E' essenziale inoltre che sia piccolo ed affiatato anche il gruppo alla guida del progetto: in taluni progetti software open-source il creatore del progetto ha sempre l'ultima parola su tutte le modifiche proposte. Più in generale esiste la figura dell'"architetto" di un progetto software, a cui compete la responsabilità di garantire che le parti sviluppate da gruppi di sviluppo diversi possano essere integrate assieme.
Tuttavia, quando le mani che lavorano su un progetto software diventano tante (anche per il ricambio generazionale), i problemi sono inevitabili. Citando una delle più lucide analisi del problema (Frederick P. Brooks, Jr., "The Mythical Man-Month"):
"The fundamental problem with program maintenance is that fixing a defect
has a substantial (20-50 percent) chance of introducing another. So the whole
process is two steps forward and one step back.
Why aren't defects fixed more cleanly?
First, even a subtle defect shows
itself as a local failure of some kind. In fact it often has system-wide
ramifications, usually nonobvious. Any attempt to fix it with minimum effort
will repair the local and obvious, but unless the structure is pure or
the documentation very fine, the far-reaching effects of the repair
will be overlooked.
Second, the repairer is usually not the man who wrote
the code, and often he is a junior programmer or trainee."
Questa analisi evidenzia due caratteristiche di un programma che può essere mantenuto con poca fatica nel tempo:
Di fatto, in un progetto software di una certa dimensione,
la scrittura del codice, alla cui tecnica dedicheremo la massima
parte di questo corso,
non occupa quasi mai più del 20 % della durata complessiva del
progetto stesso.
Come viene organizzato allora il restante 80 %, in modo da tutelare la
riuscita del progetto? Esistono varie scuole di pensiero al riguardo,
ed una letteratura sconfinata. Prendiamo un esempio dal campo della
Fisica delle particelle, precisamente lo sviluppo dei sistemi online
per l'esperimento ATLAS al Cern:
Il processo di verifica del software può essere ulteriormente articolato. Come si nota, il fatto che gli sviluppatori riescano a parlare fra di loro non viene considerato per nulla scontato:
Analizziamo alcuni passi delle GNU coding rules.