Newsgroup: it.lavoro.informatica
Titolo: cosa fa un analista?

io non sono un programmatore e quando giocavo con il commodore e l'amiga
leggevo sulle varie riviste che e' buona prassi per chi sviluppa 
commentare il codice.
Bon per 31 anni sono rimasto di questa idea facendo fede a cio' che ho 
letto, chiacchierando con la mia ex ragazza invece scopro che questa 
cosa e' una cazzata, che il codice non viene commentato e che questa 
parte diciamo "verbale" e' compito dell'analista che poi passa il 
malloppone al "coder" che prevede a trasformarlo in codice.
Mi fate capire meglio come funziona la cosa?
Oppure solo li dove lavora la mia ex fanno cosi?
Grazie.

Oppure solo li dove lavora la mia ex fanno cosi?
No non solo li', ma di sicuro immagino che schifezze di codice
producono.
C'ya
	Steve
-- 
Legge di Flon
Non c'e' linguaggio in cui sia difficile scrivere cattivi programmi.
FAQ del gruppo : 
http://www.sen.it/faq/it.lavoro.informatica.faq.html
 
http://www.duestrade.it/HOWTO_leggere_annunci.html
 
http://www.duestrade.it/HOWTO_mettere_annunci.html
   --- 
sbo...@despammed.com
 ---

 malloppone al "coder" che prevede a trasformarlo in codice.
Commentare il codice è una cosa, fare documentazione è un'altra.
E' vero comunque quello che dice la tua ex. La prassi corretta è, in 
varie forme, che l'analista scrive cosa deve fare il programma e la 
programmazione lo realizza. Poi nel dettaglio dipende da come è 
strutturato il gruppo.
Resta il fatto che i commenti sul codice non c'entrano nulla, commentare 
*bene* (che non è sinonimo di *tanto*) il codice è buona pratica di 
programmazione.

 producono.
Ok informero' l'IBM che non sanno programmare :-D lol

 programmazione.
no no io mi riferivo al commento codice e non documentazione
per me il commento e' ( chiedo scusa della banalita' ma come ex 
commodoriano 64 :-D )
10 print "a" ;stampa il carattere a sul video
per me il commento e' quello dopo il ;
credo che con la mia ex non ci siamo capiti.
Ma allora l'analista cosa fa di preciso?

 Ma allora l'analista cosa fa di preciso?
Raccoglie in input i requisiti del programma e produce in output la 
documentazione su come il programma deve essere fatto.

Ok informero' l'IBM che non sanno programmare :-D lol
 :-) e' cosa nota da decenni :-)


per me il commento e' quello dopo il ;
Tecnicamente ovviamente si' :)
C'e' anche da dire che commentare e' un'arte, ovvero un commento come
quello nell'esempio e' del tutto inutile.
C'ya
	STeve


 quello nell'esempio e' del tutto inutile.
Beh ovvio che e' inutile era per un esempio ultraelementare date le mie
ignoranze :-D

Bene ora ho maturato una conoscenza in piu' grazie ad entrambi per aver 
ridotto il grado di entropia nel mio cervello, visto mai che inizio a 
programmare :-)

ignoranze :-D
Infatti, ma non hai idea di quanti "colleghi" sviluppatori che mettono
commenti di quel genere o non ne mettono affatto :-(
Gli venisse ... :)


 commenta 
forse lei non lo commenta.
normalmente il codice ha i suoi bei commenti.
e li mette il programmatore, che si sporca le mani nel codice, non certo 
l'analista.
-- 
FabMind

 coder, spesso anche il tester :-)
Da cui si trae analista-programmatore ;-P
-- 
Spotmusic: tutto sulla musica degli spot!
www.spotmusic.net

 ha scritto nel messaggio 
news:d1a7jt$upt$1...@area.cu.mi.it...


 Ma allora l'analista cosa fa di preciso?
Nella mia esperienza, in buona parte dei casi l'analista cerca di
confondere il programmatore riguardo a cosa/come/quando realizzare una
caratteristica di un programma :D
Andrea

 commodoriano 64 :-D )
