Newsgroup: it.lavoro.informatica
Titolo: insegnare l'autonomia

ciao a tutti.
scrivo qui dopo molto tempo, visto che il mio scenario lavorativo e' in
parte cambiato.
ora, in seguito ad un'esigenza ed alla mia curiosita', unita alla voglia
di confrontarmi, credo di avere un quesito che possa interessare molti.
io sono un informatico senior e da qualche giorno ho dei consulenti (di
seniority indefinita, cerchero' di avere i cv) ai quali passare la
maintenance di un software sviluppato da me ed altri, assai povero di
documentazione perche' e' stato sviluppato con metodologie agili. il
software e' assai semplice, data entry e reports.
vorrei poter insegnare ai consulenti l'autonomia gestionale e lavorativa,
la capacita' di orientarsi all'interno del codice per cercare la causa dei
problemi, inventarsi i workaround per gestire gli incidenti (si io ragiono
in ITIL eheheh). 
io non mi aspetto di spiegare ogni linea di codice, cerco di spiegare i
pattern (sia i design pattern del codice che i patter business) dietro
l'applicazione e spero che il team capisca e riesca a portarsi ad un
livello di astrazione per arrivare a capire anche il resto.
ma come esserne sicuro o come essere pro-attivo al fine di portarli a
questo livello?
come posso renderli self-confident e quindi autonomi con i problemi che
devono risolvere? come posso dare loro l'idea che e' bene essere
interattivi con me ed altri, che possono (devono!) chiedere quando hanno
dubbi o non hanno il bagaglio tecnico necessario per continuiare, anziche'
disperarsi nella loro solitudine? 
poiche' spero che tutti lavorino bene comincio a pormi questo tipo di
problemi prima che il lavoro stesso me li ponga, quindi se da una parte,
nel caso specifico, e' come se mi fasciassi la testa prima di essermela
rotta, dall'altra l'esperienza mi insegna che a questo giro potrei avere
questo tipo di problemi.
quindi che voi siate junior o senior, clienti o fornitori,  probabilmente
avrete una visione (da una parte o dall'altra) di questo scenario.
se avete voglia provate a darmi ilvostro contributo/consiglio/esperienza
p.s. (e' molto che non posto ma googolate, cosi' vedete che non e' spam,
troll etc)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


IMHO....
1) se costoro sono a te subordinati, se sei una specie di allenatore che 
tenta di creare una
squadra vincente, allora tutti i tuoi dubbi sono pertinenti..... Ti faccio 
gli auguri, perche' essere validi tecnici non significa essere anche bravi 
insegnanti....il tuo lavoro non sara' facile: dovrai motivare e condurre.
Il successo  ovviamente dipende anche dal materiale umano che ti e' stato 
messo a disposizione...:-)
2) se costoro sono invece tuoi potenziali concorrenti, destinati in futuro a 
subentrarti o sostituirti, probabilmente dopo una prima fase di reciproca 
conoscenza, cercheranno di sostituire o modificare buona parte del software, 
naturalmente riversando tutte le colpe e/o manchevolezze su chi li ha 
preceduti...:-)
In questa seconda ipotesi, i tuoi sforzi d'insegnante temo si scontreranno 
presto con una cattiva volonta' d'imparare da parte degli alunni, la quale 
presto si trasformera' in rivalità, poi ostilità ... etc etc...:-)
ciao
fm


Andare a monte e prendere solo consulenti "buoni" non è un modo per
risolvere diciamo il problema/preoccupazioni alla radice?
Perché i dubbi che hai descritto non mi sembrano un gran che adatti da
riportare verso un consulente... se fosse qualche junior in 
co.co.pro
allora posso capire, ma non per un consulente.
Tiro ad indovinare, te non hai nessuna parola per la scelta dei consulenti?
Ciao, Alessandro


 documentazione perche' e' stato sviluppato con metodologie agili. 
Può essere il momento buono di scrivere la documentazione.
Pensare di passare le conoscenze solo oralmente è semplicemente
grottesco.
Anzi, direi che consegnare ad un programmatore un software da
manutenere sostanzialmente privo di documentazione (e magari di
commenti) è il peggior modo di presentarsi e di costruire un buon
rapporto di lavoro.

 rapporto di lavoro.
E' proprio quello che è successo a me venendo a lavorare qui dove sono, e 
oltre tutto lavoro su tecnologie e linguaggi che non ho mai visto prima. 
Sigh. E' una situazione davvero difficile. Ma come si fa a scrivere migliaia 
e migliaia di righe di codice senza un solo commento? Boh!!! 

CUT
Ogni volta che leggo delle tue esperienze e' una tragedia dove fa
tutto schifo, sono tutti incompetenti, workaholic, servili o sfigati.
Come mai?
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 Ciao, Alessandro
:-) come ti dicevo non ho nemmeno visto i CV. lo scenario e' "peggio" di
quello che immagini dal punto di vista del controllo, ma ne parloero^piu'
tardi, volevo mantenere la discussione un po' piu' astratta per poi
passare al caso particolare.


 sviluppatori in un clima spesso di servilismo.  
L'autore del post scrive che il software è "assai povero di
documentazione perche' e' stato sviluppato con metodologie agili."
Quindi dobbiamo dedurre che nelle metodologie agili, oggi così
propagandate, non si documenta in modo completo il codice. Così poi se
bisogna passare il lavoro a qualcun altro c'è solo da farsi il segno
della croce... :-)

 rapporto di lavoro.
sono d'accordo, infatti sto scrivendo parte della documentazione mancante,
cosi' come gli ananlisti si stanno occupando di documentare gli algoritmi.
pero' la documentazione, come ogno altro tipo di comunicazione, e' tra due
soggetti: chi la scrive e chi la legge.
siccome devo redigerla e non so chi ho di fronte, mi pongo il problema di
come farlo. ad esempio se commenti una partita di calcio finita 0-0 con un
amico e lui ti domanda: "ed il gol del numero 9?" tu rispondi "era in
fuorigioco" ed il tuo amico capisce. prova a dirlo ad una donna...
ecco... se io faccio una doc con uml supercazzola prematurata, sono a
posto con la coscienza ma sono sicuro che tutti mi capiscano?


 della croce... :-)
io sono antrato nel progetto in fase avanzata e dopo un giorno ero in
grado di fare dei check-in e contribuire al progetto.
senza aver visto un'ombra di doc. 
http://it.wikipedia.org/wiki/Metodologia_agile
dipende molto dal progetto. in qualsiasi linguaggio tu lavori, se devi
fare del CRUD su dati usando come UI su una pagina web o in una finestra
di un'applicazione client, sapendo quali sono le tabelle, qual'e' il
codice (perche' c'e' una doc o perche' te lo hanno detto) e hai gia'
scritto del codice nella tua vita, allora dovresti venirne fuori.
secondo me ci va del buon sennso bilanciando cio' che e' necessario
attendersi, ovvero della doc (*) ed essere un po' svegli ed aver voglia di
sbattersi un po'.
(*) se sei un dev, quale doc consideri sufficiente per entrare agevolmente
in un progetto?


 finestra di un'applicazione client, sapendo quali sono le tabelle,
