Newsgroup: it.lavoro.informatica
Titolo: Oggetti o non oggetti?

cosa è meglio?
 
a me sembra che
un programma non ad oggetti chiunque riesca a metteci le mani
vieversa se non è piu che documentato partono le settimane e poi forse 
si fa anche casino
 
o no? voi cosa dite ?


dipende, lavorando sia in modo procedurale che ad oggetti, non noto 
grosse differenze
 
se procedurale hai tutto il corpo in uno o più file ma leggibili, con 
dentro TUTTO anche quello che in quel momento non ti serve per 
manutenere il programma, comunque te lo devi leggere/scorrere.
 
Viceversa ad oggetti hai il programma sparso e con molti "richiami" 
leggere "l'insieme" è praticamente da incubo (aprire nmila file, fare 
avanti e indietro tra le funzioni richiamte, ecc) ma hai un "isolamento" 
nel momento in cui sai dove devi mettere le mani che ti limita i danni 
che puoi fare.
 
Ciao

> o no? voi cosa dite ?
 
al contrario, ma dipende da come sono scritti gli oggetti. Devono
essere ben incapsulati e devono essere scelti bene. E se mi passi il
termine devono essere "grossi". Ovvero, nel gestionale e non solo, gli
oggetti devono essere grossi e contenere del codice che fa qualcosa.
 
Creare galassie di micro oggettini con poche righe di codice per
metodo polverizza troppo la logica e serve del tempo per capirla.
 
Comunque, il codice si può scrivere per farlo capire o per se stessi.
Indipendentemente dalla tecnica se scrivi per te e per far vedere
quanto sei bravo te e soddisfare il tuo ego, quel codice non lo capirà
nessuno.
 


dico che mi spiace ma non mi risulta nessuna regola del genere.
 
ps: la prima domanda faccio finta di non averla letta.

 ben incapsulati e devono essere scelti bene.
 
occhio, c'è un tale che ti ha rubato l'identità e ha aperto un thread 
apposta per dire l'esatto contrario...
 

 apposta per dire l'esatto contrario...
 
??? Che ho mai detto che è meglio il procedurale ? Al massimo ho detto
che per alcune funzioni nel gestionale è più chiaro il codice
procedurale.


Che hai bisogno di studiare l'Object-Oriented Programming prima di
poterne giudicare le applicazioni. Ti consiglio Smalltalk (http://
www.squeak.org/Smalltalk/
) e questo libro 
http://www.squeakbyexample.org/
 
.


veramente tu hai più volte detto, anzi scusa l'altro ha detto, che questi 
sono sofismi estetici da sacrificare all'altare del basso costo.
 
 
 

 sono sofismi estetici da sacrificare all'altare del basso costo.
 
Dipende sempre dal contesto.
 
Se tu mi dici come è più chiaro il codice a oggetti o meno ?
 
- Risposta a oggetti
 
in generale è così.
 
Poi mi chiedi, come è più chiara una procedura che fa l'inventario di
magazzino ?
 
- Procedurale, senza alcun dubbio ( niente oggetto movimento per
intendersi)
 
mi sembrava di essere stato chiaro in quel 3d, citando espressamente
il contesto a cui mi riferivo.
 

 Dipende sempre dal contesto.
 
com'è che ho la sensazione tu stia menando il can per l'aia?
 
mi riferivo alla tua affermazione (riferita agli oggetti) "Devono essere 
ben incapsulati e devono essere scelti bene" quando tu hai basato tutta 
una discussione sul fatto che questi sono formalismi inutili nonché 
costosi e che il software si scrive un tanto al chilo...


 se procedurale hai tutto il corpo in uno o più file ma leggibili, con
 
Ma di che parli?? Forse dei programmi Cobol di qualche anno (decennio)
fa :-)
Lì effettivamente era come dici. Ma già se usi un linguaggio poco poco
più evoluto, tipo C o Pascal, puoi usare a piacimento librerie esterne
di cui non hai certo il sorgente.
 
PS: teoricamente si può e si poteva fare anche in Cobol, ma con molta
difficoltà data la macchinosità delle call e la scarsezza di librerie
disponibili
 
 


considerando che provengo dal cobol e l'altro procedurale è pl/sql, mi 
basavo sulle mie conoscenze.
 
Ciao

 costosi e che il software si scrive un tanto al chilo...
 
ma ti riferisci a quella sul risultato di un progetto ? Quella di
questi giorni ?