I migliori commenti sono quelli "per intenzione". Guarda questi
esempi:
"Assegno ad x il valore risultante dalla formula in basso."
"Risolvo l'equazione di secondo grado utilizzando la formula in basso."
(si presuppone che il commento sia messo PRIMA della riga di codice
interessata).
Il primo commento non documenta l'intenzione, ma solo il codice,
mentre il secondo documenta ciň che si vuole ottenere tramite
quella riga di codice(intenzione).
Una cosa secondo me *molto* sottovalutata č la mancanza di commenti
nelle sezioni dichiarative, cioč non si indica spesso - per
esempio - la funzione generale di una classe e/o la sua architettura di
massima. Tante volte(ma non sempre...) questi commenti possono
essere sostituiti dal nome della classe stessa(codice autodocumentante).
Ciao,
Andrea

 "coder" che prevede a trasformarlo in codice.
sull discorso del commentare il codice esistono delle correnti di pensiero e 
discussioni infinite.
Lo sviluppo del codice (almeno ad alto livello, oop per intenderci) sta 
entrando nella sua piena fase di maturità e si stanno 
consolidando/formalizzando pratiche anche molto diverse.
Un esempio su tutti è l'extreme programming che in questi ultimi anni sta 
mietendo molti consensi anche fra sviluppatori ed architetti sw molto famosi 
sia nel mondo java (è da lì che ha avuto origine), sia nel mondo .Net. 
Ebbene uno dei must dell'xp è che il codice non deve essere assolutamente 
commentato: se lo sviluppatore sente la necessità di commentarlo o cmq chi 
legge il codice sente la mancanza di un commento significa che il codice è 
scritto male, in quanto il codice stesso deve essere autoesplicativo. come 
fa ad essere autoesplicativo? questa risposta sarebbe troppo lunga da dare 
qui ed è una delle tematiche centrali dell'xp articolata su più punti 
(convenzione dei nomi, refactoring, metriche, ecc.).
In generale cmq anche nell'xp certe tipologie di commenti sono ben accette: 
quelle che permettono la compilazione di di file di help in automatico (tipo 
help degli sdk) e quelle specifiche che non hanno a che vedere direttamente 
con il codice stesso (ad esempio se in una istruzione moltiplico un prezzo 
per 1,2 si può mettere un commento sul fatto che è proprio 1,2 perchè alla 
tal data la legge prevede il 20% di iva).
Quindi in assoluto il discorso dei commenti non è nero o bianco, anche se 
devo dire che il discorso che fa la tua ragazza sulle diverse mansioni 
programmatori/analisti mi suona un po' strana, nel senso che l'analista 
esegue l'analisi dei requisti funzionali, ma questa non c'entra molto con i 
commenti al codice.
saluti
Roberto 

 coder, spesso anche il tester :-)
anche il tester?
personalmente vedo malissimo uno sviluppatore che testa anche il suo codice 
(anche a me purtroppo a volte capita, e devo dire che faccio schifo nel 
testare il mio stesso codice...)
saluti
Roberto 

 scritto male, in quanto il codice stesso deve essere autoesplicativo.
Cavolo, sono piu' o meno 18 anni che programmo secondo la filosofia 
Extreme Programming e nemmeno lo sapevo. Chissa' se posso rivendicarne 
la paternita'... :-)
Saluti.

 scritto male, in quanto il codice stesso deve essere autoesplicativo.
Non è detto, potrebbe anche semplicemente essere un principiante
oppure un wannabe.
Ciao,
Andrea

commenta 
Dunque, io mi son fatto l'idea che la tua ex, di programmazione, ci
capisse pochino. Il compito dell'analista _non č_ quello di scrivere
commenti, ma di stabilire il contesto entro cui il coder si deve
muovere. Come poi si muova il coder in questo contesto, sono affari
del coder stesso, che deve avere, o dovrebbe avere, la buona
educazione di commentare quanto ha fatto per aiutare l'eventuale altro
coder che dovesse fare successiva manutenzione.
Poi, va detto che qualcuno all'epoca affermava che un codice ben
scritto si commenta da solo, ma č stato prontamente legato e frustato!
:)))
--
Ciao!
Luca Menegotto

testare il mio stesso codice...)
Sottoscrivo. Ah, visto che ci sono, io faccio schifo anche a fare
documentazione... :)))
--
Ciao!
Luca Menegotto

tutti da evitare :-)
Beh, dipende dalle dimensioni del progetto. Dal mio punto di vista,
nel caso in cui siano coinvolte decine di programmatori  il ruolo di
analista  - forse direi meglio, di coordinatore di progetto - è
fondamentale. 
Credo che in effetti, se ho capito bene quel che fai tu, nel tuo caso
una divisione del genere sia inutile, se non deleteria.
--
Ciao!
Luca Menegotto

 Luca Menegotto