Se parliamo di software appena appena piů complesso, ovvero che non si
riduce al CRUD su una tabella, senza conoscere approfonditamente la
problematica (business logic, se vuoi) non vai proprio avanti.
Esempio: un calcolo stipendi.

 comunicazione, e' tra due soggetti: chi la scrive e chi la legge.
Io, oltre agli schemi formali, tipo UML, ER, ecc., ci metto sempre
poche pagine che spiegano a parole la logica di fondo, la problematica.
Per dire, per un programma che calcola lo stipendio di un consulente
co.pro
 scrivo 2 righe per riepilogare in breve come si fa questo
calcolo.
Dopodichè, massima disponibilità per chiarimenti a voce. Dopodichè, se
ancora non capiscono.... non sono buoni! :-)

 la capacita' di orientarsi all'interno del codice per cercare la causa dei
La domanda giusta è, se fossero in grado di essere autonomi, di
cercare i problemi e di risolverli nel modo corretto, se fossero
interattivi e disposti a chiedere, lavorerebbero a quel progetto in
quella posizione e con quello stipendio ?
Perchè se la risposta è si, allora basta dirglielo, se la risposta è
no imho insegnargli un metodo di lavoro è quasi impossibile,
sopratutto se hanno un po' di esperienza alle spalle.

 della croce... :-)
quando il codice è ben scritto e organizzato non ha bisogno di tanti 
commenti per essere comprensibile. se invece devi prescindere dai 
commenti per capire cosa fa il codice pur essendo un esperto della 
tecnologia, ecco, quello è il momento in cui ti devi fare il segno della 
croce.
-- 
? Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

 della croce.
Sono d'accordo se parliamo di un quantitativo moderato di codice. Ma se
parliamo di intere procedure, interi gruppi di programmi, la
comprensibilità del codice non è sufficiente. Infatti bisognerebbe
comunque leggersi migliaia e migliaia di righe, il che all'atto pratico
non è fattibile.
Pensa a dover fare una piccola modifica correttiva: è meglio avere un
minimo di documentazione riepilogativa, che ti dice quali
moduli/classi/programmi verificare, oppure è meglio doversi leggere
tutto il codice di tutti i programmi/classi?

 tutto il codice di tutti i programmi/classi?
se il progetto è ingegnerizzato in modo corretto non hai nessun bisogno 
di ricorrere alla documentazione per sapere in quale modulo intervenire. 
ovvero, ti basta una documentazione generica con gli standard di 
sviluppo per tutto il progetto e per tutti quelli a venire.
quando hai stabilito (ad esempio) come si scrivono i dao, i manager e i 
backing bean, se poi questi standard vengono rispettati il problema di 
rintracciare il codice da manutenere non esiste.
se poi lo vediamo dal punto di vista strettamente del codice, è noto che 
gli unit test documentano mille volte meglio delle parole.


 ancora non capiscono.... 
Io cerco di documentare fino ad un livello che mi sembra rendere il 
programma comprensibile.
Se mi chiedono chiarimenti glieli do e poi aggiorno la documentazione 
rivedendola o aggiungendo i chiarimenti dati a voce.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/06/relazioni-molti-molti-con-jpa.html

 il ; per indicare l'end of statement dove lo lasciamo? :-)
Perche non hai visto la riga successiva che contiene un ";" come primo 
carattere.


 Esempio: un calcolo stipendi.
scusa, ma imho stai facendo casino. come deve essere fatto il calcolo
degli stipendi è documentazione che fa parte dei requisiti, non è da
confondersi con la (eventuale) documentazione del codice. per dirla in
altri termini, si tratta di documentazione *destinata* alla
programmazione.
che il programmatore documenti come *lui* ha realizzato il calcolo è
assolutamente inutile: primo, perchè lo si evince dal codice; secondo,
perchè un eventuale manutentore deve partire partire dalla
documentazione su come il calcolo *deve* essere realizzato, non su
come è stato realizzato che nel debug è proprio ciò che viene messo in
discussione...  paradossalmente se questa documentazione fosse fatta
bene sarebbe anche sbagliata allo stesso modo del codice, quindi in
fase di debug bene che ti vada ti porta fuori strada...

 programmazione.
da quanto leggo mi pare che la documentazione sia la parte piu' importante
del processo di handover di un progetto.  lo condivido. 
scendo in dettaglio.
nel progetto ci saranno due handover, da analista ad analista (cambia la
persona che scrivee e decide i requisiti di business) e cambiano i dev che
ne fanno manutenzione e sviluppo futuro. la parte dev sara' data in
outsourcing e sara' data lontano...
ora, se da una parte e' vero che la doc e' importante, immaginiamo che ci
siano:
- use cases
- architettura
- diagramma del db
- classi e metodi commentati e raccolti ad esempio con sandCastle
diciamo 200 o 300 pagine di manualistica. 
arriva un baco da risolvere. che fa il dev che deve risolverlo? si legge
300 pagine di doc e comincia?
io ho scelto di fare coaching con delle lezioni live su piccoli pezzi di
codice, esercizi pratici e riconoscimento dei pattern usati, visto che di
documentazione ce ne sara' poca, ma di design patterns ce sono molti.
se ho due classi, anzi, allarghiamo il concetto non fermandoci al dev, se
ho due lavori uguali, che implementano il medesimo patter e solo nei
dettagli si differenziano, si deve necessariamente avere tutto documentato
per tutto o la capacita' di osservazione, la capacita' di analisi e
sintesi non devono essere date per scontate come la capacita' tecnica? la
curiosita' e la capacita' di capire come una cosa funziona, la capacita'
di proseguire in autonomia o aiutati e non fermarsi davanti ad una
difficolta', non e' un aspetto caratterizzante di un lavoratore? e come
potrei contribuire a formare questo aspetto?


 discussione...  
Qui non sono d'accordo. Se hai 100.000 righe di codice e devi risolvere
un bug, oppure devi aggiungere una funzionalità, non le leggi/vai in
debug su tutte e 100.000 . Cerchi di comprendere quello che fanno, e di
intervenire "chirurgicamente". Se hai davanti solo il codice non ci
riesci in tempi ragionevoli, non ci piove.
D'altra parte se questo programmatore (o progettista o chi è) non mi
documenta nemmeno le principali interazioni tra i
programmi/classi/moduli, bè, a mio parere fa un lavoro di bassa qualità.

 come potrei contribuire a formare questo aspetto?