a equino'... facciamo che t'aspetto qui, quando ti decidi a tornare sulla 
terra se ne riparla.
 
 

 manutenere il programma, comunque te lo devi leggere/scorrere.
 
Ma stai SCHERZANDO???
 
Che io ho sotto manutenzione programmi con qualche decina di files di codice sorgente ciascuno, che ogni volta che tocchi da qualche parte devi diventare scemo a capire dove la tua modifica impatta??
 
Mi sa che devi studiarti bene bene cosa significa 'incapsulamento'...
 
Poi e' ovvio che per 10 righe di codice solo un maniaco si mette a scrivere oggetti.
 
-- 
Ciao!
Luca


Un programma deve essere ben documentato. Punto.
Detto questo, negli oggetti metti le mani meglio, che riesci a farti un'idea anche NON leggendo tutto il codice. Ovvio che si possono fare mostri anche a oggetti, ma pure con il procedurale non si scherza!
 
-- 
Ciao!
Luca
 

 Un programma deve essere ben documentato. Punto.
 
facciamo punto e virgola.
la documentazione conta per una frazione sulla manutenibilità e a mio
modesto avviso anche piccola. la documentazione ha il grosso difetto
di inseguire lo sviluppo e di conseguenza essere sistematicamente
obsoleta. non dico che non sia indispensabile, anzi, ma io spiego
sempre che bisogna stare attenti a cosa si documenta e in particolare
il codice deve spiegarsi da solo.

 Che io ho sotto manutenzione programmi con qualche decina di files di codice sorgente ciascuno, che ogni volta che tocchi da qualche parte devi diventare scemo a capire dove la tua modifica impatta??
 
quando ci sono delle freak-funzioni-procedure meglio modificare o 
all'inizio a o alla fine se non si può r.i.p.! :D
 
 

 scemo a capire dove la tua modifica impatta??
Tipico problema di mancanza di incapsulamento dove i linguaggi ad 
oggetti ti danno un supporto nativo. L'incapsulamento pero' lo puoi 
anche implementare con i procedurali anceh se chiaramente e' piu' faticoso.

 il codice deve spiegarsi da solo.
 
In linea di massima sono d'accordo su questo
Per esperienza mia i progetti più rognosi da rimaneggiare sono quelli 
che non hanno un codice chiaro/commentato
La documentazione spesso dà un errato senso di sicurezza, purtroppo
 
M
 
-- 
I fatti mi cosano


Perfetto. Tre punti che mi piace/mi trovo spesso a stressare sono:
 
codice pulito e chiaro
tests
programmazione il più possibile dichiarativa
 
I primi due sono (uno ci spera sempre) autoesplicativi un pò per
tutti. Il terzo, necessita sempre di qualche nota (vuoi perchè non la
si è mai affrontata, vuoi perchè la si dimentica a seguito del poco
supporto nei linguaggi che si usano) ma è sempre stato (e sta
diventando sempre più) importante e utile.

 programmazione il più possibile dichiarativa
 
io vorrei sottolineare anche l'importanza dei test visto che li hai
nominati.
ci sono pochi metodi efficaci per "obbligare" il programmatore (che
può essere anche se stesso, sia chiaro) a scrivere codice pulito e
chiaro, fra questi ci sono gli unit test accoppiati ad uno strumento
che verifichi la copertura del codice.
scrivere codice "testabile" vuol dire scrivere codice senza inutili
complessità bandendo le ramificazioni. provare per credere. il che
migliora notevolmente anche la comprensione di un umano, perché
oggettivamente il grosso problema quando si mette mano a un codice al
di la di leggersi tutti i commenti è capire che cazz...arola di
percorsi compie.

 La documentazione spesso dà un errato senso di sicurezza
 
Io penso che sia uno strumento, come gli altri.
Peraltro, mi tocca confessare che spesso io in prima persona ho usato gli argomenti finora portati (a cui manca il migliore, 'tanto non la legge nessuno') per NON fare la documentazione. Non sono il solo, per quel che mi risulta.
 
-- 
Ciao!
Luca

 Peraltro, mi tocca confessare che spesso io in prima persona ho usato gli argomenti finora portati (a cui manca il migliore, 'tanto non la legge nessuno') per NON fare la documentazione. Non sono il solo, per quel che mi risulta.
 
Documentare non piace quasi a nessuno. Per fortuna con i tests lo si
può fare in modo più pro-attivo, divertente e proficuo.

 si fa anche casino
 