Andrea


wrote:

Oppure gli si vogliono dare le linee generali per individuare dove
mettere le mani in fase di manutenzione senza dover andare a spulciare
riga per riga. Anche perché la teoria del 'codice ben scritto' la
sento da 25 anni, e finora non ne ho visto applicazioni funzionanti.
--
Ciao!
Luca Menegotto

riguardo - ad esempio - i bug fix e cose simili.
Andrea, io ho iniziato a programmare a livello professionale facendo
parte di un team di sviluppo. Si parlava dei commenti, e queste erano
piů o meno le direttive.
1) ciascuna funzione deve possibilmente non superare la pagina
stampata, deve essere commentata circa cosa fa, parametri in ingresso,
risultato, eventuali effetti collaterali (so che non ci devono essere,
di principio, ma talora fanno comodo, e tieni presente che all'epoca
OOP iniziava a muovere i primi seri passi).
2) ciascuna variabile deve essere dichiarata in modo autoesplicativo
3) il commento all'interno del codice non deve commentare una singola
riga, ma deve, blocco per blocco, indicare il passaggio logico che il
blocco commentato assolve, in modo che un eventuale manutentore
comprenda il procedimento impiegato durante l'implementazione dalla
sola lettura dei commenti.
Io di mio, negli anni, ci ho aggiunta una sola cosa:
4) tutte le variabili dichiarate a livello globale (chiaramente per i
rispettivi scope) vanno commentate, soprattutto nel caso in cui siano
possibili malintesi o fraintendimenti.
--
Ciao!
Luca Menegotto

 - la documentazione
Mi associo.
Chi dice che il codice non si commenta, IMHO, č un pessimo esempio di 
programmatore.

 Mi fate capire meglio come funziona la cosa?
Che differenza c'è tra chi progetta una casa e chi si mette li con mattoni, 
calce e cazzuola a tirar su le pareti?
Ecco, tra analista e programmatore più o meno la differenza è la stessa: uno 
progetta, l'altro implementa.
Facilmente puoi trovare ragazzini di 3°-4° superiore che sanno fare qualche 
programma, magari anche in linguaggio a oggetti. Molto piu difficilmente 
riuscirai a trovare persone che sanno fare l'analisi e la progettazione di 
un software prima della laurea in informatica o scienze dell'informazione (o 
almeno prima di aver studiato per alcuni esami) 

 ha scritto nel messaggio 
news:IAa_d.1073578$35.39...@news4.tin.it...

ho sempplicemente esposto le linee guida dell'xp, nulla di più.
saluti
Roberto 

 :)))
pensa che su questa base si muove l'intero movimento delle Agile 
Methodolgies...
saluti
Roberto 

 possibili malintesi o fraintendimenti.
ok per la programmazione procedurale o strutturata, non dovrebbe essere 
necessario invece nella oop in quanto in teoria non dovrebbero esserci 
variabili globali in giro.
saluti
Roberto 

 ha scritto nel messaggio 
news:423949b9$0$6299$5fc...@news.tiscali.it...

si potrebbe allora ancora andare più in profondità nella "gerarchia" delle 
mansioni introducendo l'architetto della soluzione.
saluti
Roberto 

 riguardo - ad esempio - i bug fix e cose simili.
I commenti nel codice sono una questione spesso controversa. Di solito 
*cosa* e *come* si commenta fa parte delle regole del gruppo di lavoro, 
ma alcune regole sono generalmente condivisibili. Ad esempio, non si 
descrivono nei commenti informazioni ridondanti, ovvero già descritte da 
altri elementi del linguaggio; es. se si usa una nomenclatura di nomi 
descrivere i nomi stessi è fuffa, come è fuffa descrivere ciò che si 
evince chiaramente dalla lettura del codice. Inoltre i commenti non 
devono essere prolissi e non devono togliere leggibilità al codice 
(rispettare le indentazioni, spaziatura, etc...).
Se usi un CVS, è abbastanza inutile anche descrivere modifiche e bug-fix 
perchè queste descrizioni vanno nella versione alla commit (ed è quello 
il suo posto; sai quando è stata fatta la modifica, da chi e in che 
versione). Inoltre chi vuole vedere il dettaglio della modifica è più 
esplicativo fare una diff fra le versioni, eventuali commenti aggiunti 
fanno aumentare inutilmente le differenze nel confronto.
In definitiva, le buone norme di programmazione fanno un uso molto 
parsimonioso dei commenti, contrariamente a quello che viene 
istintivamente da pensare.

 grazie a te se rispondi