Può essere, ma non sarebbe bello se si evitasse di scrivere un minimo
di documentazione (e la relativa fatica) puntando tutto sulla buona
volontà del nuovo programmatore od analista. Secondo me, è tutta
questione di misura e di equilibrio tra i due opposti.

 venire.  
Hmmm.... Quindi uno capisce dal nome se una certa classe/programma fa,
per esempio, il calcolo dell'Iva piuttosto che dell'Ici? Oppure legge
il nome di una tabella o di un campo e capisce cosa è, che valori può
assumere, quali vincoli incrociati esistono con altri campi/tabelle,
ecc. ecc.? Sì, a volte è possibile. Molte poche volte, nella mia
esperienza.....

 questione di misura e di equilibrio tra i due opposti.
si, ma siccome la doc in parte la si scrive prima, in parte durante, in
parte dopo, mi ponevo il problema di cosa dare in pasto ai subentranti in
base alla loro capacita' ed autonomia. ad esempio a me non e' servito
nulla e ho lavorato benissimo senza lamentarmi.


 subentranti in base alla loro capacita' ed autonomia. 
Appunto. Se non sai in anticipo cosa serve e non serve, devi preparare
un pň di tutto. Compresa la documentazione tradizionale, che mi sembra
di capire ti annoia parecchio :-)

Stefano M. Masullo segretario generale Assoconsulenza< 
associazione Italiana conslenti di Investimento segretario 
generale Assocredito Associazione Italiana Conslenti di Credito 
Bancario e3 Finanziario amministratore delegato Euro Sopa Spa 
vice presidente Sintesi Consult Spa vice presidente Ideal Conslt 
direttore editoriale Shirkah direttore responsabiile Rossia vice 
presidente Noi Liberisti azzrri direttore editoriale Finanza 
Arabe presidente Icos Technology rettore ISFOA Libera e Privata 
Università Internazionale Autorizzata dal Conssiglio di Stato e 
Repubblica del Canton Ticino con sede a Lugano atore di ben 20 
libri di cui uno adottato dall'Università Commerciale Luigi 
Bocconi di Milano quale testo obbligatorio di esame è il guru 
indiscuso della finanza italiana avendo previsto con largo 
anticipo ciò che sarebbe sccesso sui mercati finanziari 
internazionali guardate il suo pamphlet sul sito 
www.assoconslenza.com
 scritto nell'agosto e nel dicembre del 
1998 .
Guardate anche i suoi video dell'epoca 2001 - 2006 tratti dalle 
più importanti trasmissioni televisive di settore sia nazionali 
che internaziomnali. 
Io personalmente affidandomi ai soi consigli in questi ultimi 
anni ho raddoppiato il mio capitale investito.
http://www.assoconsulenza.eu/telenova2003.html
http://www.assoconsulenza.eu/money2002.html
http://www.assoconsulenza.eu/bloomberg102001.html
http://www.assoconsulenza.eu/cnbcsett2001.html
http://www.youtube.com/user/eugeniobenetazzo
http://it.youtube.com/watch?v=k6at-ZP8QgM&...feature=related
Siti di riferimento
www.eugeniobenetazzo.com
www.assoconsulenza.com
www.assocredito.org
www.sintesiconsult.com
www.eurosopa.it
www.shirkah-finance.com
www.rossiamagazine.it
www.arabfinco.com
www.idealmutua.it
-- 
Postato da Alice Newsgroup: lo usi da web ma con le funzioni del newsreader 
http://newsgroup.alice.it
Gerarchie it, italia, it-alt, tin, it.binari. Unico!

Stefano M. Masullo segretario generale Assoconsulenza< 
Impiccati.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 quale non e' piu' valida perche' in 24 mesi gli scenari aziendali cambiano.
Le metodologie agili non sono l'unica alternativa al processo a cascata.
Tutte le metodologie moderne (agili o meno) considerano un modello di 
sviluppo iterativo o evolutivo.
Poi il tipo di modello di sviluppo va scelto a seconda del tipo di 
progetto, non troverai mai un libro che consiglia di utilizzare il 
processo a cascata in un progetto dove la fase di analisi durerebbe 24 mesi.
Tra le metodologie di cui ho sentito parlare non mi risulta che ci sia 
una che afferma che non bisogna scrivere documentazione, ma piuttosto 
che dice di non scrivere, o passare troppo tempo a formalizzare, quella 
inutile.
Sembrerebbe che nel tuo caso un po' di documentazione far capire ai 
nuovi programmatori dove mettere le mani sia tra la documentazione utile.


> documentazione è sostanzialmente impossibile.
L'architettura generale di un software in genere è abbastanza stabile da 
poter tenere la sua documentazione aggiornata senza particolari sforzi.
La documentazione dell'architettura generale, se fatta bene, fornisce 
una mappa che permette allo sviluppatore di orientarsi nel codice e 
andare a trovare dove le modifiche devono essere fatte.
La documentazione dei dettagli invece, oltre a diventare obsoleta appena 
il codice cambia, è anche inutile perché non ti aiuta a capire come 
funziona un software piu' di quello che faccia già il codice.


 ecc. ecc.? 
su questo argomento, per me è una questione di lana caprina. in java 
faccio largo uso di orm, dove mappo direttamente in oggetti java tabelle 
e relazioni. se una proprietà deve assumere solo alcuni valori allora 
diventa un enum, così oltre a forzare il valore diventa autoesplicativo.


 Stefano M. Masullo segretario generale Assoconsulenza< 
ma vaffanculo te e masullo, hai postato la stessa pappardella su tutta 
it.*
-- 
/me che si prepara ad un altro salto indietro nel tempo.
E chi vuole, e specialmente puo' capire... capisca!

 questo mi pare un requisito a prescindere. 
Faccio solo due considerazioni. La prima: l'ambiente software deve
gestire questa chiara organizzazione. Però non sempre questo è fornito
in modo nativo (esempio: le pagine Jsp; i vecchi sistemi procedurali in
C e Cobol, ecc.).
Secondo: nella pratica quasi mai è possibile dividere in modo perfetto
il software in singoli gruppi/package di significato univoco. Così
avere una mappa delle relazioni e dipendenze effettive aiuta a non
perdere tempo ricercando col lanternino le tante classi di interesse
nei package comuni.

CUT
Quoto e sottoscrivo.
In quanto alla dodumentazione, devo dire che la piccola o piccolissima 
azienda italiana non e' affatto interessata ad essa....l'importante e' che i 
programmi funzionino bene, siano rispettatu i tempi di consegna e i costi 
stabiliti.
Non c'e' documentazione valida?....beh, chi in futuro dovra' intervenirci 
sopra.....si arrangera'!...:-(
ciao
fm 

 il software in singoli gruppi/package di significato univoco.