se vuoi far partire una discussione sull' opportunita' di usare un
linguaggio ad oggetti per favorire comprensione, manutenzione,
riusabilita' ed estendibilita' del software mi sembra doveroso farti
notare che sei in ritardo solo di una ventina di anni... :)

 Peraltro, mi tocca confessare che spesso io in prima persona ho usato gli argomenti finora portati (a cui manca il migliore, 'tanto non la legge nessuno') per NON fare la documentazione. Non sono il solo, per quel che mi risulta.
 
ribadisco il mio concetto, scrivere documentazione va benissimo e può
essere utilissimo in tanti aspetti del progetto ma non per migliorare
la manutenibilità del codice.
 

 per la comprensione del codice vuol dire che c'è qualcosa che non va.
 
If you’re about to add a comment, ask yourself, “How can I improve the
code so that this comment isn’t needed?" - Steve McConnell

 i commenti 
 
Ecco, come sospettavo questa è la confusione. Per me commenti != documentazione.
Oddio, avere una descrizione sommaria di una classe o di un metodo può pure aiutare, però a) il nome della classe dovrebe dire ciò che la classe fa, cosi' come il nome del metodo e b) il codice di ogni singolo metodo non dovrebbe mai essere talmente lungo da rendere il metodo stesso illeggibile.
 
Quando parlo di documentazione parlo soprattutto del progetto di massima e dei flussi di lavoro. OK, ho scritto una classe, ci ho scritto pure i test, ma se non dico _perche'_ la classe esiste nell'ottica generale del progetto IMHO manco un servizio che va fornito a chi, un domani, potrebbe dover mettere le mani al progetto scritto da me.E se gli levo il peso della ricerca delle motivazioni per cui le cose esistono in un certo modo, IMHO gli facilito il lavoro.
 
-- 
Ciao!
Luca
 

 o no? voi cosa dite ?
 
Dopo diversi giorni, è un peccato nessuno abbia risposto:
"Ma cosa intendi per *non oggetti*?"
oppure
"Entrambi, dipende"
o ancora
"Tutto quello che di meglio ho a disposizione"
 
o comunque sollevato argomenti simili.

 Che io ho sotto manutenzione programmi con qualche decina di files di codice sorgente ciascuno, che ogni volta che tocchi da qualche parte devi diventare scemo a capire dove la tua modifica impatta??
 
Nella stragrande maggioranza dei casi, questo accade perchè sono
scritti davvero male. Programmi fortemente state-oriented che non
spingono la statefulness verso livelli più alti, side-effects come se
piovesse, il non saper organizzare e usare quel poco di higher order
che magari si ha a disposizione nel dato linguaggio... etc.
 
Molti problemi hanno una soluzione naturale o accettabilissima nel
paradigma imperativo/procedurale, sono i programmatori che rendono
tali soluzioni ingestibili.

 Quando parlo di documentazione parlo soprattutto del progetto di massima e dei flussi di lavoro. OK, ho scritto una classe, ci ho scritto pure i test, ma se non dico _perche'_ la classe esiste nell'ottica generale del progetto IMHO manco un servizio che va fornito a chi, un domani, potrebbe dover mettere le mani al progetto scritto da me.E se gli levo il peso della ricerca delle motivazioni per cui le cose esistono in un certo modo, IMHO gli facilito il lavoro.
 
L'hai scritta tu stesso la soluzione nel paragrafo precedente: già il
naming giusto aiuta molto la comprensione. Con i nomi giusti, anche un
call graph di un doxygen diventa un aiuto non da poco in certe
circostanze. Scrivere della buona doc è sempre l'ideale, soprattutto
quando il dominio applicativo è complesso (o ahimè sconosciuto) o
l'unica soluzione trovata è per forza di cose arzigogolata (ad es.:
una serie di hacks necessari), ma i tests vengono prima
necessariamente.
 
Sono i tests la tua "safety net" nel tempo, non la pur buona
documentazione. E questo è tanto più vero quanto più ampio è (diventa)
il software.

 Quando parlo di documentazione parlo soprattutto del progetto di massima e dei flussi di lavoro. OK, ho scritto una classe, ci ho scritto pure i test, ma se non dico _perche'_ la classe esiste nell'ottica generale del progetto IMHO manco un servizio che va fornito a chi, un domani, potrebbe dover mettere le mani al progetto scritto da me.E se gli levo il peso della ricerca delle motivazioni per cui le cose esistono in un certo modo, IMHO gli facilito il lavoro.
 