ciao Nicola
 
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 
Be scagli la prima pietra chi non ha mai fatto (magari preso dalla 
fretta) un programma senza particolari commenti?  Ma da li a dire che e' 
una cazzata, e' una cazzata secondo me. Io il mio codice anche se e' 
vecchio lo capisco sempre, pero' facilita la lettura a chi il programma 
non lo ha fatto (e comunque lo stesso anche a te) e si trova a doverci 
operare. Poi il fatto che l'analista butti giu' il problema in forma 
scritta non e' equivalente a commentare il codice direi. 
Quando ho avuto a che fare con un'analista che facesse da intermediario 
con il cliente (poche volte), lui mi diceva cio' che aveva visto e io 
decidevo gli interventi. Pero' ho visto analisti scrivere l'analisi ed 
indicare ai programmatori "porzioni di codice" o indicare i colori delle 
label o altro, brrrrrrrrr.
-- 
Federico

 coder, spesso anche il tester :-)
Non solo non e' la situazione ideale ma perlomeno se proprio vogliamo
separare queste professioni, almeno bisognerebbe assicurarsi che
l'analista abbia esperienza di programmazione mentre invece in molte
realta' l'analista non ha la piu' pallida idea di come si programmi ma
viene preso soltanto perche' ha un titolo di studio superiore. Il disastro
e' l'inevitabile conseguenza di questa scelta assurda e dettata
dall'ignoranza informatica di chi ha praticato questa scelta. Forse questa
suddivisione andava bene ai tempi delle schede perforate perche' alla fine
chi andava a perforare le schede non doveva necessariamente conoscerne la
struttura (anche se doveva comunque farlo con perizia). Da allora la
teoria e la pratica si sono evoluti un pochino.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 label o altro, brrrrrrrrr.
Nessuno mette in dubbio che ci possano essere intermediazioni inutili o 
figure incompetenti, ma per fare bene un programma ci vuole sia la 
comprensione del dominio che la realizzazione tecnica. Magari tu avevi 
entrambe le competenze e la figura ulteriore era superflua, ma questo 
non vuol dire che sia sempre così. Se lavori in un progetto di un certo 
livello può darsi benissimo che tu sia messo a lavorare su un argomento 
di cui non ne sai abbastanza da evitare un arrosto.

I commenti nei sorgenti di linux :)
root@harem:/usr/src/linux# grep -ri fuck *
Documentation/DocBook/kernel-locking.tmpl:       If you don't see why,
please stay the fuck away from my code.
Documentation/DocBook/kernel-locking.tmpl:    <title>The Fucked Up
Sparc</title>
arch/ppc/kernel/ppc405_pci.c:	 * the kernel try to remap our BAR #1 and
fuck up bus
arch/i386/kernel/mtrr.c:/*  Some BIOS's are fucked and don't set all
MTRRs the same!  */
arch/mips/kernel/irixioctl.c: * irixioctl.c: A fucking mess...
arch/mips/kernel/irixelf.c:#if 0 /* XXX No fucking way dude... */
arch/mips/sgi-ip22/ip22-setup.c:	 * fucking with the memory controller
because it needs to know the
arch/sparc/kernel/ptrace.c:/* Fuck me gently with a chainsaw... */
arch/sparc/kernel/head.S:	/* XXX Fucking Cypress... */

 
Nooooo, ma non volevo dire cio', scusa mi sono espresso male. COmunque il 
consulente serviva perche' andava dove io non avevo il tempo, pero' 
riferiva il problema non pianificava l'intervento. Altri invece pianificano 
dalla A alla Z l'intervento, infatti ho visto analisti specificare ogni 
cosa ai programmatori che alla fine vedevano ridotto al minimo il loro 
apporto all'implementazione. Ma non era mica una polemica. 
Io ora voglio passare dall'altra parte e dire agli altri cosa devono fare e 
poi rompere anche i coglioni "Allora e' pronto il nuovo software per 
gestire le FS di cui ti ho parlato stamattina ???"
-- 
Federico

