Kralizek
07-06-2010, 08:13
Oggi ho riaperto un pezzo di codice che avevo scritto tempo fa ed ho avuto la sensazione di vedere un roseto potato con una trebbiatrice... é il caso che lo faccio notare?
View Full Version : [OT: Rapporti sociali] - Vita d'ufficio
cdimauro
07-06-2010, 08:18
Beh, quando capita io lo faccio. Lo sanno anche i muri, in ufficio, che disprezzo il mio vecchio codice. :D
Appena devo rimetterci mano per qualche aggiornamento ne approfitto per rifattorizzarlo o, eventualmente, riscriverlo.
Ad esempio, è da un paio di settimane che sto ristrutturando l'intero codice di un progetto che è in produzione, ma che continua a subire modifiche a causa di nuovi requisiti. E siccome mi sono stancato di prendere pali (visto che sono soltanto un pezzo di una "catena di montaggio", e per fare dei test seri dovrei scomodare tutti gli altri pezzi; cosa alquanto difficile), mi sono preso il tempo che mi serve e sto passando tutto alla TDD (http://en.wikipedia.org/wiki/Test-driven_development). Adesso sono MOLTO più sereno. :)
Appena devo rimetterci mano per qualche aggiornamento ne approfitto per rifattorizzarlo o, eventualmente, riscriverlo.
Ad esempio, è da un paio di settimane che sto ristrutturando l'intero codice di un progetto che è in produzione, ma che continua a subire modifiche a causa di nuovi requisiti. E siccome mi sono stancato di prendere pali (visto che sono soltanto un pezzo di una "catena di montaggio", e per fare dei test seri dovrei scomodare tutti gli altri pezzi; cosa alquanto difficile), mi sono preso il tempo che mi serve e sto passando tutto alla TDD (http://en.wikipedia.org/wiki/Test-driven_development). Adesso sono MOLTO più sereno. :)
shinya
07-06-2010, 09:12
Oggi ho riaperto un pezzo di codice che avevo scritto tempo fa ed ho avuto la sensazione di vedere un roseto potato con una trebbiatrice... é il caso che lo faccio notare?
Personalmente ho smesso di lamentarmi del codice già scritto. Dopo un pò ho imparato che nella quotidianità del lavoro non puoi mai sapere perchè un certo pezzo di codice sia scritto nella maniera in cui è scritto.
Anche quelli bravi scrivono codice di merda, a volte.
Non è un comportamento dovuto all'incapacità, ma in un mondo di deadline, analisi di requisiti discordanti, utenti schizofrenici, cambi progetto, riunioni, strumenti di sviluppo inadeguati, "standard" aziendali che dopo 6 mesi sono obsoleti, ecc, ecc... non puoi sapere perchè quel pezzo di codice sia scritto cosi.
Purtroppo non si riesce sempre a scrivere codice elegante, per svariati motivi che non dipendono dall'individuo, ma dall'ambiente. Quello che si fa sul lavoro, comunemente, è piuttosto lontanto dall'arte della programmazione. Il refactoring in certi casi lo puoi fare se il cliente te lo paga. O se hai tempo libero, e non ti hanno spostato ad altri progetti.
In conclusione: non me ne uscirei con un "OMG! WTF iz this CRAP!??!?!111"... ma magari con un "Penso che questo pezzo possa essere strutturato in maniera più flessibile e performante."
My 2 centz.
Personalmente ho smesso di lamentarmi del codice già scritto. Dopo un pò ho imparato che nella quotidianità del lavoro non puoi mai sapere perchè un certo pezzo di codice sia scritto nella maniera in cui è scritto.
Anche quelli bravi scrivono codice di merda, a volte.
Non è un comportamento dovuto all'incapacità, ma in un mondo di deadline, analisi di requisiti discordanti, utenti schizofrenici, cambi progetto, riunioni, strumenti di sviluppo inadeguati, "standard" aziendali che dopo 6 mesi sono obsoleti, ecc, ecc... non puoi sapere perchè quel pezzo di codice sia scritto cosi.
Purtroppo non si riesce sempre a scrivere codice elegante, per svariati motivi che non dipendono dall'individuo, ma dall'ambiente. Quello che si fa sul lavoro, comunemente, è piuttosto lontanto dall'arte della programmazione. Il refactoring in certi casi lo puoi fare se il cliente te lo paga. O se hai tempo libero, e non ti hanno spostato ad altri progetti.
In conclusione: non me ne uscirei con un "OMG! WTF iz this CRAP!??!?!111"... ma magari con un "Penso che questo pezzo possa essere strutturato in maniera più flessibile e performante."
My 2 centz.
Kralizek
07-06-2010, 09:38
rileggendo l'OP mi sa che non ho reso l'idea, il problema é che un altro collega ha messo le mani su questa pagina é l'ha distrutta scrivendo codice molto poco performante (oltre che sporco)
per la serie: io ero il giardiniere che aveva tirato su il roseto, e questo collega era il contandino su trebbiatrice :P
per la serie: io ero il giardiniere che aveva tirato su il roseto, e questo collega era il contandino su trebbiatrice :P
shinya
07-06-2010, 09:42
rileggendo l'OP mi sa che non ho reso l'idea, il problema é che un altro collega ha messo le mani su questa pagina é l'ha distrutta scrivendo codice molto poco performante (oltre che sporco)
per la serie: io ero il giardiniere che aveva tirato su il roseto, e questo collega era il contandino su trebbiatrice :P
Si io avevo capito proprio cosi.
Vale sempre il discorso che ho fatto, puoi far notare la cosa in maniera 'polite' :)
per la serie: io ero il giardiniere che aveva tirato su il roseto, e questo collega era il contandino su trebbiatrice :P
Si io avevo capito proprio cosi.
Vale sempre il discorso che ho fatto, puoi far notare la cosa in maniera 'polite' :)
cdimauro
07-06-2010, 09:42
In tal caso... a morte il contadino. :D
Ryuzaki_Eru
07-06-2010, 10:01
E siccome mi sono stancato di prendere pali (visto che sono soltanto un pezzo di una "catena di montaggio", e per fare dei test seri dovrei scomodare tutti gli altri pezzi; cosa alquanto difficile), mi sono preso il tempo che mi serve e sto passando tutto alla TDD (http://en.wikipedia.org/wiki/Test-driven_development). Adesso sono MOLTO più sereno. :)
Ero scettico riguardo al TDD. Poi ho dovuto impararlo per partecipare ad un progetto e mi sono dovuto ricredere. Magari può prendere tempo per scrivere i test, ma poi vivi tranquillo :D
Ero scettico riguardo al TDD. Poi ho dovuto impararlo per partecipare ad un progetto e mi sono dovuto ricredere. Magari può prendere tempo per scrivere i test, ma poi vivi tranquillo :D
vladix
07-06-2010, 11:22
In tal caso... a morte il contadino. :D
voto unanime :D
PS: un pezzettino di codice trovato su una delle applicazioni che sto modificando :D
logger.debug("sono dentroooooooooooooooooooo"); // oooh siii ... che goduria
voto unanime :D
PS: un pezzettino di codice trovato su una delle applicazioni che sto modificando :D
logger.debug("sono dentroooooooooooooooooooo"); // oooh siii ... che goduria
Ryuzaki_Eru
07-06-2010, 11:53
Non ci credo :asd:
Kralizek
07-06-2010, 11:56
:eek:
marco.r
07-06-2010, 17:12
:eek:
Nei momenti di maggiore tensione si scrivono queste ed altre perle.
Tipo
void merda()
{
...
}
oppure
printf("Ma che oooooh...\n"); // se non bestemmio stavolta...
cose temporanee che in teoria non dovrebbero vedere neanche il tramonto, ma che a volte in modi misteriosi finiscono pure nel repository :mbe:.
Piccolo OT visto che si parla di cose che restano oltre il dovuto... Una volta ho preparato una macchina per un collega (diciamo Pinco). ho messo una password temporanea e per essere sicuro che la cambiasse ho scelto "PincoStupido". "Cosi' sono sicuro che la cambi quanto prima".
E' ancora li'...
Nei momenti di maggiore tensione si scrivono queste ed altre perle.
Tipo
void merda()
{
...
}
oppure
printf("Ma che oooooh...\n"); // se non bestemmio stavolta...
cose temporanee che in teoria non dovrebbero vedere neanche il tramonto, ma che a volte in modi misteriosi finiscono pure nel repository :mbe:.
Piccolo OT visto che si parla di cose che restano oltre il dovuto... Una volta ho preparato una macchina per un collega (diciamo Pinco). ho messo una password temporanea e per essere sicuro che la cambiasse ho scelto "PincoStupido". "Cosi' sono sicuro che la cambi quanto prima".
E' ancora li'...
RaouL_BennetH
07-06-2010, 17:46
Nei momenti di maggiore tensione si scrivono queste ed altre perle.
Tipo
void merda()
{
...
}
oppure
printf("Ma che oooooh...\n"); // se non bestemmio stavolta...
cose temporanee che in teoria non dovrebbero vedere neanche il tramonto, ma che a volte in modi misteriosi finiscono pure nel repository :mbe:.
Piccolo OT visto che si parla di cose che restano oltre il dovuto... Una volta ho preparato una macchina per un collega (diciamo Pinco). ho messo una password temporanea e per essere sicuro che la cambiasse ho scelto "PincoStupido". "Cosi' sono sicuro che la cambi quanto prima".
E' ancora li'...
[imbarazzatissimo mode on]
io sono uno dei contadini :(
alle volte nelle mie porzioni di codice puoi trovare cose del genere:
//ci riesco stavolta a far venir fuori la lista ?
private IList HowTheHellReturnThisList(....)
{
.....
}
[imbarazzatissimo mode off]
:(
Oppure catturo delle eccezioni facendomi restituire solo un "ASD", e ne metto così tante che poi
non capisco più a chi "ASD" si riferisce....
Tipo
void merda()
{
...
}
oppure
printf("Ma che oooooh...\n"); // se non bestemmio stavolta...
cose temporanee che in teoria non dovrebbero vedere neanche il tramonto, ma che a volte in modi misteriosi finiscono pure nel repository :mbe:.
Piccolo OT visto che si parla di cose che restano oltre il dovuto... Una volta ho preparato una macchina per un collega (diciamo Pinco). ho messo una password temporanea e per essere sicuro che la cambiasse ho scelto "PincoStupido". "Cosi' sono sicuro che la cambi quanto prima".
E' ancora li'...
[imbarazzatissimo mode on]
io sono uno dei contadini :(
alle volte nelle mie porzioni di codice puoi trovare cose del genere:
//ci riesco stavolta a far venir fuori la lista ?
private IList HowTheHellReturnThisList(....)
{
.....
}
[imbarazzatissimo mode off]
:(
Oppure catturo delle eccezioni facendomi restituire solo un "ASD", e ne metto così tante che poi
non capisco più a chi "ASD" si riferisce....
Ryuzaki_Eru
07-06-2010, 18:43
Quella di Raoul è geniale, soprattuto la parte degli asd....:asd:
cdimauro
07-06-2010, 19:55
Ero scettico riguardo al TDD. Poi ho dovuto impararlo per partecipare ad un progetto e mi sono dovuto ricredere. Magari può prendere tempo per scrivere i test, ma poi vivi tranquillo :D
Ne prende abbastanza, ma è tutto tempo ripagato: te ne accorgi dopo, non appena fai qualche modifica e c'è qualche test che fallisce segnalandoti che hai fatto una cazzata.
In pratica s'investe già in fase di sviluppo per quella di test. Con l'indiscutibile vantaggio di ritrovarti con una test case che puoi usare sempre a fine sviluppo, ma soprattutto con un sistema molto più solido.
PS: un pezzettino di codice trovato su una delle applicazioni che sto modificando :D
logger.debug("sono dentroooooooooooooooooooo"); // oooh siii ... che goduria
:rotfl: Questa è da antologia. :asd:
Ne prende abbastanza, ma è tutto tempo ripagato: te ne accorgi dopo, non appena fai qualche modifica e c'è qualche test che fallisce segnalandoti che hai fatto una cazzata.
In pratica s'investe già in fase di sviluppo per quella di test. Con l'indiscutibile vantaggio di ritrovarti con una test case che puoi usare sempre a fine sviluppo, ma soprattutto con un sistema molto più solido.
PS: un pezzettino di codice trovato su una delle applicazioni che sto modificando :D
logger.debug("sono dentroooooooooooooooooooo"); // oooh siii ... che goduria
:rotfl: Questa è da antologia. :asd:
DanieleC88
07-06-2010, 20:14
io sono uno dei contadini :(
:eek:
:eek:
minerte
07-06-2010, 20:57
bhe a volte per tempi di consegna strettissimi sono "necessari"...purtroppo le basi dell'ingegneria del software mancano...ma non ha chi struttura/scrive il codice ma al cliente....vaglielo a spiegare che magari allungando la consegna potresti scrivere un codice più pulito facile da manutenere etc etc.... ma c'è anche il discorso più manutanzione => più lavoro.
Bhe io ho imparato il detto dell'antico programmatore cinese
"non toccare codice che funziona"
Infatti attualmente nel "mio" progetto c'è una classe di 5800 righe (:muro: :muro: :muro: ) che gestisce metà "applicazione" (penso che chi l'abbia scritta venisse della programmazione procedurale) a cui non farei il refactoring nemmeno con la pistola puntata contro......
Bhe io ho imparato il detto dell'antico programmatore cinese
"non toccare codice che funziona"
Infatti attualmente nel "mio" progetto c'è una classe di 5800 righe (:muro: :muro: :muro: ) che gestisce metà "applicazione" (penso che chi l'abbia scritta venisse della programmazione procedurale) a cui non farei il refactoring nemmeno con la pistola puntata contro......
cdimauro
07-06-2010, 21:17
Io, invece, ho una generale tendenza alla rifattorizzazione (sono malato: aiutatemi!!! :cry:).
Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.
Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.
Albitexm
07-06-2010, 21:26
rileggendo l'OP mi sa che non ho reso l'idea, il problema é che un altro collega ha messo le mani su questa pagina é l'ha distrutta scrivendo codice molto poco performante (oltre che sporco)
per la serie: io ero il giardiniere che aveva tirato su il roseto, e questo collega era il contandino su trebbiatrice .
E' il caso che lo faccia notare?:P
Dipende tutto dalla posizione di potere che ha il "contadino" nella tua azienda.
Insomma il peso e il rapporto che ha con te e con le alte sfere, questo "trebbiatore".
In azienda non c'è democrazia..
per la serie: io ero il giardiniere che aveva tirato su il roseto, e questo collega era il contandino su trebbiatrice .
E' il caso che lo faccia notare?:P
Dipende tutto dalla posizione di potere che ha il "contadino" nella tua azienda.
Insomma il peso e il rapporto che ha con te e con le alte sfere, questo "trebbiatore".
In azienda non c'è democrazia..
minerte
07-06-2010, 22:20
Io, invece, ho una generale tendenza alla rifattorizzazione (sono malato: aiutatemi!!! :cry:).
Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.
ma per me il problema e sempre quello economico....
Se ci troviamo in un progetto open o personale io lo farei sempre....
ma in un progetto "closed" e "legacy" dove magari la logica che gestisce e contorta(dalle varie modifiche negli ) ma "funziona" ti conviene(se non per reali esigenze), sia in termini di tempo che economici fare un reverse engineering per capirne il funzionamento e rischiare?
Tutto quello che ho detto è contrario a ciò che ho studiato, ma da quello che ho sempre visto le cose vanno cosi......
Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.
ma per me il problema e sempre quello economico....
Se ci troviamo in un progetto open o personale io lo farei sempre....
ma in un progetto "closed" e "legacy" dove magari la logica che gestisce e contorta(dalle varie modifiche negli ) ma "funziona" ti conviene(se non per reali esigenze), sia in termini di tempo che economici fare un reverse engineering per capirne il funzionamento e rischiare?
Tutto quello che ho detto è contrario a ciò che ho studiato, ma da quello che ho sempre visto le cose vanno cosi......
^TiGeRShArK^
07-06-2010, 22:35
ma per me il problema e sempre quello economico....
Se ci troviamo in un progetto open o personale io lo farei sempre....
ma in un progetto "closed" e "legacy" dove magari la logica che gestisce e contorta(dalle varie modifiche negli ) ma "funziona" ti conviene(se non per reali esigenze), sia in termini di tempo che economici fare un reverse engineering per capirne il funzionamento e rischiare?
Tutto quello che ho detto è contrario a ciò che ho studiato, ma da quello che ho sempre visto le cose vanno cosi......
è dimostrato che il continuous refactoring migliora la qualità del codice e a lungo andare DIMINUISCE i costi.
Se non si rifattorizza costantemente il codice la complessità per effettuare una modifica cresce esponenzialmente e di conseguenza anche il costo per il cliente.
TDD e continuous refactoring sono le basi per avere una buona codebase e per mantenere i costi di sviluppo costanti.
Se ci troviamo in un progetto open o personale io lo farei sempre....
ma in un progetto "closed" e "legacy" dove magari la logica che gestisce e contorta(dalle varie modifiche negli ) ma "funziona" ti conviene(se non per reali esigenze), sia in termini di tempo che economici fare un reverse engineering per capirne il funzionamento e rischiare?
Tutto quello che ho detto è contrario a ciò che ho studiato, ma da quello che ho sempre visto le cose vanno cosi......
è dimostrato che il continuous refactoring migliora la qualità del codice e a lungo andare DIMINUISCE i costi.
Se non si rifattorizza costantemente il codice la complessità per effettuare una modifica cresce esponenzialmente e di conseguenza anche il costo per il cliente.
TDD e continuous refactoring sono le basi per avere una buona codebase e per mantenere i costi di sviluppo costanti.
cdimauro
08-06-2010, 04:55
ma per me il problema e sempre quello economico....
Se ci troviamo in un progetto open o personale io lo farei sempre....
ma in un progetto "closed" e "legacy" dove magari la logica che gestisce e contorta(dalle varie modifiche negli ) ma "funziona" ti conviene(se non per reali esigenze), sia in termini di tempo che economici fare un reverse engineering per capirne il funzionamento e rischiare?
Tutto quello che ho detto è contrario a ciò che ho studiato, ma da quello che ho sempre visto le cose vanno cosi......
Io, almeno per ora, ho la fortuna di lavorare a codice mio. E a me piace avere il codice bello, sistemato e in ordine (secondo i miei "gusti"). In ufficio un mio collega mi chiama "l'esteta del codice". :asd:
è dimostrato che il continuous refactoring migliora la qualità del codice e a lungo andare DIMINUISCE i costi.
Se non si rifattorizza costantemente il codice la complessità per effettuare una modifica cresce esponenzialmente e di conseguenza anche il costo per il cliente.
TDD e continuous refactoring sono le basi per avere una buona codebase e per mantenere i costi di sviluppo costanti.
Ma poi, come dicevi tu, la rifattorizzazione aiuta a mantenere la codebase; specialmente in combinazione con la TDD: ti vedi il codice trasformare senza che nemmeno te ne accorgi; è un po' difficile da spiegare, ma è come se ti portasse in maniera naturale ad averlo strutturato, pulito e ben sistemato.
Se ci troviamo in un progetto open o personale io lo farei sempre....
ma in un progetto "closed" e "legacy" dove magari la logica che gestisce e contorta(dalle varie modifiche negli ) ma "funziona" ti conviene(se non per reali esigenze), sia in termini di tempo che economici fare un reverse engineering per capirne il funzionamento e rischiare?
Tutto quello che ho detto è contrario a ciò che ho studiato, ma da quello che ho sempre visto le cose vanno cosi......
Io, almeno per ora, ho la fortuna di lavorare a codice mio. E a me piace avere il codice bello, sistemato e in ordine (secondo i miei "gusti"). In ufficio un mio collega mi chiama "l'esteta del codice". :asd:
è dimostrato che il continuous refactoring migliora la qualità del codice e a lungo andare DIMINUISCE i costi.
Se non si rifattorizza costantemente il codice la complessità per effettuare una modifica cresce esponenzialmente e di conseguenza anche il costo per il cliente.
TDD e continuous refactoring sono le basi per avere una buona codebase e per mantenere i costi di sviluppo costanti.
Ma poi, come dicevi tu, la rifattorizzazione aiuta a mantenere la codebase; specialmente in combinazione con la TDD: ti vedi il codice trasformare senza che nemmeno te ne accorgi; è un po' difficile da spiegare, ma è come se ti portasse in maniera naturale ad averlo strutturato, pulito e ben sistemato.
WarDuck
08-06-2010, 07:11
Come diceva il mio professore di fisica alle superiori:
L'eleganza è tutto.
:asd:
Certo è che se qualcuno mette le mani nel mio codice non so se potrei rispondere di me stesso :asd:
L'eleganza è tutto.
:asd:
Certo è che se qualcuno mette le mani nel mio codice non so se potrei rispondere di me stesso :asd:
tomminno
08-06-2010, 07:44
è dimostrato che il continuous refactoring migliora la qualità del codice e a lungo andare DIMINUISCE i costi.
Se non si rifattorizza costantemente il codice la complessità per effettuare una modifica cresce esponenzialmente e di conseguenza anche il costo per il cliente.
TDD e continuous refactoring sono le basi per avere una buona codebase e per mantenere i costi di sviluppo costanti.
E' vero ma pensa ad un codice legacy, ovviamente parti da una base senza TDD, devi apportare delle modifiche con tempi di rilascio di 1 settimana o al massimo 2 appena appena sufficienti a scrivere il codice necessario alla modifica, figuriamoci alla scrittura di test anche minimamente completi sulla parte modificata.
Non avrai mai il tempo di rifattorizzare nè tanto meno scrivere dei TDD e così di anno in anno la storia si ripete il software fa sempre più schifo, ma il tempo per prendersi una pausa di riflessione e cominciare a risistemarlo non ce l'hai mai.
Se non si rifattorizza costantemente il codice la complessità per effettuare una modifica cresce esponenzialmente e di conseguenza anche il costo per il cliente.
TDD e continuous refactoring sono le basi per avere una buona codebase e per mantenere i costi di sviluppo costanti.
E' vero ma pensa ad un codice legacy, ovviamente parti da una base senza TDD, devi apportare delle modifiche con tempi di rilascio di 1 settimana o al massimo 2 appena appena sufficienti a scrivere il codice necessario alla modifica, figuriamoci alla scrittura di test anche minimamente completi sulla parte modificata.
Non avrai mai il tempo di rifattorizzare nè tanto meno scrivere dei TDD e così di anno in anno la storia si ripete il software fa sempre più schifo, ma il tempo per prendersi una pausa di riflessione e cominciare a risistemarlo non ce l'hai mai.
minerte
08-06-2010, 07:53
è dimostrato che il continuous refactoring migliora la qualità del codice e a lungo andare DIMINUISCE i costi.
Se non si rifattorizza costantemente il codice la complessità per effettuare una modifica cresce esponenzialmente e di conseguenza anche il costo per il cliente.
TDD e continuous refactoring sono le basi per avere una buona codebase e per mantenere i costi di sviluppo costanti.
Si hai perfettamente ragione, quello che dici è scritto anche in tutti i manuali di ingegneria del software ..... ma riesci a farlo capire al cliente?
Se non riesci a far capire che se una persona ci impiega 100 giorni ad effettuare un lavoro, 2 non c'è ne impiegano 50 a testa (programmazione a coppia, a mio parere utilissima)gli vorresti far capire gli altri concetti?
Se non si rifattorizza costantemente il codice la complessità per effettuare una modifica cresce esponenzialmente e di conseguenza anche il costo per il cliente.
TDD e continuous refactoring sono le basi per avere una buona codebase e per mantenere i costi di sviluppo costanti.
Si hai perfettamente ragione, quello che dici è scritto anche in tutti i manuali di ingegneria del software ..... ma riesci a farlo capire al cliente?
Se non riesci a far capire che se una persona ci impiega 100 giorni ad effettuare un lavoro, 2 non c'è ne impiegano 50 a testa (programmazione a coppia, a mio parere utilissima)gli vorresti far capire gli altri concetti?
Kralizek
08-06-2010, 08:21
Io, invece, ho una generale tendenza alla rifattorizzazione (sono malato: aiutatemi!!! :cry:).
Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.
condivido, ma purtroppo é una cosa per cui raramente veniamo pagati ed al master Löwy disse che un refactor é accettabile solo quando diminuisce la complessitá di un "assembly" della radice quadrata...
Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.
condivido, ma purtroppo é una cosa per cui raramente veniamo pagati ed al master Löwy disse che un refactor é accettabile solo quando diminuisce la complessitá di un "assembly" della radice quadrata...
^TiGeRShArK^
08-06-2010, 08:24
E' vero ma pensa ad un codice legacy, ovviamente parti da una base senza TDD, devi apportare delle modifiche con tempi di rilascio di 1 settimana o al massimo 2 appena appena sufficienti a scrivere il codice necessario alla modifica, figuriamoci alla scrittura di test anche minimamente completi sulla parte modificata.
Non avrai mai il tempo di rifattorizzare nè tanto meno scrivere dei TDD e così di anno in anno la storia si ripete il software fa sempre più schifo, ma il tempo per prendersi una pausa di riflessione e cominciare a risistemarlo non ce l'hai mai.
Un pò per volta si può fare.
Non è possibile ovviamente riscrivere totalmente un codice legacy tutto in una volta, ma se nei periodi di minore carico lavorativo si iniziano a scrivere i test e a rifattorizzare in futuro si potranno trarre solo giovamenti.
Non avrai mai il tempo di rifattorizzare nè tanto meno scrivere dei TDD e così di anno in anno la storia si ripete il software fa sempre più schifo, ma il tempo per prendersi una pausa di riflessione e cominciare a risistemarlo non ce l'hai mai.
Un pò per volta si può fare.
Non è possibile ovviamente riscrivere totalmente un codice legacy tutto in una volta, ma se nei periodi di minore carico lavorativo si iniziano a scrivere i test e a rifattorizzare in futuro si potranno trarre solo giovamenti.
^TiGeRShArK^
08-06-2010, 08:25
Si hai perfettamente ragione, quello che dici è scritto anche in tutti i manuali di ingegneria del software ..... ma riesci a farlo capire al cliente?
Se non riesci a far capire che se una persona ci impiega 100 giorni ad effettuare un lavoro, 2 non c'è ne impiegano 50 a testa (programmazione a coppia, a mio parere utilissima)gli vorresti far capire gli altri concetti?
Qua da noi è esplicitamente richiesto fare refactoring ed avere una copertura dei test quanto più alta possibile.
In italia è un mondo a parte.
Se non riesci a far capire che se una persona ci impiega 100 giorni ad effettuare un lavoro, 2 non c'è ne impiegano 50 a testa (programmazione a coppia, a mio parere utilissima)gli vorresti far capire gli altri concetti?
Qua da noi è esplicitamente richiesto fare refactoring ed avere una copertura dei test quanto più alta possibile.
In italia è un mondo a parte.
^TiGeRShArK^
08-06-2010, 08:28
Io, almeno per ora, ho la fortuna di lavorare a codice mio. E a me piace avere il codice bello, sistemato e in ordine (secondo i miei "gusti"). In ufficio un mio collega mi chiama "l'esteta del codice". :asd:
Ma poi, come dicevi tu, la rifattorizzazione aiuta a mantenere la codebase; specialmente in combinazione con la TDD: ti vedi il codice trasformare senza che nemmeno te ne accorgi; è un po' difficile da spiegare, ma è come se ti portasse in maniera naturale ad averlo strutturato, pulito e ben sistemato.
Anche a me piace molto, però la cosa importante è riuscire a trovare il giusto bilanciamento tra aggiunta di nuove features e refactoring, indossando i cappelli da programmatore e da "rifattorizzatore" citando il buon ron jeffries. :D
A volte se inizi il refactoring ti capita di andare in loop e di perderci troppo tempo... ci vuole anche un pò di disciplina! :p
Ma poi, come dicevi tu, la rifattorizzazione aiuta a mantenere la codebase; specialmente in combinazione con la TDD: ti vedi il codice trasformare senza che nemmeno te ne accorgi; è un po' difficile da spiegare, ma è come se ti portasse in maniera naturale ad averlo strutturato, pulito e ben sistemato.
Anche a me piace molto, però la cosa importante è riuscire a trovare il giusto bilanciamento tra aggiunta di nuove features e refactoring, indossando i cappelli da programmatore e da "rifattorizzatore" citando il buon ron jeffries. :D
A volte se inizi il refactoring ti capita di andare in loop e di perderci troppo tempo... ci vuole anche un pò di disciplina! :p
minerte
08-06-2010, 08:29
In italia è un mondo a parte.
:ave: :ave: :ave: :ave: :ave: :ave:
Serve qualcuno a londra?
:ave: :ave: :ave: :ave: :ave: :ave:
Serve qualcuno a londra?
^TiGeRShArK^
08-06-2010, 08:31
:ave: :ave: :ave: :ave: :ave: :ave:
Serve qualcuno a londra?
:asd:
Per ora no che io sappia. :p
Serve qualcuno a londra?
:asd:
Per ora no che io sappia. :p
tomminno
08-06-2010, 08:43
Un pò per volta si può fare.
Non è possibile ovviamente riscrivere totalmente un codice legacy tutto in una volta, ma se nei periodi di minore carico lavorativo si iniziano a scrivere i test e a rifattorizzare in futuro si potranno trarre solo giovamenti.
Ovvio io non mi riferivo al rifare tutto insieme il software. Solo che metti che ti ci vuole 1 settimana (5 giorni) di tempo per scrivere il codice necessario alla modifica e diciamo in totale 7 giorni con i test. Ma la richiesta di modifica arriva sempre all'ultimo e in 1 settimana devi finire in produzione. Ovviamente contratti e dici posso fare il lavoro in 5 giorni o il lavoro fatto meglio in 7: la risposta è sempre: hai 4 giorni (perchè dall'alto vedono solo il risparmio immediato di 3 giorni). Il 5 giorno è assegnato dal reparto di test e pubblicazione.
E questo avviene puntualmente sempre per tutti i progetti. I tempi per la realizzazione sono sempre minori di quelli necessari alla scrittura ragionata del codice.
Non è possibile ovviamente riscrivere totalmente un codice legacy tutto in una volta, ma se nei periodi di minore carico lavorativo si iniziano a scrivere i test e a rifattorizzare in futuro si potranno trarre solo giovamenti.
Ovvio io non mi riferivo al rifare tutto insieme il software. Solo che metti che ti ci vuole 1 settimana (5 giorni) di tempo per scrivere il codice necessario alla modifica e diciamo in totale 7 giorni con i test. Ma la richiesta di modifica arriva sempre all'ultimo e in 1 settimana devi finire in produzione. Ovviamente contratti e dici posso fare il lavoro in 5 giorni o il lavoro fatto meglio in 7: la risposta è sempre: hai 4 giorni (perchè dall'alto vedono solo il risparmio immediato di 3 giorni). Il 5 giorno è assegnato dal reparto di test e pubblicazione.
E questo avviene puntualmente sempre per tutti i progetti. I tempi per la realizzazione sono sempre minori di quelli necessari alla scrittura ragionata del codice.
cdimauro
08-06-2010, 13:22
condivido, ma purtroppo é una cosa per cui raramente veniamo pagati ed al master Löwy disse che un refactor é accettabile solo quando diminuisce la complessitá di un "assembly" della radice quadrata...
Lo so, ed è un vero peccato. Qui manca proprio la mentalità, ma nel senso peggiore: non ci sono conoscenze in materie.
Anche a me piace molto, però la cosa importante è riuscire a trovare il giusto bilanciamento tra aggiunta di nuove features e refactoring, indossando i cappelli da programmatore e da "rifattorizzatore" citando il buon ron jeffries. :D
A volte se inizi il refactoring ti capita di andare in loop e di perderci troppo tempo... ci vuole anche un pò di disciplina! :p
D'accordissimo, ma quando cominciano a piovere pali e tu non puoi testare perché, come dicevo prima, sei soltanto un anello della catena e ti servono gli altri anelli ma non sono disponibili, allora alla prossima richiesta metti le mani avanti e ti prendi almeno una settimana in più del previsto per costruirti la test suite.
Finora è l'unica soluzione che ho trovato.
Il mio posteriore ha già dato, e non ha voglia di dare di nuovo. :asd:
Lo so, ed è un vero peccato. Qui manca proprio la mentalità, ma nel senso peggiore: non ci sono conoscenze in materie.
Anche a me piace molto, però la cosa importante è riuscire a trovare il giusto bilanciamento tra aggiunta di nuove features e refactoring, indossando i cappelli da programmatore e da "rifattorizzatore" citando il buon ron jeffries. :D
A volte se inizi il refactoring ti capita di andare in loop e di perderci troppo tempo... ci vuole anche un pò di disciplina! :p
D'accordissimo, ma quando cominciano a piovere pali e tu non puoi testare perché, come dicevo prima, sei soltanto un anello della catena e ti servono gli altri anelli ma non sono disponibili, allora alla prossima richiesta metti le mani avanti e ti prendi almeno una settimana in più del previsto per costruirti la test suite.
Finora è l'unica soluzione che ho trovato.
Il mio posteriore ha già dato, e non ha voglia di dare di nuovo. :asd:
tomminno
08-06-2010, 13:39
D'accordissimo, ma quando cominciano a piovere pali e tu non puoi testare perché, come dicevo prima, sei soltanto un anello della catena e ti servono gli altri anelli ma non sono disponibili, allora alla prossima richiesta metti le mani avanti e ti prendi almeno una settimana in più del previsto per costruirti la test suite.
Finora è l'unica soluzione che ho trovato.
Il mio posteriore ha già dato, e non ha voglia di dare di nuovo. :asd:
Eh già ma se la settimana in più non te la danno mai?
Finora è l'unica soluzione che ho trovato.
Il mio posteriore ha già dato, e non ha voglia di dare di nuovo. :asd:
Eh già ma se la settimana in più non te la danno mai?
shinya
08-06-2010, 13:45
Eh già ma se la settimana in più non te la danno mai?
Si ma soprattutto... secondo me tutti voi partite dall'assioma che il manager/capo progetto abbia come obiettivo di minimazzare i costi, adoperandosi per scegliere la soluzione più razionale possibile.
Non è cosi. Ci sono altri ragionamenti e interessi in gioco (almeno in Italia, almeno per la mia esperienza), che non si trovano scritti sui libri di TDD o altro.
Avevo postato un link tempo fa, che non so quanti abbiano effettivamente letto, ma riassume bene certe realtà: http://www.hwupgrade.it/forum/showthread.php?t=2198855
Si ma soprattutto... secondo me tutti voi partite dall'assioma che il manager/capo progetto abbia come obiettivo di minimazzare i costi, adoperandosi per scegliere la soluzione più razionale possibile.
Non è cosi. Ci sono altri ragionamenti e interessi in gioco (almeno in Italia, almeno per la mia esperienza), che non si trovano scritti sui libri di TDD o altro.
Avevo postato un link tempo fa, che non so quanti abbiano effettivamente letto, ma riassume bene certe realtà: http://www.hwupgrade.it/forum/showthread.php?t=2198855
tomminno
08-06-2010, 14:15
Si ma soprattutto... secondo me tutti voi partite dall'assioma che il manager/capo progetto abbia come obiettivo di minimazzare i costi, adoperandosi per scegliere la soluzione più razionale possibile.
C'è anche da pensare che spesso lo sviluppo e la manutenzione di un software sono affidati a team differenti. Ergo al responsabile dello sviluppo interessa solo che il tempo di sviluppo sia minimo, dell'eventuale tempo per correggere i bug a posteriori non gliene può fregar di meno (o meglio gliene può fregare in minima parte). Saranno tutte rogne del responsabile dell'altro reparto. Intanto verso i piani alti risulta che il tempo di sviluppo dei progetti è minimo quindi con grande ritorno d'immagine per il capo reparto. I tempi di manutenzione del software invece si disperdono nel tempo e non hanno tempistiche definite.
Avevo postato un link tempo fa, che non so quanti abbiano effettivamente letto, ma riassume bene certe realtà: http://www.hwupgrade.it/forum/showthread.php?t=2198855
Esattamente.
C'è anche da pensare che spesso lo sviluppo e la manutenzione di un software sono affidati a team differenti. Ergo al responsabile dello sviluppo interessa solo che il tempo di sviluppo sia minimo, dell'eventuale tempo per correggere i bug a posteriori non gliene può fregar di meno (o meglio gliene può fregare in minima parte). Saranno tutte rogne del responsabile dell'altro reparto. Intanto verso i piani alti risulta che il tempo di sviluppo dei progetti è minimo quindi con grande ritorno d'immagine per il capo reparto. I tempi di manutenzione del software invece si disperdono nel tempo e non hanno tempistiche definite.
Avevo postato un link tempo fa, che non so quanti abbiano effettivamente letto, ma riassume bene certe realtà: http://www.hwupgrade.it/forum/showthread.php?t=2198855
Esattamente.
MaxArt
09-06-2010, 00:53
Ahahah, giusto oggi ho scritto una roba tipo
...
else {
res = this_sucks("fanculo");
}
Io, invece, ho una generale tendenza alla rifattorizzazione (sono malato: aiutatemi!!! :cry:).
Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.Il refactoring è una pratica che faccio di continuo, ma trovo più stimolante creare qualcosa che si presti bene al refactoring, così che anche dopo mesi possa dire: "Ah, ma come sono stato bravo! :D"
Se questo non capita, non è raro che ripensi tutta la cosa da zero.
...
else {
res = this_sucks("fanculo");
}
Io, invece, ho una generale tendenza alla rifattorizzazione (sono malato: aiutatemi!!! :cry:).
Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.Il refactoring è una pratica che faccio di continuo, ma trovo più stimolante creare qualcosa che si presti bene al refactoring, così che anche dopo mesi possa dire: "Ah, ma come sono stato bravo! :D"
Se questo non capita, non è raro che ripensi tutta la cosa da zero.
Kralizek
09-06-2010, 07:52
scusate l'OT (visto che il nuovo tema é molto piú interessante) ma per la cronaca, ho rimesso a posto la paginetta e da 2000ms di caricamento siamo scesi ai soliti 50ms.
cosa da mordere alla giugulare del contadino! :S
cosa da mordere alla giugulare del contadino! :S
cdimauro
13-06-2010, 06:40
Rieccomi, dopo aver scritto 115 test e aver superato agevolmente, solo per i test, la dimensione del sorgente originale (che tra l'altro ho pesantemente rifattorizzato). :cool:
Eh già ma se la settimana in più non te la danno mai?
Ma io mica l'ho chiesta. :D
Mi è stato chiesto di aggiungere / modificare n funzionalità, e gli ho risposto che mi servivano m giorni, con m che includeva quella settimana. Mi hanno detto sì e ho cominciato a scrivere test.
Se non fai così non riesci a ritagliarti lo spazio necessario per avere una code base solida e poco prona ai bug. Che poi i bug ci possono sempre essere, eh! Ma con 115 test ben scritti (almeno spero), se cambio qualcosa anche solo per sbaglio ho una sfilza di semafori rossi che mi si accendono (NetBeans, tra l'altro, ha un buon supporto per i test anche usando Python), e come m'è capitato.
Ho cambiato una stupidaggine, ho dimenticato di aggiornare quel codice, e 4 test sono saltati. :D
Si ma soprattutto... secondo me tutti voi partite dall'assioma che il manager/capo progetto abbia come obiettivo di minimazzare i costi, adoperandosi per scegliere la soluzione più razionale possibile.
Non è cosi. Ci sono altri ragionamenti e interessi in gioco (almeno in Italia, almeno per la mia esperienza), che non si trovano scritti sui libri di TDD o altro.
Manager? Capo progetto? Che roba è? :D E' da tempo che invoco la figura del project manager per questo progetto complesso e delicato a cui sto lavorando in questo periodo. Nonostante tutte le minchiate che sono capitate in questi due anni, con stravolgimenti e ri-stravolgimenti dei requisiti in corso d'opera, soltanto lo scorso mese hanno finalmente tirato fuori questa figura, ma... in duplice persona :D Ognuno s'è preso una certa area di competenza.
E comunque il project manager che si occupa della parte che curo io (e altri miei colleghi) viene da me, e mi chiede quanto tempo ci metto, e la cosa finisce lì.
Non c'è nessuno, nemmeno il mio responsabile, che abbia la competenza per capire quanto tempo mi ci vuole per implementare qualcosa. Di Python ne masticano in pochi qui, e men che meno c'è gente che si va a spulciare il mio codice (che comunque non è scritto male, ma io amo utilizzare tutte le caratteristiche di Python, quindi il linguaggio DEVI conoscerlo se ti trovi davanti una generator expression o una metaclasse).
Diciamo che sono nella posizione migliore; più precisamente, in una posizione che si vede raramente (di norma i tempi li dettano altri, appunto).
Ma con ciò non è che me ne approfitto. Io il lavoro lo faccio, e i risultati li porto. Se questa volta (mai capitato prima) mi sono preso una settimana in più è perché veramente ne avevo bisogno, perché non posso continuare a mettere le mani sul codice e fare qualche test funzionale poi dopo "per vedere se va tutto bene"; specialmente con questo progetto non me lo posso più permettere!
Poi vorrei che l'azienda cominciasse finalmente a investire seriamente nello sviluppo di codice di qualità. E' vero che finora la politica dello "scrivo velocemente il pezzo di codice per la commessa che è arrivata oggi, ma con la scadenza a ieri" ci ha portato il pane e ci ha permesso di diventare la realtà che siamo, ma con una struttura di una 80ina di persone devi deciderti a passare dalla garage-house (perché la mentalità è quella: da bottega artigiana) a una quasi media impresa. Son costi e tempo, non lo metto in dubbio, ma serve una struttura professionale.
Non si può più contare sull'abilità dei singoli individui che, per quanto "bravi", non hanno la patente per scrivere codice esente da bug...
Avevo postato un link tempo fa, che non so quanti abbiano effettivamente letto, ma riassume bene certe realtà: http://www.hwupgrade.it/forum/showthread.php?t=2198855
Da allora mi sento come Kirk: "diario di bordo del capitano, data terrestre DD-MM-YYYY, oggi ho fatto x, y e z; poi però ho aggiunto anche w; in mezzo ci sono state due riunioni con Tizio e Caio". :cool:
Grazie per quel link che è stato molto utile. Devo ricordarmi, anzi, di rileggerlo ogni tanto, in modo da fissare bene a mente tutti gli utili consigli.
C'è anche da pensare che spesso lo sviluppo e la manutenzione di un software sono affidati a team differenti. Ergo al responsabile dello sviluppo interessa solo che il tempo di sviluppo sia minimo, dell'eventuale tempo per correggere i bug a posteriori non gliene può fregar di meno (o meglio gliene può fregare in minima parte). Saranno tutte rogne del responsabile dell'altro reparto. Intanto verso i piani alti risulta che il tempo di sviluppo dei progetti è minimo quindi con grande ritorno d'immagine per il capo reparto. I tempi di manutenzione del software invece si disperdono nel tempo e non hanno tempistiche definite.
Esattamente.
Concordo. Io ho la fortuna di essere uno e bino/trino/ecc.: sviluppo, testo, e mantengo il mio codice. :D
Il refactoring è una pratica che faccio di continuo, ma trovo più stimolante creare qualcosa che si presti bene al refactoring, così che anche dopo mesi possa dire: "Ah, ma come sono stato bravo! :D"
Se questo non capita, non è raro che ripensi tutta la cosa da zero.
Anch'io tendo a scrivere roba che sia semplice da rifattorizzare, ma a volte capita che ti cambino dei requisiti che ti porta necessariamente a rimettere mano a una porzione di codice e rifattorizzarla del tutto.
Come capita pure che scrivo un codice che fa esattamente quello che m'è stato chiesto (io adoro il principio YAGNI :D), poi arriva la classica modifica da fare che ti scombussola le cose, e sono costretto ad astrarre il codice e a rifattorizzarre...
Eh già ma se la settimana in più non te la danno mai?
Ma io mica l'ho chiesta. :D
Mi è stato chiesto di aggiungere / modificare n funzionalità, e gli ho risposto che mi servivano m giorni, con m che includeva quella settimana. Mi hanno detto sì e ho cominciato a scrivere test.
Se non fai così non riesci a ritagliarti lo spazio necessario per avere una code base solida e poco prona ai bug. Che poi i bug ci possono sempre essere, eh! Ma con 115 test ben scritti (almeno spero), se cambio qualcosa anche solo per sbaglio ho una sfilza di semafori rossi che mi si accendono (NetBeans, tra l'altro, ha un buon supporto per i test anche usando Python), e come m'è capitato.
Ho cambiato una stupidaggine, ho dimenticato di aggiornare quel codice, e 4 test sono saltati. :D
Si ma soprattutto... secondo me tutti voi partite dall'assioma che il manager/capo progetto abbia come obiettivo di minimazzare i costi, adoperandosi per scegliere la soluzione più razionale possibile.
Non è cosi. Ci sono altri ragionamenti e interessi in gioco (almeno in Italia, almeno per la mia esperienza), che non si trovano scritti sui libri di TDD o altro.
Manager? Capo progetto? Che roba è? :D E' da tempo che invoco la figura del project manager per questo progetto complesso e delicato a cui sto lavorando in questo periodo. Nonostante tutte le minchiate che sono capitate in questi due anni, con stravolgimenti e ri-stravolgimenti dei requisiti in corso d'opera, soltanto lo scorso mese hanno finalmente tirato fuori questa figura, ma... in duplice persona :D Ognuno s'è preso una certa area di competenza.
E comunque il project manager che si occupa della parte che curo io (e altri miei colleghi) viene da me, e mi chiede quanto tempo ci metto, e la cosa finisce lì.
Non c'è nessuno, nemmeno il mio responsabile, che abbia la competenza per capire quanto tempo mi ci vuole per implementare qualcosa. Di Python ne masticano in pochi qui, e men che meno c'è gente che si va a spulciare il mio codice (che comunque non è scritto male, ma io amo utilizzare tutte le caratteristiche di Python, quindi il linguaggio DEVI conoscerlo se ti trovi davanti una generator expression o una metaclasse).
Diciamo che sono nella posizione migliore; più precisamente, in una posizione che si vede raramente (di norma i tempi li dettano altri, appunto).
Ma con ciò non è che me ne approfitto. Io il lavoro lo faccio, e i risultati li porto. Se questa volta (mai capitato prima) mi sono preso una settimana in più è perché veramente ne avevo bisogno, perché non posso continuare a mettere le mani sul codice e fare qualche test funzionale poi dopo "per vedere se va tutto bene"; specialmente con questo progetto non me lo posso più permettere!
Poi vorrei che l'azienda cominciasse finalmente a investire seriamente nello sviluppo di codice di qualità. E' vero che finora la politica dello "scrivo velocemente il pezzo di codice per la commessa che è arrivata oggi, ma con la scadenza a ieri" ci ha portato il pane e ci ha permesso di diventare la realtà che siamo, ma con una struttura di una 80ina di persone devi deciderti a passare dalla garage-house (perché la mentalità è quella: da bottega artigiana) a una quasi media impresa. Son costi e tempo, non lo metto in dubbio, ma serve una struttura professionale.
Non si può più contare sull'abilità dei singoli individui che, per quanto "bravi", non hanno la patente per scrivere codice esente da bug...
Avevo postato un link tempo fa, che non so quanti abbiano effettivamente letto, ma riassume bene certe realtà: http://www.hwupgrade.it/forum/showthread.php?t=2198855
Da allora mi sento come Kirk: "diario di bordo del capitano, data terrestre DD-MM-YYYY, oggi ho fatto x, y e z; poi però ho aggiunto anche w; in mezzo ci sono state due riunioni con Tizio e Caio". :cool:
Grazie per quel link che è stato molto utile. Devo ricordarmi, anzi, di rileggerlo ogni tanto, in modo da fissare bene a mente tutti gli utili consigli.
C'è anche da pensare che spesso lo sviluppo e la manutenzione di un software sono affidati a team differenti. Ergo al responsabile dello sviluppo interessa solo che il tempo di sviluppo sia minimo, dell'eventuale tempo per correggere i bug a posteriori non gliene può fregar di meno (o meglio gliene può fregare in minima parte). Saranno tutte rogne del responsabile dell'altro reparto. Intanto verso i piani alti risulta che il tempo di sviluppo dei progetti è minimo quindi con grande ritorno d'immagine per il capo reparto. I tempi di manutenzione del software invece si disperdono nel tempo e non hanno tempistiche definite.
Esattamente.
Concordo. Io ho la fortuna di essere uno e bino/trino/ecc.: sviluppo, testo, e mantengo il mio codice. :D
Il refactoring è una pratica che faccio di continuo, ma trovo più stimolante creare qualcosa che si presti bene al refactoring, così che anche dopo mesi possa dire: "Ah, ma come sono stato bravo! :D"
Se questo non capita, non è raro che ripensi tutta la cosa da zero.
Anch'io tendo a scrivere roba che sia semplice da rifattorizzare, ma a volte capita che ti cambino dei requisiti che ti porta necessariamente a rimettere mano a una porzione di codice e rifattorizzarla del tutto.
Come capita pure che scrivo un codice che fa esattamente quello che m'è stato chiesto (io adoro il principio YAGNI :D), poi arriva la classica modifica da fare che ti scombussola le cose, e sono costretto ad astrarre il codice e a rifattorizzarre...
khelidan1980
13-06-2010, 10:46
Non ci credo :asd:
:eek:
vi meravigliate con poco, ho trovato chicche del genere( tra le tante, tantissime altre):
System.out.println("--------->)
System.out.println("--------------->)
System.out.println("---------------------->)
e il tutto stava ad indicare i vari gradi di innestamento di if o cicli for ora non ricordo bene, e sottolineo che il tutto era voluto e pensato.
:eek:
vi meravigliate con poco, ho trovato chicche del genere( tra le tante, tantissime altre):
System.out.println("--------->)
System.out.println("--------------->)
System.out.println("---------------------->)
e il tutto stava ad indicare i vari gradi di innestamento di if o cicli for ora non ricordo bene, e sottolineo che il tutto era voluto e pensato.
cdimauro
13-06-2010, 10:58
scusate l'OT (visto che il nuovo tema é molto piú interessante) ma per la cronaca, ho rimesso a posto la paginetta e da 2000ms di caricamento siamo scesi ai soliti 50ms.
cosa da mordere alla giugulare del contadino! :S
vi meravigliate con poco, ho trovato chicche del genere( tra le tante, tantissime altre):
System.out.println("--------->)
System.out.println("--------------->)
System.out.println("---------------------->)
e il tutto stava ad indicare i vari gradi di innestamento di if o cicli for ora non ricordo bene, e sottolineo che il tutto era voluto e pensato.
E' in momenti come questi che la fede nella democrazia e nel buon senso vacilla, e si affacciano, minacciosi, i forconi verso gli eretici (e untori)...
cosa da mordere alla giugulare del contadino! :S
vi meravigliate con poco, ho trovato chicche del genere( tra le tante, tantissime altre):
System.out.println("--------->)
System.out.println("--------------->)
System.out.println("---------------------->)
e il tutto stava ad indicare i vari gradi di innestamento di if o cicli for ora non ricordo bene, e sottolineo che il tutto era voluto e pensato.
E' in momenti come questi che la fede nella democrazia e nel buon senso vacilla, e si affacciano, minacciosi, i forconi verso gli eretici (e untori)...
Kralizek
13-06-2010, 11:04
E' in momenti come questi che la fede nella democrazia e nel buon senso vacilla, e si affacciano, minacciosi, i forconi verso gli eretici (e untori)...
parole sante... certe volte sento la mancanza della cara vecchia dispotica disciplina militare!
parole sante... certe volte sento la mancanza della cara vecchia dispotica disciplina militare!
WarDuck
13-06-2010, 11:49
Io sono del parere che chiunque metta un briciolo di passione nel lavoro che fa si spinga sempre a migliorare.
Il problema è la maggior parte delle volte è che ti trovi davanti a gente "spenta", il cui obiettivo è semplicemente fare il minimo per portare a casa la pagnotta, e considerando che è una cosa che vedo anche all'università (dove si presume che tu abbia fatto la scelta sulla base di ciò che ti piace fare), francamente non vedo come questo paese potrà mai progredire in meglio.
Da una parte perché il pezzo di carta ormai non garantisce più di trovarti qualcuno che effettivamente abbia le giuste competenze, dall'altra perché c'è chi vuole investire il meno possibile sulle persone, come se la conoscenza e il saper fare vengano date dall'alto.
Le persone sono la cosa fondamentale in un progetto più che tutto il resto, l'ho visto a mie spese all'università e penso che purtroppo la cosa sarà amplificata notevolmente nel mondo del lavoro.
Sarò ingenuo, ma voglio credere che comunque ci siano persone che fanno questo lavoro con passione nonostante tutto e tutti.
Il problema è la maggior parte delle volte è che ti trovi davanti a gente "spenta", il cui obiettivo è semplicemente fare il minimo per portare a casa la pagnotta, e considerando che è una cosa che vedo anche all'università (dove si presume che tu abbia fatto la scelta sulla base di ciò che ti piace fare), francamente non vedo come questo paese potrà mai progredire in meglio.
Da una parte perché il pezzo di carta ormai non garantisce più di trovarti qualcuno che effettivamente abbia le giuste competenze, dall'altra perché c'è chi vuole investire il meno possibile sulle persone, come se la conoscenza e il saper fare vengano date dall'alto.
Le persone sono la cosa fondamentale in un progetto più che tutto il resto, l'ho visto a mie spese all'università e penso che purtroppo la cosa sarà amplificata notevolmente nel mondo del lavoro.
Sarò ingenuo, ma voglio credere che comunque ci siano persone che fanno questo lavoro con passione nonostante tutto e tutti.
DanieleC88
13-06-2010, 11:52
Il problema è la maggior parte delle volte è che ti trovi davanti a gente "spenta", il cui obiettivo è semplicemente fare il minimo per portare a casa la pagnotta, e considerando che è una cosa che vedo anche all'università (dove si presume che tu abbia fatto la scelta sulla base di ciò che ti piace fare), francamente non vedo come questo paese potrà mai progredire in meglio.
Mal comune, mezzo gaudio... :mano:
Mal comune, mezzo gaudio... :mano:
Kralizek
13-06-2010, 11:58
Io sono del parere che chiunque metta un briciolo di passione nel lavoro che fa si spinga sempre a migliorare.
Il problema è la maggior parte delle volte è che ti trovi davanti a gente "spenta", il cui obiettivo è semplicemente fare il minimo per portare a casa la pagnotta, e considerando che è una cosa che vedo anche all'università (dove si presume che tu abbia fatto la scelta sulla base di ciò che ti piace fare), francamente non vedo come questo paese potrà mai progredire in meglio.
Da una parte perché il pezzo di carta ormai non garantisce più di trovarti qualcuno che effettivamente abbia le giuste competenze, dall'altra perché c'è chi vuole investire il meno possibile sulle persone, come se la conoscenza e il saper fare vengano date dall'alto.
Le persone sono la cosa fondamentale in un progetto più che tutto il resto, l'ho visto a mie spese all'università e penso che purtroppo la cosa sarà amplificata notevolmente nel mondo del lavoro.
Sarò ingenuo, ma voglio credere che comunque ci siano persone che fanno questo lavoro con passione nonostante tutto e tutti.
ti assicuro che non è una cosa solo italiana ;)
Il problema è la maggior parte delle volte è che ti trovi davanti a gente "spenta", il cui obiettivo è semplicemente fare il minimo per portare a casa la pagnotta, e considerando che è una cosa che vedo anche all'università (dove si presume che tu abbia fatto la scelta sulla base di ciò che ti piace fare), francamente non vedo come questo paese potrà mai progredire in meglio.
Da una parte perché il pezzo di carta ormai non garantisce più di trovarti qualcuno che effettivamente abbia le giuste competenze, dall'altra perché c'è chi vuole investire il meno possibile sulle persone, come se la conoscenza e il saper fare vengano date dall'alto.
Le persone sono la cosa fondamentale in un progetto più che tutto il resto, l'ho visto a mie spese all'università e penso che purtroppo la cosa sarà amplificata notevolmente nel mondo del lavoro.
Sarò ingenuo, ma voglio credere che comunque ci siano persone che fanno questo lavoro con passione nonostante tutto e tutti.
ti assicuro che non è una cosa solo italiana ;)
ndakota
13-06-2010, 12:04
Forse non vi rendete conto che non tutti sono fortunati come noi, ad avere una passione che è anche materia di studio. Conosco un sacco di ragazzi in gamba, intelligenti, che però non sanno cosa studiare. Li capisco, anch'io se non ci fosse l'informatica sarei un po' in difficoltà.
Ryuzaki_Eru
13-06-2010, 12:09
Di gente che fa questo lavoro perchè ha passione, vera passione, fortunatamente se ne trova ancora. Anche io in università vedo ragazzi che mi fanno domandare "ma che ci fanno questi qua?". Ho trovato, su centinaia di persone, solo pochissimi ragazzi che hanno una *vera* passione. Per il resto quoto ndakota, se non avessi questa passione non saprei veramente che fare.
WarDuck
13-06-2010, 13:42
Il punto è che è giusto e sacrosanto dare a tutti le stesse possibilità, ma non è corretto mandare avanti tutti a prescindere e soprattutto non è corretto illudere i ragazzi che l'università sia la soluzione a tutti i problemi, che troveranno lavoro alla fine del percorso universitario solo perché hanno un pezzo di carta.
Ci sono settori più sovraffollati di altri, è inutile far intraprendere una carriera universitaria se poi SAI GIA' che non troveranno lavoro in quel settore perché non c'è domanda di mercato.
Anziché puntare ad innalzare la qualità generale dell'istruzione si è pensato bene di abbassare la soglia di accesso per l'università (illudendo appunto che questo fosse il preludio per un innalzamento della qualità), andando al tempo stesso a rovinare gli istituti professionali che un tempo erano considerati qualificanti, e non poco, per il mondo del lavoro.
Il risultato? Il lavoro sporco non lo vuole fare più nessuno. E di questo non si può dare colpa solo ai ragazzi.
Tutti ingegneri, tutti architetti, tutti filosofi, tutti letterati, tutti avvocati, tutti esperti in comunicazione, tutti sociologi, tutti diplomatici...
E' chiaro che qualcuno ne rimarrà fuori, purtroppo anche chi voleva realmente fare quel lavoro per passione.
Non so a voi, ma a me questo mette un po' di tristezza.
Ci sono settori più sovraffollati di altri, è inutile far intraprendere una carriera universitaria se poi SAI GIA' che non troveranno lavoro in quel settore perché non c'è domanda di mercato.
Anziché puntare ad innalzare la qualità generale dell'istruzione si è pensato bene di abbassare la soglia di accesso per l'università (illudendo appunto che questo fosse il preludio per un innalzamento della qualità), andando al tempo stesso a rovinare gli istituti professionali che un tempo erano considerati qualificanti, e non poco, per il mondo del lavoro.
Il risultato? Il lavoro sporco non lo vuole fare più nessuno. E di questo non si può dare colpa solo ai ragazzi.
Tutti ingegneri, tutti architetti, tutti filosofi, tutti letterati, tutti avvocati, tutti esperti in comunicazione, tutti sociologi, tutti diplomatici...
E' chiaro che qualcuno ne rimarrà fuori, purtroppo anche chi voleva realmente fare quel lavoro per passione.
Non so a voi, ma a me questo mette un po' di tristezza.
DanieleC88
13-06-2010, 13:49
@ndakota: io penso che se non avessi scelto informatica sarei andato a fare filosofia... :stordita:
@WarDuck: stai dicendo le cose che penso praticamente da sempre. Almeno in questa discussione siamo d'accordo. :D
Un po' della colpa penso sia dei genitori, che chiaramente sarebbe bello per tutti vedere un figlio diventare ingegnere, avvocato, dottore, etc... E poi nessuno svolge più le attività "produttive".
@WarDuck: stai dicendo le cose che penso praticamente da sempre. Almeno in questa discussione siamo d'accordo. :D
Un po' della colpa penso sia dei genitori, che chiaramente sarebbe bello per tutti vedere un figlio diventare ingegnere, avvocato, dottore, etc... E poi nessuno svolge più le attività "produttive".
Kralizek
13-06-2010, 16:11
@ndakota: io penso che se non avessi scelto informatica sarei andato a fare filosofia... :stordita:
@WarDuck: stai dicendo le cose che penso praticamente da sempre. Almeno in questa discussione siamo d'accordo. :D
Un po' della colpa penso sia dei genitori, che chiaramente sarebbe bello per tutti vedere un figlio diventare ingegnere, avvocato, dottore, etc... E poi nessuno svolge più le attività "produttive".
non penso sia "colpa" dei genitori. Il problema è che all'epoca essere laureato ti dava certe possibilità che ora non ti dà più. é normale per un genitore cercare di offrire ai propri figli le migliori opportunità nelle loro possiblità. Ovvio che con il benessere degli anni 80 90 la laurea è diventata sempre più obbligo ed il carattere divisorio è stato assunto dai master prima e, ahimè, dalla possibilità di esperienze all'estero più o meno lunghe.
D'altro canto è anche colpa delle aziende che chiedono la laurea anche per fare le fotocopie. Però questo è tipicamente italiano, perchè qui in svezia i laureati sono pochi ed anche le aziende sanno ancora distinguere tra "laureati" e "tecnici".
@WarDuck: stai dicendo le cose che penso praticamente da sempre. Almeno in questa discussione siamo d'accordo. :D
Un po' della colpa penso sia dei genitori, che chiaramente sarebbe bello per tutti vedere un figlio diventare ingegnere, avvocato, dottore, etc... E poi nessuno svolge più le attività "produttive".
non penso sia "colpa" dei genitori. Il problema è che all'epoca essere laureato ti dava certe possibilità che ora non ti dà più. é normale per un genitore cercare di offrire ai propri figli le migliori opportunità nelle loro possiblità. Ovvio che con il benessere degli anni 80 90 la laurea è diventata sempre più obbligo ed il carattere divisorio è stato assunto dai master prima e, ahimè, dalla possibilità di esperienze all'estero più o meno lunghe.
D'altro canto è anche colpa delle aziende che chiedono la laurea anche per fare le fotocopie. Però questo è tipicamente italiano, perchè qui in svezia i laureati sono pochi ed anche le aziende sanno ancora distinguere tra "laureati" e "tecnici".
DanieleC88
13-06-2010, 16:29
non penso sia "colpa" dei genitori. Il problema è che all'epoca essere laureato ti dava certe possibilità che ora non ti dà più. é normale per un genitore cercare di offrire ai propri figli le migliori opportunità nelle loro possiblità.
Ma infatti non volevo incolpare nessuno, non è una "colpa", ma sta di fatto che al giorno d'oggi i laureati sono tantissimi e ce ne saranno sempre di più, per cui oggi un neolaureato non è nient'altro che "uno dei tanti".
Ma infatti non volevo incolpare nessuno, non è una "colpa", ma sta di fatto che al giorno d'oggi i laureati sono tantissimi e ce ne saranno sempre di più, per cui oggi un neolaureato non è nient'altro che "uno dei tanti".
Teo@Unix
13-06-2010, 17:09
passione + fatica....
tra l'altro fare fatica per ottenere qualcosa non è una delle cosa più belle?:)
tra l'altro fare fatica per ottenere qualcosa non è una delle cosa più belle?:)
PGI-Bis
13-06-2010, 17:19
Con un misto di preoccupazione e ilarità devo dire che pur avendo il sospetto che alcuni dei partecipanti a questo thread effettivamente abbiano frequentato un'università, questi non abbiano la più pallida idea del perchè ci siano andati.
C'era 'sta gente che a una certa ora mi faceva un sacco di domande e io rispondevo ma sotto sotto chiedendomi "com'è che 'sti tizi non son capaci di farsi i cavoli loro?".
Vi chiedo e, devo ammettere, sganasciandomi un poco: un'idea pur vaga della ragione delle università, l'avete?
Perchè sembra che l'università esista per il lavoro che dovrebbe farti trovare, il che è di una stupidità quasi comica.
C'era 'sta gente che a una certa ora mi faceva un sacco di domande e io rispondevo ma sotto sotto chiedendomi "com'è che 'sti tizi non son capaci di farsi i cavoli loro?".
Vi chiedo e, devo ammettere, sganasciandomi un poco: un'idea pur vaga della ragione delle università, l'avete?
Perchè sembra che l'università esista per il lavoro che dovrebbe farti trovare, il che è di una stupidità quasi comica.
Ryuzaki_Eru
13-06-2010, 18:14
Chi è che ha detto che l'università esiste per il lavoro che deve farti trovare?
PGI-Bis
13-06-2010, 19:01
In questa pagina conto otto riferimenti a quell'idea.
DanieleC88
13-06-2010, 19:04
In questa pagina conto otto riferimenti a quell'idea.
Coraggio, sii esplicito, nessuno si offenderà per le tue parole. :cool:
Coraggio, sii esplicito, nessuno si offenderà per le tue parole. :cool:
ndakota
13-06-2010, 19:04
In questa pagina conto otto riferimenti a quell'idea.
Io conto tre riferimenti nulli :O
Io conto tre riferimenti nulli :O
DanieleC88
13-06-2010, 19:05
Io conto tre riferimenti nulli :O
Racchiudili in un try/catch.
Racchiudili in un try/catch.
Kralizek
13-06-2010, 20:10
Racchiudili in un try/catch.
qual è il santo protettore dei nerd da bestemmiare in questo caso? :sofico:
qual è il santo protettore dei nerd da bestemmiare in questo caso? :sofico:
Kralizek
13-06-2010, 20:14
In questa pagina conto otto riferimenti a quell'idea.
sicuramente un paio di quegli otto sono miei.
nel dubbio ti dico:
la laurea non serve a lavorare, ma quando si deve approcciare un problema, a parità di età (ed in ufficio da me siamo tutti sotto i 30 ad eccezione del grafico) ed a parità di problema, si vede lontano un miglio chi ha la laurea ed approccia il problema in maniera strutturata e chi viene fuori da un corso tecnico di 2 anni basato su SQL Server ed ASP.NET in C#.
Nulla da dire su queste persone che sono ottimi per fare il lavoro sporco. Ma quando il lavoro si fa serio iniziano a vedersi le differenze.
Cappio, ad uno gli ho passato uno snippet che scrissi tempo fa in VB.NET e si sono lamentati che era in VB.NET e non in C#... ed è una cappiata questa eh :P
sicuramente un paio di quegli otto sono miei.
nel dubbio ti dico:
la laurea non serve a lavorare, ma quando si deve approcciare un problema, a parità di età (ed in ufficio da me siamo tutti sotto i 30 ad eccezione del grafico) ed a parità di problema, si vede lontano un miglio chi ha la laurea ed approccia il problema in maniera strutturata e chi viene fuori da un corso tecnico di 2 anni basato su SQL Server ed ASP.NET in C#.
Nulla da dire su queste persone che sono ottimi per fare il lavoro sporco. Ma quando il lavoro si fa serio iniziano a vedersi le differenze.
Cappio, ad uno gli ho passato uno snippet che scrissi tempo fa in VB.NET e si sono lamentati che era in VB.NET e non in C#... ed è una cappiata questa eh :P
cdimauro
13-06-2010, 20:57
A me l'università ha dato molto. Il distacco col mio modo di pensare e approcciarmi ai problemi rispetto a quando frequentavo l'ITIS è enorme.
Uno può essere bravo quanto si vuole, ma se all'università non va a scaldare il banco e passare soltanto l'esame per arrivare alla laurea, il valore aggiunto è notevole.
Specialmente materie come teoria della computabilità, a posteriori (prima mi chiedevo perché avessero incluso materie così "insulse") sono quelle che mi hanno fatto maturare di più.
Non nascondo che una materia, geometria, l'ho superata da svogliato: non mi piaceva proprio (ho, invece, adorato algebra e calcolo numerico) e ho preso il voto più scarso di tutte le materie che ho dato (22, se non ricordo male). Però qualcosa m'è rimasta lo stesso (anche perché in genere ho sempre seguito le lezioni con notevole attenzione, prendendo anche appunti). Ed è stata anche l'unica che ho preparato così all'acqua di rose (per le altre ho studiato il 100% o quasi del programma; se non capivo una cosa rimanevo bloccato).
Tutto molto utile. Per me, insomma, c'è un prima e un dopo l'università...
Uno può essere bravo quanto si vuole, ma se all'università non va a scaldare il banco e passare soltanto l'esame per arrivare alla laurea, il valore aggiunto è notevole.
Specialmente materie come teoria della computabilità, a posteriori (prima mi chiedevo perché avessero incluso materie così "insulse") sono quelle che mi hanno fatto maturare di più.
Non nascondo che una materia, geometria, l'ho superata da svogliato: non mi piaceva proprio (ho, invece, adorato algebra e calcolo numerico) e ho preso il voto più scarso di tutte le materie che ho dato (22, se non ricordo male). Però qualcosa m'è rimasta lo stesso (anche perché in genere ho sempre seguito le lezioni con notevole attenzione, prendendo anche appunti). Ed è stata anche l'unica che ho preparato così all'acqua di rose (per le altre ho studiato il 100% o quasi del programma; se non capivo una cosa rimanevo bloccato).
Tutto molto utile. Per me, insomma, c'è un prima e un dopo l'università...
shinya
14-06-2010, 08:49
Sarò ingenuo, ma voglio credere che comunque ci siano persone che fanno questo lavoro con passione nonostante tutto e tutti.
La pensavo cosi anch'io. Ma il lavoro abbruttisce, e già dopo pochissimo cominci a sviluppare una certa forma di disillusione.
Spesso il cliente non ti lascia fare le cose come andrebbero fatte, e la passione fa presto ad abbandonarti... quello che vuoi è solo che questo strazio finisca il prima possibile, vuoi andartene a casa, startene con la tua famiglia o farti una partita a Team Fortress 2.
E quindi cominci a dire "ma vaffanculo!"...perchè tanto è tutto dovuto e nessuno riconosce veramente il lavoro che fai.
Nel mondo del lavoro la passione è alimentata solo dal tuo narcisismo... o se soffri di OCD.
Se vuoi coltivare la passione devi trovarti altri spazi. Io ad esempio la tengo alta programmando in factor e contribuendo al progetto con il mio codice, quando ho tempo.
La pensavo cosi anch'io. Ma il lavoro abbruttisce, e già dopo pochissimo cominci a sviluppare una certa forma di disillusione.
Spesso il cliente non ti lascia fare le cose come andrebbero fatte, e la passione fa presto ad abbandonarti... quello che vuoi è solo che questo strazio finisca il prima possibile, vuoi andartene a casa, startene con la tua famiglia o farti una partita a Team Fortress 2.
E quindi cominci a dire "ma vaffanculo!"...perchè tanto è tutto dovuto e nessuno riconosce veramente il lavoro che fai.
Nel mondo del lavoro la passione è alimentata solo dal tuo narcisismo... o se soffri di OCD.
Se vuoi coltivare la passione devi trovarti altri spazi. Io ad esempio la tengo alta programmando in factor e contribuendo al progetto con il mio codice, quando ho tempo.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.