ok ma a questo punto mi piacerebbe vedere un esempio di documentazione
a cui ti riferisci, perché in una analisi generale di dominio non si
va (di solito) a scrivere delle classi e laddove lo fai devi tenere
conto che nel corso dello sviluppo le classi cambiano nome, cambiano
struttura, spariscono, poi ad un certo punto ci ripensi e ritornano...
e la documentazione che fa, gli va dietro? e quanto ti costa? :)
l'unica cosa su cui posso concordare è sulla documentazione tipo
javadoc cioè generata direttamente dai sorgenti, ma è un tipo di
documentazione che è utile per gli utilizzatori non per i manutentori.




 o comunque sollevato argomenti simili.
 
perché pur senza nessun intento offensivo per chi l'ha posta la domanda è 
stupida e fra rispondere "dipende" o tacere la differenza è 
sostanzialmente nulla.
poi se come è successo si entra nel vivo di un argomento allora diventa 
anche piacevole intervenire...
 

 anche piacevole intervenire...
 
Ma si, sono io che ho riletto il thread con il senno di poi.

 per la comprensione del codice vuol dire che c'è qualcosa che non va.
 
hai dimenticato un "sempre". Se il codice ha continuamente bisogno di
essere pesantemente commentato probabilmente e' stato scritto in
maniera astrusa, ma non e' sempre cosi'. Ci possono essere
tranquillamente casi in cui un commento e' "necessario" per la
comprensione del codice, altri in cui e' molto utile, altri in cui
semplicemente facilita e velocizza la comprensione del codice..
 
(in realta' questa filippica un po' la capisco.. credo sia dovuta da
un lato all' amore talebano per i test del "javista di lungo corso",
"i test, tutti i test, nient' altro che i test" , e dall' altro alla
semplice mancanza di familiarita' con lo unit testing,per non parlare
del tdd..  :)

 tali soluzioni ingestibili.
 
quoto, questo è sicuramente e' la prima causa.
 
tuttavia in molte pmi italiane ci sono altri fattori che indurrebero 
anche un buon sviluppatore a produrre liquame:
 
1. esigenze cliente totalmente folli
2. esigenze commerciali totalmente folli
3. assenza di analisi
4. codice scritto al volo e non e' extreme programming lol
5. tempi di consegna totalmente sballati
6. stipendio da fame con conseguente demotivazione
 
-- 
http://www.evilripper.net
 
http://www.flickr.com/photos/evilripper/
 

 6. stipendio da fame con conseguente demotivazione
 
La situazione la conosco bene purtroppo. Nota però che diversi dei
punti che citi sono tutt'altro che assenti in giro per il mondo,
esigenze e consegne folli in testa. Quello che cambia sono legalità,
responsabilità personale maggiormente sentita, valore della parola
data, lo scaricabarile visto come deprecabile e non come un'arte in
cui essere maestri... Il solito insomma.

 del tdd..  :)
 
E perchè proprio Java? Nel mio caso, di testing/unit tests/TDD/altro
ho imparato leggendo dei tanti "test drivers" su comp.lang.c, facendo
bottom-up e design-by-contract in Scheme e linguaggi funzionali e così
via.
 
Java invece mi ha insegnato due cose:
- che mi piace la JVM
- che voglio programmarla in un altro linguaggio[*]
 
 
[*] Clojure, la 1.4 è stata appena rilasciata, è imho il miglior Lisp
in circolazione e inizia ad essere impiegato sul serio con relative
offerte di lavoro al seguito. 
http://clojure.org/rationale
 per info

 
 
7. specifiche che cambiano all'ultimo momento (mi e' capitato di scrivere palate di codice il giorno prima della consegna)
 
 
 

 7. specifiche che cambiano all'ultimo momento (mi e' capitato di scrivere palate di codice il giorno prima della consegna)
 
purtroppo ho paura che non sei il solo! :-D
chi non ha fatto tardi per un rilascio promesso scagli la prima riga di 
codice. Poi ovviamente roba super collaudata, testata e marchiata come 
stabile. puah! -.-

 dobbiamo parlare dei tests.
 
Faccio notare che in senso lato anche i test sono 'documentazione', dato che il test, oltre a essere una verifica di bontà, costituisce di per se un esempio di come impiegare cio' che si testa.
 
Aggiungo che il mio grido di dolore deriva dal fatto che mi capita (e mi capitera' ancora tra breve) di avere a che fare con applicazioni sconfinate scritte in VB6 da terze parti, scritte in modo casuale - 'aborro l'uso delle class, e non ho la minima idea di cosa sia almeno la programmazione strutturata - , con testing carente per essere buoni e con documentazione assente. Che poi non voglio fare il santo, porcherie ne ho scritte e probabilmente ne scriverò in futuro (a volte la velocità è tutto, ahime').
 