che vuol dire "in modo perfetto"? non è che devi cercare la perfezione. 
quando arrivi ad avere il problema delle sole situazioni ambigue sei già 
a cavallo. sicuramente se ti trovi nella condizione di non discernere il 
codice del calcolo iva da quello del calcolo ici.. beh, non mi sembra il 
caso di tirare in ballo la ricerca della perfezione.


 anni ho raddoppiato il mio capitale investito.
vaffanculo a mammete ! 

 diventa un enum, cosě oltre a forzare il valore diventa autoesplicativo.
Io ho iniziato programmando per vari anni in C. La STL del C++ ancora non
c'era o se anche c'era non erano molti i compilatori che la supportavano.
In moltissimi casi mi e' capitato di prendere codice scritto da altri,
capire cosa faceva, modificarlo, aggiungerci funzionalita', togliere
funzionalita',
fare refactoring, ecc. Anche su software composti da decine di migliaia,
se non centinania di migliaia di linee di codice. Ne faccio una questione
ancora piu' di lana caprina:
se uno non capisce cosa fa quel codice, si mette li e lo studia,
ricompila, debugga, ecc. fino a quando non capisce. Se capisce in 1 minuto
ci vorra' un minuto. Se capisce in un giorno ci vorra' un giorno, se
capisce in un mese ci vorra' un mese. Se non ha voglia di farlo, per
quanto mi riguarda potrebbe anche cambiare mestiere.
E se spesso mi incavolo per come vanno le cose e' proprio perche' la
"voglia di farlo" e' praticamente passata anche a me.
Saluti,
Marco.


 giorno, se capisce in un mese ci vorra' un mese.
Il problema è che aspettare una persona che capisca cosa fa il codice e
per farlo ci voglia un mese a livello industriale non è accettabile.
-- 
Ciao!
Luca

 per farlo ci voglia un mese a livello industriale non č accettabile.
bravo! ma questo si risolve facilmente, basta scrivere bene il codice. 
in un codice ben fatto una persona scafata diventa produttiva e lo 
diventa in tempi molto pių brevi.


 e lo diventa in tempi molto più brevi.
Dipende dalla quantità.
In ogni caso, per come la vedo io, ci sono i commenti? allora usiamoli!
Non dico commentare ogni riga, sarebbe irragionevole, però almeno avere
un idea di cosa fa un blocco di codice (una funzione?) è importante:
primo, per una questione di velocità, dato che se conosco scopo,
parametri e risultati ho tutto ciò che mi serve, posto che il blocco
funzioni; secondo, perché la testa delle persone è varia e differente,
e la chiarezza di intenti è un plus che facilita il lavoro; terzo,
perché se io riprendo in mano il mio codice dopo 6 mesi, mi da noia
andarmi a rivedere cosa fa, dato che non me lo ricordo... ;-)
-- 
Ciao!
Luca

 farlo, per quanto mi riguarda potrebbe anche cambiare mestiere.
Un programmatore C molto difficilmente capisce, ad esempio, un
programma Cobol/Cics, o magari Clipper. Se manca la documentazione
esplicativa, si deve per forza cercare qualche esperto (che nel tempo
diventa sempre più raro e costoso) per ricostruire la funzione svolta.
Così anche tu non capiresti un fico secco di un semplice pezzettino di
codice fuori della tua esperienza. Per quanto mi riguarda, quindi, puoi
anche cambiare mestiere... :-)

 dai docenti universitari ("io non posso leggere il codice".
Evidentemente tu leggi sempre codice scritto da veri maestri di
razionalità e chiarezza. Invece io, purtroppo, ho spesso avuto a che
fare con roba scritta da spaccapietre del software, del tutto
indifferenti alle pene di chi deve poi metterci le mani.
Eppure ti lamenti sempre dello schifo che è l'IT in Italia. Che
strano... :-)

 quanto mi riguarda potrebbe anche cambiare mestiere.
In un settore come il mio (applicazioni embedded in campo soprattutto 
industriale) un approccio simile non è possibile, per problemi di tempo ma 
soprattutto perchè non ci si può ad esempio mettere a fare esperimenti con 
il software che controlla un macchinario per capire come funziona (magari 
distruggendolo!). Io ad esempio, oltre ai commenti, produco "pallogrammi" 
che descrivono gli stati del sistema e le loro transizioni; non si può 
ricominciare da Adamo ed Eva tutte le volte che si riprende in mano un 
progetto o che lo fa qualcun altro. Se il codice è in Assembler poi 
sicuramente i commenti non sono sufficienti neppure se lo manutiene sempre 
la stessa persona. 

 diventa sempre più raro e costoso) per ricostruire la funzione svolta.
questo è lapalissiano. però fammi capire, tu vuoi far fare la 
manutenzione del software a chi non conosce il linguaggio con cui è 
scritto?


 In ogni caso, per come la vedo io, ci sono i commenti? allora usiamoli!
ok, però quando leggi i commenti vuol dire che sei già sul codice che 
intendi debuggare. e in ogni caso un codice correttamente commentato 
rientra, a mio modo di vedere, nel codice ben scritto.


 perché no? si potrebbe anche fare. 
certo, tutto si può fare, ma poi non ci si deve lamentare dell'overhead 
necessario per entrare nel progetto...
-- 
 Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

 la stessa persona. 
in quel settore non è nemmeno neccessario/sensato applicare metodologie 
di tipo agile all'origine della discussione.


 
http://www.flickr.com/photos/marko_po/
se "po" sta per Prato siamo anche paesani... 

 se "po" sta per Prato siamo anche paesani... 
confermo :)


 per farlo ci voglia un mese a livello industriale non č accettabile.
