Newsgroup: it.comp.java
Titolo: Meccanismo di asserzione.


Grazie
Vincenzo Stefanazzi.

Ciao,

----------------------------------------------
Chiedo scusa per il nome nel precedente post.

 Programmer", cito testualmente
Non saprei cosa dice sul libro in questione, ma in generale, le asserzioni 
sono - appunto :-) - clausole logiche che precedono o seguono statement 
(pre- o post- condizioni) o valgono all'interno di un ciclo (invarianti).
Una volta valutate rispetto allo stato del programma, devono risultare 
*vere* in certe condizioni (tipicamente, una precondizione deve valere 
"true" prima che lo statement a cui precede sia eseguito; una post- 
viceversa; un'invariante, appunto, in ogni iterazione, prima e dopo ogni 
istruzione del ciclo che lo contiene.
Ora, un certo linguaggio di programmazione puo' o meno mettere a 
disposizione un meccanismo sintattico per scrivere queste clausole logiche; 
e un meccanismo runtime di valutazione che permette di calcolarne il valore 
ed interrompe il flusso regolare di controllo nel caso un'asserzione 
fallisca (cioe', risulti falsa quando dovrebbe esser vera). Spesso inoltre 
questo meccanismo puo' essere disabilitato in condizioni di "produzioni" 
per minimizzare l'impatto sulle prestazioni.
Siccome le asserzioni sono affermazioni sullo stato del programma 
relativamente indipendenti dal particolare codice in questione, sono molto 
utili per individuare automaticamente bugs o, appunto, situazioni di 
eccezione - o viceversa per definire la correttezza di un pezzo di codice.
Il lato negativo consiste nella loro stessa natura: sono espressioni 
_logiche_ - e il programmatore tipo non ha tutta 'sta confidenza con il 
calcolo del prim'ordine da considerarne la scrittura facilissima. Inoltre 
alcune possono essere piuttosto difficili da "ideare" (o individuare) - 
tipicamente invarianti di ciclo. Questo, e il fatto stesso che e' il 
programmatore a doverle esplicitamente scrivere ne ha limitato storicamente 
l'uso.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 l'uso.
Che a sua volta è causa del fatto che sia opinione diffusa che il lavoro di
programmazione sia operatività di manovalanza (per non generalizzare, e dire
che moltissimi profili tecnici sono sottovalutati). Gli addetti ai lavori,
avendo queste opinioni, le hanno anche tradotte in fatti rispondendo alle
esigenze di mercato con la quantità anziché la qualità.

 la quantità anziché la qualità. 
In effetti (e credimi, sono anni che ponzo sul problema e su possibili 
soluzioni) il punto e' che il lavoro di programmazione e' quasi sempre 
valutato sui risultati immediati o a breve termine. 
Che di per se' e' ragionevolissimo, e necessario. Un programmatore deve 
essere in grado di risolvere un problema in tempi brevi e a costi bassi. 
Altrimenti e' - commercialmente - inutile. 
E le persone che in genere ricevono rispetto e 'avanzano' sono quelle che 
soddisfano questo criterio. 
Il punto e', *solo* questo criterio.
Le altre caratteristiche di quanto viene prodotto da un programmatore 
(leggibilita', mantenibilita', grado di riuso, eccetera) non sono in genere 
affatto valutate. 
Caratteristiche "di sistema" :-), quali ad esempio l'attitudine alla 
collaborazione, alla condivsione di competenza e risorse (che non sono 
astratte: si traducono in azioni concrete come domandare se qualcosa esiste 
gia' per fare un certo lavoro; aver cura di coordinare il proprio lavoro 
con il manager/gli altri; comunicare la disponibilita' di nuovi 
componenti/funzionalita'; ricordarsi di riversare i fottuti files nel 
sistema di version control almeno una volta al giorno, eccetera :-) sono 
anch'esse in genere poco considerate.
Il risultato e' che queste caratteristiche non sono particolarmente 
rilevanti per il posizionamento e la carriera di una persona.. e di 
conseguenza in media non particolarmente considerate quando si tratta di 
decidere avanzamento e posizionamento di altre persone. E' una spirale 
negativa. 
(Tra parentesi, questo e' uno dei motivi per cui sono istintivamente 
contrario alle varie "certificazioni" in giro.. contribuiscono a far 
ingorare ancora di piu' quello che - se non il "vero" problema - e' almeno 
una buona meta' del problema della produzione di software; a rafforzare 
l'idea che saper codificare una soluzione locale e a breve termine 
equivalga ad essere un buon programmatore/progettista/chiamalocomevuoi).
Ora, tutto questo non succede per incapacita' o cattive intenzioni: a 
parole, qualunque manager ti dira' - e _sinceramente_ - che queste 
caratteristiche sono importanti ed apprezzabili. Il problema e' che _non_ 
sono facilmente valutabili e riconoscibili da chi non le ha - mentre il 
criterio dei risultati *oggi* e' semplicissimo da usare.
Ed ecco quindi che spesso finiscono in posizioni 'di potere' (o 
'inamovibili') tipi di 'guru' che sono tali solo in ambito di efficienza di 
produzione a breve termine, e i cattivi risultati a medio/lungo termini 
sono accettati come "inevitabili", e mai e poi mai attribuiti al lavoro di 
queste persone; manca nel management il collegamento mentale per 
quest'attribuzione di responsabilita'.