Termino facendo chiarezza nella confusione 'commento' vs. 'documentazione'. Ho detto - ed e' l'unica volta che ho tirato fuori i commenti - : commentare e' una forma d'arte. Mentre continuo a pensare fondamentale la documentazione di un progetto, penso che solo a volte i commenti al codice raggiungano la dignità di documentazione. E visto che ci sono, la mia strategia è la seguente: i commenti, se ci sono, solo a intestazione classe / funzione, solo se servono e solo se può capitare che l'impiego dei parametri o il valore di ritorno possano ingenerare confusione. 
 
E non ho altro da dire sui commenti! ;-)
 
-- 
Ciao!
Luca
 

 Termino facendo chiarezza nella confusione 'commento' vs. 'documentazione'. Ho detto - ed e' l'unica volta che ho tirato fuori i commenti - : commentare e' una forma d'arte. Mentre continuo a pensare fondamentale la documentazione di un progetto, penso che solo a volte i commenti al codice raggiungano la dignità di documentazione. E visto che ci sono, la mia strategia è la seguente: i commenti, se ci sono, solo a intestazione classe / funzione, solo se servono e solo se può capitare che l'impiego dei parametri o il valore di ritorno possano ingenerare confusione.
 
Programmare come scolpire: eliminare il superfluo per far uscire fuori
l'opera. Mi è sempre piaciuto l'accostamento.

 del tdd..  :)
 
oh riccardino audano da badoo, ma cosa vuoi che ti risponda? non ti
sputo che ti profumo, non ti piscio che ti lavo, non ti caco che ti
inciprio (cit.).
 
 

 practices?
 
Nessuno vuole farlo e anzi, ho pensato che una domanda che effettivamente nasceva con un po' di vis polemica - ebbene si, lo confesso! - è retrospettivamente un'ottima domanda!
 
Ora, supponiamo di avere un'applicazione che NON prevede test; secondo te e non solo, qual è la 'best practice per rientrare nelle best practices'? ;-)
 
Premetto che io non ho opinioni in materia, dal momento che non ho mai provato!
 
-- 
Ciao!
Luca

 practices'? ;-)
 
beh non sta scritto da nessuna parte che un software su cui non sono 
stati mai implementati i test sia condannato a continuare in eterno su 
questa falsariga; se c'è volontà (e sottolineo se c'è volontà) questa 
come altre buone abitudini si possono introdurre senza necessariamente 
sanare il pregresso che è un po' la preoccupazione che si legge fra le 
righe. 
 
in secondo luogo come spesso ne ho parlato con i miei colleghi quella di 
implementare i test può essere anche una buona abitudine personale. 
comunque quando si fa una modifica occorre provarla almeno una volta in 
esecuzione e scrivere uno unit test è una alternativa migliore alla black 
box.

 Non sono il solo, per quel che mi risulta.
 
fidati, sei in ottima e abbondante compagnia :-)
 
Andrea 
 
 

 inciprio (cit.).
 
Colto nel segno eh? :) Ma perche' te la prendi ? E rilassati dai,
cos'e', ti sei fatto di nuovo prendere la mano con l iPad? vabbe' che
al cuor e alla passione non si comanda..ma lo sai che "ti irrita"..
almeno usa una cremina...
"Javista di lungo corso non e' mica un insulto o un segno di
disprezzo.. anzi! E ogni javista di lungo corso con un minimo di senso
di autocritica sa di essere un po' in fissa con design patterns, best
practices e test ..tutto li'..

 male la documentazione tanto poi nessuno la legge ? :-)
 
in realtà non è vero che la documentazione non la legge nessuno, se è
utile viene letta eccome. per dire, il manuale utente viene letto, ma
anche le specifiche di progetto o le api references.
il problema è quando la documentazione *non* è utile. è la
documentazione è inutile sostanzialmente in due casi:
 
- quando è obsoleta
- quando è ridondante
 