Puo' essere. 
Ma per come la vedo io, saper leggere il codice per un informatico e' come
saper leggere un disegno meccanico per un perito meccanico.
Il disegno ha le sue regole e chi vuole lavorare in quell'ambito deve
conoscerle. Il codice, forse, ha meno "regole", o comunque regole "meno
rigide" alle quali il programmatore deve sottostare , ma se questo genera
tempi di attesa lunghi per coloro che devono imparare a leggere, significa
solo che le "regole" attuali per la scrittura di codice rendono il
software 
non adeguato ad essere considerato un prodotto industriale e lo sviluppo
di codice conseguentemente non dovrebbe essere considerato un processo
industriale. 
Fare finta che il processore esegua quello che c'e' scritto in un
documento Word anziche' quello che e' scritto nel codice, secondo me non
risolve il problema (anzi, aggiunge al tempo di attesa necessario affinche
il programmatore impari a leggere il codice, anche il tempo di attesa che
il programmatore precedentge scriva il documento Word. Perche' comunque il
programmatore, prima o poi, quello che c'e' scritto nel codice lo deve
capire comunque, se ad esempio gli viene richiesto di fare una modifica al
codice scritto da un altro)
La mia personale impressione  e' sempre stata che si voglia consentire di
lavorare nell'informatica a persone che di informatica non ne sanno e non
ne vogliono sapere (vedi "io non posso leggere il codice") e per fare
questo c'e' bisogno che quelli che di informatica sanno qualcosa, lavorino
anche per questi sopra. D'altra parte controlli ce ne sono di tutti i tipi,
tranne che su come e' scritto il codice. Questo tipo di controllo
richiederebbe un tipo di competenza, o meglio di "cultura" piu' che
competenza, in ambito informatico che spesso nelle aziende non c'e'.
Ad esempio:
Personalmente al secondo anno di universita' ho trovato un professore 
(di calcolo numerico) che ci aveva chiesto di scrivere un programma.
L'affermazione fatta dal tipo era:
"se nel codice che scrivete non ci sono commenti esaurienti l'esame non lo
fate". E cosi' e' stato.
Prova ad andare in una azienda a dirgli: "mi serve una settimana per
scrivere commenti alle 10.000 linee di codice che ho scritto" e vedi cosa
ti rispondono.
Pero' se di settimane te ne prendi due per scrivere un documento word
nessuno ti dice niente (anzi, se invece che essere un programmatore sei un
"solution architect" di tempo te ne puoi prendere spesso molto di piu')
 
A mio modo di vedere un informatico dovrebbe decisamente avere problemi
zero nel leggere un codice commentato, capire cosa fa ed eventualmente
modificarlo.
Pero' i vari PM, ecc., spesso non sono informatici, quindi il codice,
commentato o meno non lo vogliono vedere. Il documento word invece si.
Ciao,


 diventa sempre più raro e costoso) per ricostruire la funzione svolta.
[SNIP]
Si ma scusa... Se tu sei un imprenditore e ti serve uno che sia in grado
velocemente di capire velocemente un codice scritto in cobol metti su
internet un annuncio che dice "cerco un esperto programmatore C per
attivita' di sviluppo software in linguaggio cobol?"
A parte che poi vorrei capire come pretendi che un programmatore C, quando
gli dai da sviluppare un codice in cobol senza aver mai visto tale
linguggio, possa essere produttivo in tempi brevi, anche se avesse a
disposizione un documento che descrive il codice stesso. Se il
programmatore C ha a disposizione dei buoni commenti all'interno del
codice cobol, stai tranquillo che ci mette meno tempo a imparare a
sviluppare in cobol , piuttosto che  se ha a disposizione solo un
documento Word e nessun commento del codice.
Ciao,


 imparare Java, Ruby o VB.
Si ma il punto di cui si discuteva era (almeno io lo avevo interpretato
cosi') :
"Supponiamo che il programmatore X conosca un certo numero di linguaggi
(ad esempio C/C++/Python);  supponiamo che X debba mettere le mani su del
codice *non scritto da lui* (supponiamo che Y abbia scritto il codice su
cui X deve mettere le mani), sia che tale codice sia scritto in
C/C++/python (ovvero in un linguaggio che X conosce) sia che tale codice
sia in Java, Ruby o Cobol (ovvero in un linguaggio che X non conosce). Per
ottenere che  il programmatoe X sia in grado di mettere le mani il piu'
rapidamente possibile sul codice scritto da Y e' meglio che Y abbia
scritto dei buoni commenti al codice e comunque abbia lasciato un codice
"leggibile" senza alcuna documentazione "cartacea" (per quanto ci sarebbe
molto da discutere su cosa voglia dire codice "leggibile") oppure e'
meglio che ci siano dei documenti "cartacei" e nessun commento al codice
(che magari potrebbe essere anche intricato quanto ti pare, tanto ci sono
i documenti che descrivono cosa fa il codice stesso) ?
Personalmente, quando ho dovuto fare qualcosa del genere (nel senso che io
ero X), ho sempre trovato preferibile avere codice "leggibile" e nessuna
documentazione piuttosto che l'opposto.
Ciao,
Marco


 imparare Java, Ruby o VB.
possiamo stare qui a ripetere lo stesso concetto all'infinito. uno che 
non conosce il linguaggio ha bisogno di tempo prima di poter mettere 
mano al codice, per quanto bravo questo tempo sarà sempre maggiore di zero.


 imparare Java, Ruby o VB.
Concordo completamente
A mio modesto modo di vedere, e l'ho ribadito innumerevoli volte, chi
si fissa sulla sintassi di un particolare linguaggio NON E' un
informatico nel senso stretto della parola. Come ripetuto già in altri
post, i linguaggi sono l'astrazione di un algoritmo. Essendo la
stragrande maggioranza dei programmi scritti in linguaggi che stanno
tra il paradigma operativo e quello a oggetti, tranne rare eccezioni,
l'informatico , quello vero, sa e si rende ben conto che il linguaggio
è uno strumento e che nella sua cassetta degli attrezzi ci devono
essere più strumenti per raggiungere un determinato scopo.
Ad esempio  io che non ne so nulla di sintassi Perl, correggo,
CAPENDOLI, fior fiori di script Perl che fanno le cose più disparate.
Sono uscito dal campo dello sviluppo ben cinque anni fa, dopo una
forzata e non voluta "ricaduta" dopo due anni da sistemista di
sicurezza. Non capisco nulla quindi di tutti questi magici tool che
generano programmi a partire da interfacce definite e da strumenti di
design. Per come la vedo io sarebbe meglio scriversi  del codice
direttamente... ma forse sono troppo "antico".

 strano... :-)
