[OT: Rapporti sociali] - Vita d'ufficio

[Kralizek]

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?

[cdimauro]

Beh, quando capita io lo faccio. Lo sanno anche i muri, in ufficio, che disprezzo il mio vecchio codice.

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. Adesso sono MOLTO più sereno.

[shinya]

Originariamente inviato da Kralizek

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.

[Kralizek]

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

[shinya]

Originariamente inviato da Kralizek

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'

[cdimauro]

In tal caso... a morte il contadino.

[Ryuzaki_Eru]

Originariamente inviato da cdimauro

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. 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

[vladix]

Originariamente inviato da cdimauro

In tal caso... a morte il contadino.

voto unanime

PS: un pezzettino di codice trovato su una delle applicazioni che sto modificando

logger.debug("sono dentroooooooooooooooooooo"); // oooh siii ... che goduria

[Ryuzaki_Eru]

Non ci credo

[Kralizek]

[marco.r]

Originariamente inviato da Kralizek

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 .

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]

Originariamente inviato da marco.r

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 .

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]

Quella di Raoul è geniale, soprattuto la parte degli asd....

[cdimauro]

Originariamente inviato da Ryuzaki_Eru

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

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.

Originariamente inviato da vladix

PS: un pezzettino di codice trovato su una delle applicazioni che sto modificando

logger.debug("sono dentroooooooooooooooooooo"); // oooh siii ... che goduria

Questa è da antologia.

[DanieleC88]

Originariamente inviato da RaouL_BennetH

io sono uno dei contadini

[minerte]

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 ( ) 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]

Io, invece, ho una generale tendenza alla rifattorizzazione (sono malato: aiutatemi!!! ).

Magari dirò un'eresia, ma la trovo un'attività più stimolante e appagante della stessa (prima) scrittura del codice.

[Albitexm]

Originariamente inviato da Kralizek

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..

[minerte]

Originariamente inviato da cdimauro

Io, invece, ho una generale tendenza alla rifattorizzazione (sono malato: aiutatemi!!! ).

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^]

Originariamente inviato da minerte

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.