andando a documentare il codice (è di questo che si parlava) 90 su 100
cadi in una di queste due casistiche quando non in entrambe.
la ridondanza perché il codice è scritto ovviamente in un *linguaggio*
e andando a descrivere "cosa fa" finisci nella migliore delle ipotesi
col duplicare una informazione, dico nella migliore delle ipotesi
perché il linguaggio di programmazione è già (ovviamente) più adatto a
descrivere cosa fa un programma rispetto al linguaggio parlato.
l'obsolescenza perché il semplice fatto che ti stai ponendo il
problema di modificarlo sta a dimostrare che il codice è dinamico, e
la documentazione per quanto possa essere curata tende
*inesorabilmente* a disallinearsi.
 
 
 
 
 

 offerte di lavoro al seguito.
http://clojure.org/rationaleper
 info
 
eh e' una delle tante, troppe cose nella mia lista dei "TODO" :)

 eh e' una delle tante, troppe cose nella mia lista dei "TODO" :)
 
I linguaggi come Clojure sono (chi più, chi meno) parte del presente e
saranno tra i protagonisti del futuro più immediato per molti. "The
free lunch is over" da un bel pò, ed è sempre bello essere su un treno
che punta al futuro.
 
[*] con un certo numero di eccezioni, certo, ma ininfluenti visto
com'è andata.

 Colto nel segno eh? :)
 
caro riccardo audano da badoo, lo sai benissimo che la tua totale
incapacità di sostenere un dibattito nel merito coglie sempre nel
segno. d'altronde che altro può fare un coglione se non cogliere :p
conosci un solo metodo per sentirti all'altezza degli altri,
trascinare le discussioni alla tua bassezza. ovvio che chiunque non ti
ignora (cosa che succede la stra-stra-grande maggioranza delle volte)
finisce per cadere in basso.
il questo messaggio hai voluto quotare tutti i miei interventi: bravo,
ottimo lavoro, ma se tu fossi stato una persona mediamente
intelligente avresti concluso che, anche se non eri d'accordo, c'era
assai di che dibattere. invece, al solito, la tua prima cartuccia
l'hai sparata con la consueta quanto ingiustificata entrata a gamba
tesa, la seconda quando hai cominciato a minimizzare la discussione
(ma di che stiamo parlando? ma che c'è da discutere?) e infine la
terza e ultima cartuccia quando ti sei messo a fare la noiosa
disquisizione sui termini. questo signori è riccardo audano da
badoo(*) e chi ancora non lo conosce non ci provi nemmeno perché tanto
altre cartucce non ne ha.
 
(*) a chi si chiede il perché faccia una ricerca a ritroso su questo
gruppo, in particolare quando pur sgamato a frequentare un social in
adescamento squinzie si è messo a sparare a zero riguardo twitter,
sempre per il solito spirito "spirito" di serena discussione.

 che punta al futuro.
 
"the free lunch" non e' mai esistito, ma se parli di evoluzione
intellettuale ,elasticita' mentale e poliedricita' con me sfondi una
porta aperta.. nei limiti del possibile per me sono tra le doti piu'
belle e necessarie per una persona ..e per un programmatore ancora di
piu' che nel caso generale...

 piu' che nel caso generale...
 
Sei in diaccordo con me, Herb Sutter e un bel pò di altre persone al
mondo. Il free lunch[*] è esistito eccome, ed è durato anche troppo
non solo in riferimento alla nuova era della concorrenza in cui
operiamo.
 
[*] 
http://www.gotw.ca/publications/concurrency-ddj.htm
 

 Sei in diaccordo
 
era disaccordo ovviamente

 stitikit? Se è un framework o similare non lo conosco.
 
sarei io. mette nomignoli a chi non gli va a genio. sai com'è lo trova 
divertente, il burlone.
 
 

Avverto che non sei sereno, e mi dispiace.
 
che bella ! Letta e rubata.
 

 sarei io.
 
Ovviamente non mi era sfuggito, visto che lo ripete un post si e
l'altro pure... ma non potevo dargli soddisfazione :)


E' terribile quel riccardo quando ci si mette, un pò mi ricorda quel
pazzo che girava qui anni fa, Luc. In un certo senso, Usenet è Usenet
anche grazie a tipi come loro ;)

 anche grazie a tipi come loro ;)
 
ecco, a proposito... Luc lo avete rotto. Vediamo di non esagerare che
rompete pure questo però.


Mi ero perso il messaggio. Un modo di attaccare il problema è il
seguente.
Ti fidi di quello che il codice già fa, assumendo che sia corretto.
Individui le parti in cui dovrai fare le modifiche e scrivi dei tests
fino a che non sei convinto di aver capito come funzioni il codice.
Esempio stupido in pratica (per l'occasione in Python, leggibile anche
da chi non lo conosce), mettiamo il caso che mentre seguo il flusso
del codice nei moduli trovo una function che manipola certi dati che
sembrano interessarmi:
 