Infatti io interverrei *obbligando a scrivere "bene" il codice*,
cosa che un informatico *deve saper fare* a mio modo di vedere
(cosi' come, a mio modo di vedere, dovrebbero saperlo fare quelli che fanno
il controllo di qualita'),
anziche' fregarmene se il codice e' scritto male, tanto c'e' la
documentazione.
Ovvero il controllo lo farei sulla qualita' del codice, anziche' sulla
presenza di documenti sui quali il numero di versione sia corretto
(il controllo di qualita', con il quale sto avendo a che fare proprio
in questo periodo, si preoccupa infinitamente se tu hai un documento su
cui c'e' scritto che quella e' la versione 1.2 e poi hai il documento con
versione 1.0 ma non hai il documento con versione 1.1. Si preoccupa anche
se nella "test object list" ci sono 2-3 test case su 40 in cui compare la
dicitura N.A., anche se spieghi in una nota di quel test case il perche'
di quell' N.A. Invece nel codice ci possono essere le peggiori schifezze
che vuoi, ma nessun controllo di qualita' se ne freghera' mai. D'altra
parte per fare un controllo di qualita' sul codice bisognerebbe sapere
qualcosa di informatica. Spesso pero' chi fa il controllo di qualita'
l'informatica l'ha giusto sentita nominare, almeno nelle grandi aziende.
D'altra parte hanno ragione loro visto che il controllo di qualita' e'
*sempre* sul *processo aziendale* e *mai* sul *prodotto*).
Ciao,
Marco


 informatico nel senso stretto della parola. 
scusa eh... ma nessuno stava sostenendo il contrario di questa 
affermazione peraltro lapalissiana.
prova però a ricostruire questo thread (almeno gli ultimi 3/4 messaggi) 
e giudica tu se si stava discutendo di questo. certamente un informatico 
deve sapersi districare fra i linguaggi, ma ciò non toglie che (come 
nell'esempio di ispas) mettere apposta una persona che non conosce il 
cobol a manutenere un programma cobol non è proprio la scelta ottimale, 
spece se poi ci si preoccupa del tempo che impiega a diventare produttivo.
-- 
? Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

 la stessa persona.
Infatti io posso capire che il codice "scritto bene" possa talvolta non
essere sufficiente (ma spesso lo e' dato che , almeno nella mia
esperienza, gli ambiti come il tuo non sono la maggioranza di quelli che
si incontrano). Quello che io trovo inconcepibile e' che se anche il
codice e' "scritto male" spesso nessuno ha niente da dire, mentre se manca
qualcosa nei documenti cartacei si incavolano tutti come iene
(e la frase o comuqnue l'atteggiamento e' sempre lo stesso: "io non posso
leggere il codice").
Ciao,
Marco


 direttamente... ma forse sono troppo "antico".
Non so i tuoi colleghi, ma io che sono probabilmente "troppo antico"
esattamente come te, lavoro a stretto contatto con colleghi piu' giovani
che sono superultraesperti di "tool che generano programmi a partire da
interfacce definite e da strumenti di design" ed esattamente come te, mi
e' capitato in passato di mettere le mani su codice scritto in linguaggi
che non conoscevo (tipo Delphi) e farne delle modifiche.
Pero'  i miei colleghi di cui sopra sono tra i piu' strenui sostenitori
della necessita' di documentazione cartacea e dell'atteggiamento del tipo:
"dove lavoravo prima avevano del codice scritto in C. Appena lo abbiamo
visto c'era da mettersi le mani nei capelli: hanno deciso di riscriverlo
in java".
Ora il codice in questione io non l'ho visto per cui magari c'era davvero
da mettersi le mani nei capelli. Pero' quando lavoravo nella
multinazionale precedente un atteggiamento simile l'ho visto spesso e, dal
mio punto di vista, spesso era piu' dovuto al fatto che la gente non aveva
molta voglia di andarsi a leggere il codice, specialmente se in linguaggio
a loro non gradito (per non parlare poi dei vari PM ecc., che se gli dici
"in java si fa prima....")
Ciao,


 Marco.
Ciao

 spece se poi ci si preoccupa del tempo che impiega a diventare produttivo.
Dipende.
Io sono diventato produttivo in Oracle Pro*C dopo una giornata a
leggere codice, ma sapevo di C e sapevo di SQL. Dovessi rifarlo in
COBOL mi ci vorrebbero almeno quattro giorni uomo, manuale alla mano,
quindi in questo caso particolare dipende dal linguaggio usato...

 cosa ti rispondono.
Veramente io ho lavorato in diverse aziende (in 20 anni qualcuna ne ho
passata) e codice ben commentato è stato un requisito. Nota che ho
detto 'ben commentato', che 10.000 righe di codice non implicano 10.000
righe di commento (anzi, probabilmente 200 basteranno)!
Per contro, chi ha l'approccio che hai tu mi sembra quello di chi dice
'non sono io che devo mettere commenti, sono gli altri che devono
capire ciò che scrivo', presupponendo che ciò che si scrive sia
perfetto. Non considera, questo approccio, che l'uomo per sua natura è
veriabile nel tempo, che ciò che scrivi oggi non lo scriverai uguale
domani, ma soprattutto che una persona che approccia ciò che hai
scritto ha un modo di pensare completamente differente dal tuo.
-- 
Ciao!
Luca

 scritto ha un modo di pensare completamente differente dal tuo.
Si', ma questo vale anche per quello che trovi scritto in un documento
cartaceo.


 io che sono troppo antico.
Direi che siamo in due.
Ciao,
Marco (che usa vi, o meglio vim, anche sotto Windows).


 sfaticati ma prendi gente in gamba.
beh, siccome ora mi trovo dalla parte opposta del tavolo rispetto alla
quale sono sempre stato mi chiedevo appunto, come fare in modo che:
1. le persone che lavoreranno sul mio codice non _debbano_ farsi il culo
per fare il lavoro, ma semplicemente lavorino
2. acquistino ragionevole indipendenza e capacita' di astrazione.
il sunto dei reply per ora e' che serve buona documentazione e gente in
gamba.


 sopra.....si arrangera'!...:-(
:-) si ma il livello di validita' dipende dal lettore, no?
pensa al telefono cellulare: ci sono persone che devono leggersi tutto il
manuale, altri che navigano per i menu' con sicurezza. da un
professionista mi aspetto che sappia muoversi, ad esempio, in un database
(tra l'altro di sono software che generano documentazione) e che necessiti
di sapere _cosa_ un un campo rappresenti e non _come_. 


 un buon programmatore impara un nuovo linguaggio in pochissimo tempo.
si, ma un buon programmatore lo fai continuare a programmare bene nel suo
linguaggio, a meno che egli stesso per propri motivi, non voglia dedicarsi
ad altri linguaggi.
un pessimo programmatore lo provi su un altro linguaggio ed hai serie
probabilita' che faccia cagare anche in quell'altro.


 documentazione.
C'è da dire che le tecnologie e gli standard cambiano rapidamente in
informatica. Ciò vuol dire che quello che era standard e scritto bene
10 anni fa oggi potrebbe anche essere pericolosamente incompleto ed
insufficiente.
Poi, se il codice è scritto male, o semplicemente segue logiche
"strane" o vecchie (e questo nella realtà è comunissimo), devo dedurre
da quanto dici che la sua manutenzione/lettura diventa impossibile.
E questo è inammissibile.

 di capire ti annoia parecchio :-)
no, dai... dipende.
ad esempio, documentare "tecnicamente" il db nei dettagli, lo trovo spesso
inutile. ci sono software che lo fanno.
con tre pagine di descrizione dei meccanismi me la tolgo.
la parte di codice segue rigorosamente delle guidance e dei pattern (si e'
un codice microsoft e segue le factories WSSF e SCSF). il codice lo
commento mentre lo scrico con la descrizione di cosa implementa la classe
ed i metodi, uno per uno.
Non sono l'analista, nel codice non spiego gli algoritmi, ma indico il
riferimento al documento business in cui e' illustrato, etc.
quello che _non_ voglio documentare, tanto per fare un esempio, e' questo:
- Ho la stored procedure sproc_PaperogaGet
- Ho un Data Access Layer
- per sapere quale/quali metodi accedono alla sp mi basta una search sul
nome della procedura, non ci sono pattern strani di astrazione del db...
perche' dovrei documentare nel mio codice DAL che nella classe public
class Papersera, c'e' il metodo PaperseraRedattoriGet che richiama
sproc_PaperinoGet e sproc_PaperogaGet?


 scritto?
Ok, ma allora non facciamo i grandi discorsi. Alla fine stiamo
convergendo sull'idea che un codice puň essere letto solo da chi
conosce quel linguaggio (o meglio quell'ambiente con librerie, tools,
ecc., il linguaggio č solo la base), e magari da chi conosce quella
problematica, specifica (banche piuttosto che ente pubblico, industria,
ecc.).
Almeno, se la documentazione esiste, si amplia un pň il campo, visto
che un maggior numero di persone conosce l'italiano, o l'inglese se
vuoi... :-)
Se invece vediamo i casi di migrazione verso un nuovo ambiente, qui
diventa frequentissimo che il "nuovo" sviluppatore non č assolutamente
in grado, da solo, di capire il vecchio codice (es. da Cobol/Cics a
Java).

 scritto ha un modo di pensare completamente differente dal tuo.
Perfetto! E' come pretendere che chi conosce l'italiano (= Java, per
esempio) debba per forza conoscere il cinese (= Visual Basic), e debba
essere produttivo nello stesso identico modo.
(invece di Java e VB, ci si puň mettere "logica di Ispas" e "logica di
Pincopallo", la situazione č identica).

 Java).
migrazione intanto e' un concetto che appartiene allo sviluppo di un nuovo
progetto e non alla maintenance. quindi il pm dovrebbe prevedere due
figure professionali, l'una che comprenda l'attuale codice, l'altra che
comprenda quello nuovo. inoltre difficilmente un porting si limita ad una
traduzione di un codice in un altro, ma prevede implementazione di nuove
eo diverse funzionalita'. il "vecchio codice" quindi e' fornito come
materiale per aiutare la stesura del nuovo, come "documentazione", esempio
o per parziale riuso. nel caso dei db immagino pure per porting dei dati
esistenti.


 informatico nel senso stretto della parola. 
A parte che il linguaggio vero e proprio spesso č solo uno dei
componenti del prodotto, e neppure il piů importante. Quindi, se non
sai cosa fa la funzione x della libreria y, come fai ad astrarre
l'algoritmo leggendo solo il codice?
Magari se il programma ha 100 righe forse ce la fai pure...

 cobol?"
Bè, mica sono io a sostenere che al "vero informatico" basta il codice
per capire tutto...
Quanto ad imparare facilmente un linguaggio dai commenti, mi sembra
impossibile.


Vabbè qui ovviamente siamo d'accordo: se il software è fatto coi piedi
il problema della documentazione diventa secondario.

 E questo è inammissibile.
Guarda che con queste cose io  posso anche piu' o meno concordare.
Se mi dici: "il codice e' obsoleto, rifacciamolo" posso capire.
Pero' questo vale anche se c'e' documentazione cartacea associata a quel
codice.
In altre parole quello che capisco poco e' se mi dici:
"se il codice ha una documentazione cartacea associata allora non diventa
mai obsoleto ne' difficile da manutenere, mentre se non ha una
documentazione associata, allora e' sicuramente obsoleto e di difficile
manutenzione, anche se fosse scritto nel modo migliore possibile".
Ciao,
Marc


 impossibile.
Guarda che se uno non conosce il cobol e deve impararlo, nemmeno
la documentazione  cartacea del programma scritto in cobol serve allo
scopo.
Anzi, direi che serve *decisamene meno* rispetto al codice (a meno che
tale documentazione non contenga un corso di cobol, cosa di cui dubito).
Di sicuro i commenti al codice servono per capire cosa fa il codice.
Poi e' ovvio che se io ho 10 anni di esperienza in C, faro' prima a
modificare
un codice scritto in C che non uno in Clipper.


 possibile".
Io propendo per la prima, nella maggiore manutenibilità e nella più
lenta obsolescenza, in riferimento al fatto che quella documentazione
ti può chiarire molto più rapidamente del codice la business logic, o
comunque lo scopo del codice (a parte che anche la documentazione può
essere scritta male, nessuno è perfetto... :-)
Sulla seconda ipotesi dico solo che in pratica penso sia molto
difficile trovare grandi procedure che sono scritte tutte con ottima
qualità, con logica uniforme, ecc. Se questo accade, certamente anche
il codice è un'ottima base. Sempre con la limitazione che il codice lo
può leggere efficacemente solo chi conosce bene quell'ambiente
software, mentre una documentazione può essere più universale.
 

 Magari se il programma ha 100 righe forse ce la fai pure...
Se la funzione x si chiama effettivamente x, nel senso che ha un
prototipo del tipo
int x(char *c, char *d, char *k[], int z, int *u)
effettivamente e' un po' difficile (per quanto andando a vedere il corpo
delle funzione talvolta si potrebbe fare (ma dubito che se il prototipo e'
di questo tipo poi il corpo sia comprensibile).
Invece se magari il prototipo e' del tipo:
int TDES_cipher(const char *source, char *destitation, const char *keys[],
int  source_len, int *destination_len)
forse, se ho una vaga idea di cosa sia il Triplo DES, ho gia' qualche idea
su cosa faccia la funzione in oggetto e magari anche di cosa significhino
i parametri (certo per capire gli ultimi 2 un po' di C lo devo avere
"smanettato". Per i primi 3 basta probabilmente sapere qualcosa
sul triplo DES);
 magari, anche se non so molto ne' di TDES ne' di C, posso
comunque capire molto, se  subito prima o subito dopo la riga in cui c'e'
il
prototipo c'e' anche un commento del tipo
//////////////////////////////////////////////////////////////////////////
//
// La funzione TDES_cipher, prende in ingresso un array di caratteri ed
// esegue una cifratura triplo des secondo quanto descritto nel documento
// FIPS PUB 46-3 del 25 ottobre 1999. Prima di essere cifrato, il dato di 
// ingresso verra' esteso aggiungendovi in testa una stringa di 4 byte 
// contenente la dimensione in byte dell'array da cifrare.
//  Poiche' questo tipo di cifratura 
// prevede che il dato di ingresso sia cifrato a blocchi di 7 bit 
// (aggiungendo un bit di parita' come ottavo bit per ogni blocco di 7 bit,
// secondo quello che e' descritto nel documento sopra nominato), se la
// dimensione del dato di ingresso non e' un multiplo intero di 7 bit,
// verrà effettuato un padding secondo le seguenti modalita' <descrizione
// delle modalita' di padding>
//
// PARAMETRI:
// const char *source: puntatore all'array di caratteri da cifrare. 
 
// char * destination: puntatore alla zona di memoria che dovrà contenere
//                     il risultato della cifratura. Dovra' essere una 
//                     stringa esadecimale. L'allocazione della memoria
//                     puntata da destination viene effettuata nel 
//                     chiamante 
//
// const char *keys[]  : puntatore ad un array di 3 array di char.
//                       ogni array di char costituisce una chiave per 
//                       la cifratura
//                        
// int source_len      : dimensione dell'array da cifrare
//
// int *destination_len: questo e' un parametro di Input/Output.
//                       In Input *destination_len contiene la dimensione 
//                       massima della zona di memoria                    
    //                       puntata da destination. In output dovrà
contenere
//                       la dimensione del dato cifrato 
//
// VALORI DI RITORNO:
//   
// se la cifratura ha successo, TDES_cipher restituisce 0
// se la cifratura fallisce TDES_CIPHER restituice un valore negativo;
//
// -2 => la memoria puntata da destination non e' sufficientemente grande
//       per contenere il dato cifrato
// -3 => <ecc..>
// -4 => <ec..>
//////////////////////////////////////////////////////////////////////////
int TDES_cipher(const char *source, char *destitation, const char *keys[],
int source_len, int *destination_len);
Ciao,
Marco.


 Magari se il programma ha 100 righe forse ce la fai pure...
questo va senza dire.
Però forse mi sono spiegato male: se hai tutte le interfacce
funzionali e i tipi dati specificati devi essere in grado di leggere
il codice.
L'esempio mio che ti ho citato è perchè il committente per ogni
programma aveva fornito dettagliata interfaccia funzionale... in
mancanza di questo, stiamo parlando del sesso degli angeli.

 gamba.
Queste due cose servono sempre ;)
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/06/relazioni-molti-molti-con-jpa.html

 sproc_PaperinoGet e sproc_PaperogaGet?
Diciamo che, se č facile ricavare con qualche tool o funzione
automatica queste informazioni, perchč non ricavarle e metterle in un
documento? :-) All'inverso, se fosse difficile, allora un documento
fatto a mano con tali informazioni sarebbe prezioso.
Piů o meno quello che dicevo riguardo al db.

 francesismo.