testare il mio stesso codice...)
Amen fratello.
Purtroppo la realta' e' diversa dalla teoria :(
C'ya
	STeve
-- 
Legge di Flon
Non c'e' linguaggio in cui sia difficile scrivere cattivi programmi.
FAQ del gruppo : 
http://www.sen.it/faq/it.lavoro.informatica.faq.html
 
http://www.duestrade.it/HOWTO_leggere_annunci.html
 
http://www.duestrade.it/HOWTO_mettere_annunci.html
   --- 
sbo...@despammed.com
 ---

 Purtroppo la realta' e' diversa dalla teoria :(
tu pensa che una volta ero talmente abituato a vedere la gui web che stavo 
sviluppando che testandola non mi sono accorto (ce l'avevo sempre lě sotto 
gli occhi...) che la textbox della password aveva i caratteri in chiaro e 
non come asterischi... sono andato cosě a fare la consegna dal cliente :-S 
(ovviamente il cliente se n'č accorto dopo i primi due microsecondi)
insomma, vedi una cosa tutti i giorni e ti diventa familiare tanto da 
diventare parte dello sfondo...
saluti
Roberto 

diventare parte dello sfondo...
Gia', la ragione principe per cui chi sviluppa non dovrebbe mai
testare il codice che scrive.
Anche la documentazione andrebbe scritta da qualcuno diverso
dall'analista/programmatore.
Luca non sei il solo che la odia :-)
Ma specie se la realta' lavorativa e' piccola ti tocca fare di tutto,
spesso anche contattare il cliente :-)
E fare assistenza.
Di positivo c'e' che impari a fare tante cose :)


 coder che dovesse fare successiva manutenzione.
Beh come programma non te lo so dire lei e' della vecchia scuola, quella 
prima della mia mi pare lavorasse in cobol e pascal ora non programma 
piu' da tempo, magari una volta si faceva cosi ora non piu'.
Cmq io resto della mia idea che se il codice e' commentato e' meglio, 
appunto perche' se un altro ci lavora magari capisce prima perche' hai 
scelto quella soluzione di codice.
In soldoni lei disse che l'analista prepara il malloppone guida e il 
coder scrive il codice ma non il commento a cio' io sbottai...
ma come lavorate male in ibm... non mi stupisce che abbiate un server
su un pentium 1 da 133 con un solo hd :-D ( ma questa e' un altra storia 
  :-D )

 :))
uh! forse si, la memoria non aiuta piu' :-D

 siamo su un NG di informatica o di abbinamento di colori di slip e calze ?
Scusa ma vuoi proprio che ti risponda?
Cortesemente leggi anche il resto del thread perche' altrimenti potrei 
diventare offensivo e forse volgare.

 sparsi in giro, alla M$ sono ancora piu cialtroni del previsto.
Ma sinceramente non so neanche io cosa mi aspettavo, navigo nel mare 
dell'ingoranza della progammazione, l'intenzione di imparare il c e' 
sempre piu' forte ma finche' riesco ad iniziare... :-(
Non so dirti se sono cialtroni alla micromorbida oppure no, non ne ho le 
conoscenze per asserirlo, di certo visto le rogne che quotidianamente
combatto con il loro sistema la propensione e' quella :-D

 lunga da dare qui
#13 Real programmer never comment: the code is obvious
(da una mitica serie di tag in Fidonet) :-D

almeno prima di aver studiato per alcuni esami)
Per essere architetto/analista  io aggiungerei :
Aver fatto manutenzione  (come coder) a progetti con architetture
sbagliate.
Aver visto almeno 2 - 3 grossi sistemi e averci lavorato
Aver sperimentato il rapporto con il cliente
Aver studiato BENE architettura e caratteristiche del
linguaggio/sistema che si andrà ad utilizzare
e 2 - 3 anni di esperienza nel settore....
Dimenticavo.. senza un runaway project nel curriculum, dovrebbe proprio
essere impedito
di fare l'analista o l'architetto !
PS:  discorso diverso per l'analista puro di una volta.. quelli che
sanno come funziona uno sportello bancario, non gli interessa
particolarmente come sarà realizzato o le maschere.. però conoscono
gli adempimenti di legge, tutte le procedure e COSA deve fare il
sistema e perchè.. ma questi esistevano una volta e sapevano il fatto
loro..