def process(L):
  return [] == [False for i in range(len(L)) if L[i] != L[len(L)-i-1]]
 
Noto che L è una stringa passata dai callers, non sono sicuro di
quello che accade all'interno, l'interfaccia e i nomi scelti non mi
aiutano ma so che le mie modifiche avverranno in un certo intorno
piuttosto prossimo. Ho trovato un punto d'interesse dove inserire un
test. Siccome il dover lavorare a questo sistema legacy mi sta
deprimendo, la prima cosa da fare è cazzeggiare inventandosi in 10
secondi un incredibilmente inutile mini-sistema di test driving adatto
a questo post, che puntualmente verrà fuori sbagliato (siamo
programmatori o no?!):
 
def check(f, p, e):
  try:
    r = f(p)
      assert r == e
    except AssertionError:
      print '***Failed: %s.%s  Got: |%s|  Expected: |%s|\n' % \
          (f.__module__, f.__name__, r, e)
 
Con il nuovo giocattolino pronto e tornando seri, ecco cosa fare.
Scrivo un paio di tests che sono sicuro falliranno (come lo so? li
vedrò fallire fra un attimo, ovvio):
 
def test_process():
  check(process, "a string", "WILL_FAIL")
test_process()
 
Li eseguo e falliscono:
 
***Failed: __main__.pal3  Got: |False|  Expected: |WILL_FAIL|
 
Ah, ora so che l'input "a string" produce False, bene. Osservo ancora
il codice, continuo a non capirci molto ma ne aggiungo un altro
comunque:
 
  check(process, "madam", "WILL_FAIL")
 
***Failed: __main__.pal3  Got: |True|  Expected: |WILL_FAIL|
 
True. Con i tests in posizione, passo ad altre functions/moduli/
sottosistemi/classi/quello_che_è e aggiungo tests osservando il
comportamento del sistema e imparando qualcosa di nuovo ad ogni test
(si spera...). Ad un certo punto, deciderò che con i tests può bastare
e inizierò a fare le modifiche. Ora ci sono ottime possibilità che i
tests mi avvertano se rompo qualcosa mentre modifico in giro in
codice, quantomeno è sicuramente meglio di farle al buio e senza
alcuna copertura. Oltretutto con l'output dei tests posso scoprire più
velocemente il funzionamento del sistema, ad esempio posso tornare per
necessità su process() e accorgermi con altri tests che "12321" e
"NaN" passano i tests e... trovato, process() non fa altro che
ritornare True se una stringa è palindroma ("ma chi l'ha scritta sta
roba contorta, porc..."[*]). Mentre scopro come funziona ci lavoro e
sono coperto dai tests - a questo punto se ne vale la pena (o se è in
programma dall'inizio) posso pensare di fare refactoring dove e se
serve e process() diventa:
 
def is_palindrome(item):
  return item == item[::-1]
 
con "item" scelto in modo più significativo, che ora la fantasia
latita un attimo. E via così, aggiungo tests quando serve/ne sento la
necessità.
 
Questo approccio è di solito chiamato ***Characterization Tests***, ne
trovi una dettagliata descrizione (tra le tante altre cose trattate)
nel libro "Working effectively with legacy code" di Michael Feathers -
un gran libro davvero e che centra proprio la tua domanda in pieno.
 
Ci sono delle soluzioni, che l'autore identifica come *seams* nel
libro: è in questi punti/giunture che tocca infiltrarsi con i tests.
Il discorso è lunghissimo e più che altro varia da caso pratico a caso
pratico: puoi avere come target una function tipo l'esempio scemo,
puoi dover usare un object
(ma non tutti i metodi sono "seams"/punti di entrata praticabili),
puoi riuscire a sfruttare la fase pre-compilazione con preprocessore e
linker nel caso di C e C++...
Chiaramente, l'esempio scemo è giusto l'approccio iniziale nel caso
più fortunato, ovvero software con dipendenze umane e interfacce
decenti. Il problema maggiore è come penetrare efficacemente le
dipendenze quando queste sono da incubo, in modo che con i tests tu
possa arrivare a fare switch fra dipendenze_on e dipendenze_off come e
quando serve. Il punto è (banale a dirsi) tutto nel non alterare il
codice di produzione (come ho visto fare maldestramente a molti e poi
sono davvero cazzi amari) ma "estrarre" comunque degli agganci per
fare il testing, studiando le dipendenze statiche (di quelle
dinamiche, calls at runtime e soci non ce ne facciamo nulla) nel
codice.
 
E' un lavoraccio ma può essere fatto se è necessario (e se ne vale la
pena, ovviamente).

 ***Failed: __main__.pal3  Got: |False|  Expected: |WILL_FAIL|
 
Ho sbagliato nell'inventarmi la linea di ritorno dell'errore,
chiaramente doveva essere:
 
***Failed: __main__.process  Got: |False|  Expected: |WILL_FAIL|
 
I posts-post-bevuta-con-gli-amici andrebbero banditi... e pure le idee
che ne nascono :)