nella maggior parte delle applicazioni che vengono scritte di recente si
usano architetture n-Tier o n-Layer. 
molta della logica business si concentra nel Domain Layer (cfr. M.Fowler
PEAA)ed e' li che c'e' la specificita' dell'applicazione.
poi parte delle interazioni sono anche nella Facade o UI, chiaro, ma una
buona esperienza di UI dovrebbe permettere di leggere il codice abbastanza
agevolmente.
Se una UI e' implementata con MVC o MVP, questo va relativamente
documentato: e' il developer che deve sapere o imparare il pattern e
riconoscerlo nel codice, altrimenti i commenti diventano un corso
DeAgostini per aspiranti dev.
Come ho detto in un altro post, un conto e' dover commentare il domain
layer dove e' realizzato un calcolo, un conto e' commentare un DAL in cui
una stored procedure e' lanciata con i suoi parametri, ed il risultato e'
messo in una variabile. posso commentare la signature del metodo del DAL,
ma anche li, con un piccolo sforzo, vedo come diamine e' richiamata dal
Domain layer che e' quello che invece dovrebbe avere la descrizione piu'
particolareggiata.


 particolareggiata.
Quindi mi pare che concordiamo... o no ?
Ciao,
Marco.


 Piů o meno quello che dicevo riguardo al db.
