Newsgroup: it.lavoro.informatica
Titolo: Discussioni con colleghi programmatori...

Premessa: oggi il capo non c'è.
Discussione: il software è sufficiente che funzioni o il fatto che sia 
anche scritto bene ed ottimizzato non è da mettere in secondo piano?
Tutti i miei colleghi sono per il "funzionare", io invece, tranne i casi 
di fretta, alloco sempre un po di tempo per scrivere il codice il meglio 
possibile (anche per i posteri). E come è oggi capitato, non per la 
prima volta, ho fatto correzioni estetico/prestazionali a codice fatto 
da altri.
Beh... Mi son preso del rompic*****... Fa niente, sono "corazzato" e 
penso di essere nel giusto, anche con 11 anni di esperienza di 
programmazione in team.
Che ne pensate?
-- 
______________________________________
Luc (31, CO, VC++ Programmer)
Editorial Systems Software development
______________________________________

 wrote in message
news:MPG.1b4f76ccc...@tornado.fastwebnet.it...
Tutti i miei colleghi sono per il "funzionare", io invece, tranne i casi
di fretta, alloco sempre un po di tempo per scrivere il codice il meglio
possibile (anche per i posteri).
Anche io, esattamente come te. Se  non ho particolari problemi di
tempistiche cerco sempre di apportare migliorie al codice.
E come è oggi capitato, non per la
prima volta, ho fatto correzioni estetico/prestazionali a codice fatto
da altri.
Non dovresti farlo in questo modo la differenza tra i due codici sarà
lampante.. :-)
G.M.


Chiedo venia ho quotato di m...a. :-)
G.M.


http://csvtosql.sourceforge.net/

 
aggiungo:
se scrivi del codice modulare sarà più facile fare refactoring.


 però senza farsi troppe seghe mentali.
Il problema è che quando lavori in team, se c'è una gamba corta, anche 
le altre poi zoppicano...


Cazz, mi trovo d'accordo con te, anche se la cosa mi preoccupa ;). Credo
che tutto ciò che è ordinato sia migliore, che non bisogna estremizzare
le cose ma che sia serio pretendere che chi è per il "basta che funzioni"
sia messo in una gogna in sala server. 
Inoltre i costi di refactoring o di modifiche grosse all'applicativo sono
quasi uguali a quelli di sviluppo, se le cose son fatte alla "basta che
funziona"... (vogliamo dire alla cazzo di cane? e diciamolo su :P)

 anche scritto bene ed ottimizzato non è da mettere in secondo piano?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

senza polemica con chi fa le cose fatte bene
coi commenti o quantaltro ..


senza polemica con chi fa le cose fatte bene
coi commenti o quantaltro ..
-- 


senza polemica con chi fa le cose fatte bene
coi commenti o quantaltro ..
-- 


 le altre poi zoppicano...
è vero, poi il casino è quando ci sono discordanze di stile ... :) :)


>Che ne pensate?
Secondo me i tuoi colleghi non sono granchè.
Però a discolpa di quelli che non sono granchè bisogna ricordarsi delle
"perle ai porci": delle volte abbiamo quello che ci meritiamo, con
corrispondenza biunivoca (azienda caccolosa vuole personale caccoloso,
personale caccoloso finisce per imbucarsi in aziende caccolose, personale
caccoloso fa diventare l'azienda caccolosa, azienda caccolosa finisce per
invogliare il personale alla caccolosità).
Mio papà dice che un lavoro fatto bene porta via lo stesso tempo di un
lavoro fatto male. Però c'è un sacco di gente che pensa diversamente.
Insomma: è un problema con così tante sfaccettature che alla fine penso che
la cosa migliore sia attenersi al proprio "code of conduct", specialmente se
in linea di principio si è nel giusto.
E magari cercare in giro un posto di lavoro (boss, colleghi) che apprezzino
queste virtù. (è assai frustrante arrivare a pensare che "non c'è gusto qui
ad essere intelligenti").
F.B.

 queste virtù.
A beh, per questo sono in una botte di ferro. Il ns. titolare, anche lui 
programmatore, è irraggiungibile per purezza di codice... Ne deduco 
quindi che lo apprezza dai suoi dipendenti (ma non chiamatemi lecchino!)
;)
PS: ho appena convinto il mio collega di fronte a eliminare 4 pagine di 
codice duplicato in tre classi diverse facendone una in più comune...
:-OOO


 Cazz, mi trovo d'accordo con te
Perchè non si parla di politica, semplice! 


 anche scritto bene ed ottimizzato non è da mettere in secondo piano?