Tutto quello che ricordo è che ad un certo punto iniziò a tirarsi gli
schiaffoni da solo. Era inevitabile.

 se me lo chiedi.
 
evvabbe', e con questa abbiamo cominciato a sputare pure sui design
patterns e sui linguaggi e le comunita' che ne hanno incoraggiato e
diffuso la conoscenza e l' utilizzo..evvai!
Certo che se l'abilita' di un programmatore si giudicasse da quante
cose disprezza tu e il professorino malato sareste dei semidei :)

 sai com'è lo trova divertente, il burlone.
 
elloso' , e' che non riesco ad essere serio e professionale come te,
che ci posso fa'? :)

 la manutenibilità del codice.
 
questa poi e' una sciocchezza bella e buona: la documentazione puo'
benissimo aiutare , facilitare e velocizzare il lavoro di chi deve
mantenere ed estendere del codice che non ha scritto..

 cose disprezza tu e il professorino malato sareste dei semidei :)
 
Se non hai sufficiente esperienza in entrambi i campi (con i linguaggi
dove i dp sono necessare *e* con quelli dove non è esattamente così)
questo non è un mio problema.
 
Rileggi attentamente: "I design patterns servono a certi linguaggi per
colmare il gap espressivo verso quelli che non ne hanno bisogno". 16
dei 23 classics sono all'atto pratico inutili, o per meglio dire già
contenuti nelle forme idiomatiche del linguaggio stesso (meglio dei
linguaggi che ci arrivano in espressività), puoi partire da Peter
Norvig e dalle sue presentazioni sui dynamics per capirci qualcosa in
più ma senza una buona esperienza di paradigmi dichiarativi non sarà
facile. Ecco perchè parli di "sputarci sopra", perchè non sai quello
di cui stiamo parlando.
 
Uno a caso: prototype. E che me ne faccio se il mio linguaggio prevede
già l'immutability? Miracolo mancato, eh?
 
Più studio dei fatti e meno stravolgimenti delle frasi altrui, please.
"sputare su", puah...

 Caciotta e Il Professorino Malato..
 
Questo si che è un pattern. Se Fantacoso è Alessandro Riolo, il prof è
Nicholas e di rootkit oramai sappiamo (gli altri non ho individuato),
hai giusto storpiato tre dei nomi che leggo/ho letto in archivio con
più piacere fin'ora. La cosa si fa preoccupante :O
 
:)

 la prima domanda faccio finta di non averla letta.
 
Ma ,seriamente, cosa vuoi che ci sia discutere? C'e' bisogno di
mettersi a discutere sull' utilita' degli unit test e l'opportunita' e
i vantaggi del loro utilizzo??? O paragonarli , confrontarli o
contrapporli a commenti e documentazione che sono due altre tecniche
ovviamente utili e ovviamente con un ambito diverso?

 più piacere fin'ora. La cosa si fa preoccupante :O
 
ah ma anche io adoro leggere il Fantasmagoricoriolo...mitiche le
risate quando se usciva con "pensionati in albania" o "la mafia non
esiste e non influenza la politica, sono giusto quattro contadini" o
"il psi vince in sicilia perche' martelli era un bell 'uomo e
andreotti un cesso" o "se alcuni studenti siciliani fannno cacare a
scuola la colpa non e' loro o delle loro famiglie, ma dell'oppressore
italiano che li costringe a studiare in una lingua straniera" ... solo
per citarne alcune a caso.. come vedi non riesco a dimenticarle :)
Sono decisamente un fan!
Apprezzare il professorino malato, quello si' lo trovo un minimo
preoccupante..ma magari intendevi come puo' piacere un film horror :)
Il mio soprannome capolavoro pero' penso sia indiscutibilmente " Il
mOnagotto", il razzista leghista a sua insaputa, quello che trovava
"provocatori" i presepi con le statuine di colore ...