cioe', ad un professionista che ha in mano il codice serve una lista dei
membri pubblici di una classe e non basta aprire sto cazzo di classe e
vedere cosa e' public?


 Marco.
ciao
Andrea

 Direi che siamo in due.
almeno in tre :-) anzi , scommetto che siamo in ottima e abbondante 
compagnia qui dentro
Andrea 

 classe e vedere cosa e' public?
no, mi riferivo ai metodi che richiamano la sp_paperopoli (o come si
chiama :-)

 metterà comunque a capire il codice in sè.
premetto una cosa: io lavoro ormai da diversi anni in java e se devo 
scegliere fra un programmatore che non conosce java ma potenzialmente 
bravo da tirar su e uno già formato ma meno bravo, scelgo sicuramente il 
primo. questo per dire che su questo punto con me sfondi una porta aperta.
quello che ti contesto è un'altro punto. tu insisti sul problema di 
conoscere la semantica, in realtà quello è l'ultimo dei problemi ed è 
chiaro che si possa minimizzare. il problema grosso è che ci si trova di 
fronte a tecnologie completamente diverse e modi di programmare 
completamente diversi. in java non si programma affatto allo stesso modo 
di come si programma in python o in cobol o in pl/sql. se non hai mai 
visto java e sei un bravo programmatore è chiaro che con la sintassi in 
poco tempo ti arrangi, ma se ti trovi davanti a degli ejb e non sai cosa 
sono gli ejb non ti basta certo mezza giornata solo per capire dove 
mettere le mani. ma la stessa cosa si può dire delle jsf, di struts, 
hibernate, di come si scrive un web service, eccetera, eccetera. quando 
una persona esperta di altri linguaggi viene "fiondata" su un'altra 
tecnologia e gli viene chiesto di essere subito produttiva, di sicuro in 
qualche modo se la cava, ma a che prezzo? inevitabilmente tende a far 
ciccia continuando a programmare con gli stessi pattern di prima (dove 
si sente sicuro) col risultato che scrive un sacco di puttanate, magari 
in qualche modo funzionanti ma pur sempre puttanate.
-- 
 Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

 "papperà" suo malgrado l'azienda e NON certo le risorse.
Quoto.
Personalmente credo che l'azienda non sia affatto ingenua...
ovvero se nella fase 1 (in cui ha acquistato del codice di bassa qualita') 
ha risparmiato...
sa benissimo che nella fase 2 (nella quale qualcun altro dovra' rimaneggiare 
il codice di cui sopra) ... potrebbe andare in contro a costi notevoli.
Proprio per questi motivi, in certi casi preferiscono sostituire il software 
anziche' modificarlo.
In quanto poi allo "spremere" il fornitore ...beh, certe aziende ci provano 
sempre e comunque ... :-)
ciao
fm


IMHO... servono anche soldi...:-)
Poiche' le PMI italiane vogliono spender poco....temo si sia gia' innescato 
un meccanismo del tipo "la moneta cattiva scaccia quella buona".
ciao
fm 

fm ha scritto:


siccome la mia domanda era:
<AUTOQUOTE>
come posso renderli self-confident e quindi autonomi con i problemi che
devono risolvere? come posso dare loro l'idea che e' bene essere
interattivi con me ed altri, che possono (devono!) chiedere quando hanno
dubbi o non hanno il bagaglio tecnico necessario per continuiare, anziche'
<AUTOQUOTE>
ritieni che debba pagarli personalmente (sono dipendente del posto in cui
loro sono consulenti) ogni volta che gli parlo? :-)
disperarsi nella loro solitudine? 