Allora mi e' successo di coordinare 5 programmatori nuovi, previo 
insegnamento, per poi farli lavorare sul nostro gestionale e sulle 
eventuali verticalizzazione da fare ai clienti. 
Bene ipotizzando che dopo due anni (cosa che assolutamente non si e' 
verificata) i loro programmi almeno funzionassero erano lo stesso uno 
schifo, perche'? Perche se uno stava ammalato una settimana e sorgeva un 
problema su un programma fatto da uno di questi personaggi o nasceva la 
necessiata di fare un'implementazione, c'era da avere paura a metterci le 
mani perche' era tale la confusione, il disordine, che si finiva con il 
fare un bel po di danni prima di raggiungere l'obbiettivo. Mentre con gli 
altri tre colleghi che ho se dobbiamo modificarci a videnca i programmi 
lo possiamo fare con un certa tranquillita', perche' i sorgenti sono 
ordinati e facilmente comprensibili e quindi facilmente modificabili.
Bene ora questi personaggi con il tempo sono stati tutti licenziati, e a 
turno quando devo prendere in mano uno di questi programmi perche' c'e' 
da fare ad esempio una qualche modifica arrivo per disperazione e 
disgusto a rifarli di peso. Tre di questi erano laureati ... 
Quindi io sono per anche per un certo ordine e leggibilita' del 
codice ... Perche' ci sono molti vantaggi operativi e non solo estetici 
che non si possono trascurare ... Ad esempio mi e' capitato di rifare un 
programma di 2000-2500 righe e ridurlo di 700 righe facendogli fare le 
stesse cose e togliendo i bug fate voi .....
Ciao a tutti.
--
Federico
Inviato da 
www.mynewsgate.net

 
Non sarai mica un troll????
Non sarai mica un troll????
Non sarai mica un troll????


> Non sarai mica un troll????
che e' un troll ?


 lavoro fatto male. Però c'è un sacco di gente che pensa diversamente.
Io sono d'accordo con te e con tuo padre :) Non e' che ad essere ordinati 
e leggibili impieghi di piu', anzi , secondo me quando hai un certo 
standard di lavoro viaggi come una scheggia perche' scrivi meno codice e 
piu' facilmente modificabile quindi in realta' hai un risparmio di 
tempo...


 Ciao a tutti.
Concordo con opinioni e fatti da te descritti... ;)



Penso che vorrei avere la fortuna di lavorare soltanto
con gente che ragiona esattamente come te... ti capisco.
Anche per me è una lotta continua, e forse è pure persa in
partenza perchè è quasi impossibile cambiare il modo "schifoso"
di lavorare di alcuni altri "professionisti".

 
ripenso con orrore a quando trovai del codice che stampato (con pochi spazi
tra le linee) conteneva un funzione di 4.5 metri di lunghezza....
non fui per nulla contentodi doverci metter mano...
brr...
Ciao

 
Allora lo diventerai .... vedo del talento .


programmazione in team.
Beh sai, prima di tutto occorre capire bene cosa si intende per scrivere
bene il codice.
Certamente se tutto si tratta di "stile di scrittura" la cosa e' auspicabile
ma non e' realistica... non e' realistica perche' non ci sono i tempi per
farlo e perche' e' meglio fissare due o tre punti fermi e basta
(indentazione, etc.) perche' quando le scadenze arrivano si tende, appunto,
a fare funzionare il tuttoe a consegnare il lavoro.
Mentre se per ottima scrittura del codice intendi una ottima strutturazione
li' la cosa non solo e' auspicabile, ma e' fondamentale altrimenti non
avrebbe senso usare un linguaggio piuttosto che un altro. In pratica se usi
un linguaggio ad oggetti e poi strutturi male le classi e non utilizzi
l'incapsulamento, l'ereditarieta' e balle varie allora si poteva usare anche
Cobol. Se usi un pattern MVC e poi mischi i livelli e cabli il codice di un
livello in un altro, allora si poteva fare tutto in CGI. Tanto il tutto
funzionerebbe sia in un linguaggio che in un altro.
Scrivere bene il codice deriva da una forte formazione teorica, dietro alla
quale opera la pratica. Ma quanti si preoccupano di imparare la teoria e poi
la pratica? E' uso comune prendere il manuale e iniziare a smanettare,
imparando cosi'. Se uno ha imparato a copiare il codice, a compilare e ad
aspettarsi che tutto funzioni, e' giusto che questa forma mentis la abbia
anche dopo.
La differenza tra Programmatore e Analista-Programmatore e' tutta qui. Il
Programmatore scrive codice e si aspetta che funzioni,
l'Analista-Programmatore scrive codice, analizza la forma migliore e prende
delle scelte. E' un piccolo salto, ma fondamentale.

 cosi' si scrive in fretta e si produce esattamente il doppio
immagino le porcherie


 
non e' che avanzi posto da te?
-- 
piero

 
Concordo ma i soldi per ritestare il software ce li metti tu?
-- 
--------------------------------------------------------------------
Non system disk or disk error, replace and strike any key when ready
--------------------------------------------------------------------

 [CUT]
Almeno, e ripeto almeno, che sia leggibile, strutturato decentemente e 
assolutamente privo di codice "duplicato"... Che vengano applicati i 
design-pattern alla lettera, importa di meno nelle normali situazioni.


 Concordo ma i soldi per ritestare il software ce li metti tu?
In che senso "ritestare"? 


 
Si devono fare dei test di non regressione dopo le 'ottimizzazioni', che 
sono comunque delle modifiche che possono portare a nuovi bug, non trovi?


 sono comunque delle modifiche che possono portare a nuovi bug, non trovi?
A beh, certo. Però se inizi già a sviluppare pensando anche alla qualità 
del codice, le cose andranno via più liscie... 
