| Lei pone una questione assai interessante e
di notevole rilievo. I ragazzi che frequentano gli ultimi anni delle scuole superiori, sanno in qualche modo programmare vuoi
in ragione di un proficuo insegnamento vuoi perché si sono perfezionati da soli. Molti posseggono un computer proprio
e dimostrano una grande agilità specie tra gli iscritti all'ITIS ed all'ITC.
Tuttavia le evidenti qualità manuali spesso si accompagnano ad una carente cultura professionale,
cioè ad un orientamento metodologico approssimatico e talora fuorviante. Se la lacuna non viene
corretta, nel mondo del lavoro si immette una persona che prima
o poi avrà difficoltà personali e creerà problemi agli altri. L'origine di tutti i
mali è l'antica concezione della programmazione come esclusivo esercizio logico-intellettivo (vedi
risposte 27 e 29). Invece oggi abbiamo capito che il programmatore, il quale
abitualmente sviluppa software applicativo, lavora in un contesto aziendale/istituzionale quantomai pratico.
L'astrazione è un esercizio né utile, né richiesto per sviluppare i
programmi di calcolo commerciale, statistiche attuariali, stampe di paghe e
stipendi.
Elenchiamo alcuni luoghi comuni con i relativi commenti.
Idee comuni |
Commenti |
| Il programma è la soluzione di un problema
logico. |
Il programmatore
applicativo non risolve
problemi logici ed invece crea un manufatto tecnologico sulla base di specifiche
tecniche o specifiche di programmazione
che gli dicono esattamente quello
che il programma dovrà fare. Dunque non si tratta affatto di un "problema
astratto" ma molto evidente. Quando le specifiche di programmazione non sono chiare ma
sembrano un rompicapo allora vuol dire che l'analista (che le ha preparate) non ha fatto
un buon lavoro. Il programmatore dovrà contestarle e mai accettarle come
fosse una sfida enigmistica. Quando a scuola si propongono
i programmi come fossero rompicapi matematici, l'allievo acquisisce una concezione errata del suo
futuro lavoro.
|
| Il problema è
risolto una volta per tutte. |
Al
contrario il programma applicativo viene continuamente modificato.
Dietro nuove esigenze che provengono dal mercato, dal governo,
dall'utenza e da mille altri motivi, l'analista ed il programmatore
modificano il programma. Le statistiche dicono che questo rimane fermo
soltanto qualche mese, ma ci sono programmi che cambiano più volte
nell'arco della settimana. I programmi matematici non cambiano nel tempo
dunque, se lo studente li prende come modello, parte con una concezione
professionale stravolta. |
| La difficoltà
principale risiede nella soluzione del problema |
Il programmatore
interpreta e traduce le specifiche tecniche, cioè progetta il programma (mediante
la pseudocodifica)
poi fà la codifica, quindi fà i test. Spesso viene coinvolto anche nella fase iniziale
di analisi. Dunque il suo lavoro è ben più complesso ed articolato. |
| |
analisi
(specifiche tecniche)
v
progetto del programma
v
codifica del programma
v
test
|
| Poiché il programma
è la soluzione di un problema logico, importante è che funzioni correttamente. |
Ci mancherebbe che una
azienda paghi ed il programma non funzioni a dovere ! E' ovvio che il programma debba dare i dati
richiesti ma
questo non basta. A causa dei continui aggiornamenti cui sarà
sottoposto, il programma applicativo deve essere
ben documentato, cioè deve essere progettato con
appositi schemi prima della codifica vera e propria.
|
| La logica del programma viene esplicata dal diagramma a blocchi. |
Il programma va progettato
con il diagramma a blocchi oppure con la pseudocodifica che vanno scelti
in modo da facilitare le successive fasi di codifica e di manutenzione. Il criterio è
questo:
si sceglie il diagramma più consono, cioè più simile al linguaggio di programmazione.
Dunque se il linguaggio è
l'Assembler si usa il diagramma a blocchi,
se il linguaggio è simbolico si usa la
pseudocodifica. Poiché il primo linguaggio è alquanto raro, ne
consegue che la pseudocodifica è di gran lunga più diffusa (sull'argomento vedi risposta n. 23).
|
| Mi trovo molto bene con il
diagramma a blocchi perché esplica la logica del problema. |
Nessun ingegnere sceglie il
diagramma di progetto dietro un capriccio personale, ma a seconda dei bisogni oggettivi
del lavoro. La regola da seguire è quella indicata nel punto precedente e
non sarà mai un criterio personalistico.
|
| La logica esplica le corrette
operazioni tra le variabili |
Le operazioni del programma
manipolano i campi informativi che sono precise porzioni di memoria. Soltanto in rari casi
questi si riferiscono a variabili astratte invece di regola
trattano valori molto pratici
quali lire, dollari, quintali, metri nonché nomi, descrizioni, colori ecc. |
| La trasparenza
non è una qualità necessaria. |
Al fine di essere facilmente
modificato il programma deve risultare chiaro in termini oggettivi e non
soltanto a livello individuale. La programmazione
strutturata ci dà le regole che ne stabiliscono la
trasparenza obbiettiva: 1) Vanno usate le strutture classiche:
- sequenza
- alternativa
- ripetizione
che garantiscono l'oggettiva
leggibilità
dell'algoritmo.
2) Vanno usati nomi
assolutamente trasparenti per i campi che hanno contenuto fisso e
quelli che hanno contenuto variabile, per le etichette ed altro. Es.
Interessi; Accrediti, Movimenti. E non Int; Acc; Mov che saranno
incomprensibili a chi modificherà il programma.
|
| Il diagramma a blocchi è sufficiente ad
illustrare la logica del problema. |
Il programma è composto da:
- le istruzioni
- le dichiarative
La pseudocodifica [o in
alternativa il diagramma a blocchi] serve per progettare le prime. Il diagramma dei campi che
riporta il flusso dei dati nei vari campi di memoria determina le
dichiarative (vedi risposta 39). I due schemi si completano l'uno con l'altro. Usare soltanto il primo ed
ignorare il secondo è un errore che causa una fatica maggiore del
necessario ed un minor controllo del risultato.
Purtroppo il diagramma dei campi è spesso usato in modo sciatto ed il futuro
professionista non lo sfrutta in modo conveniente.
|
Qualcuno può domandarsi: come mai allora si
continua a presentare la programmazione come soluzione di un problema
logico-matematico?
La risposta è
semplice. In particolari ambienti quali i laboratori scientifici e le case di produzione
del software, i metodi
di lavoro non contrastano con i luoghi
comuni sopra elencati. In tali speciali settori le idee
riportate a sinistra sono accettabili. Questi settori hanno
contribuito a circonfondere l'informatica di un certo alone lungo i
decenni e, sebbene siano minoritari, hanno
consolidato i luoghi comuni sopra elencati.
Tali settori lavorativi costituiscono
infatti un piccolo gruppo (specie nel nostro paese), invece la più parte degli addetti
informatici si
dedica al software applicativo che si conduce nelle banche, nelle
fabbriche, nelle aziende piccole e grandi, nei ministeri ecc. Il problema dunque è eminentemente concreto. La
maggioranza dei giovani che escono dalle nostre scuole non và alla produzione scientifica o
industriale per la quale sarebbero abbastanza ben preparati, ma nelle aziende e
nelle istituzioni dove invece valgono i principi opposti. Si potrebbe dire
che la scuola prepara per una professione del tutto improbabile, e di fatto genera dei disorientati.
Un professore una volta mi obbiettò che la scuola
insegna a fare i programmi software più impegnativi e dunque non va
criticata.
Questa
osservazione è valida in astratto perché di fatto anche la programmazione
applicativa è assai esigente. Il calcolo degli interessi bancari non è
meno importante del calcolo di un'orbita satellitare. Ogni lavoro ha la
sua dignità, e gli studenti devono essere preparati esattamente per i
compiti che svolgeranno e non per le cose che non faranno mai.
Indietro |
38. Il
problema è come impostare professionalmente un ragazzo che farà il
programmatore... |
