[OT: Rapporti sociali] - Vita d'ufficio

[cdimauro]

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

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

Originariamente inviato da ^TiGeRShArK^

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

Come diceva il mio professore di fisica alle superiori:

L'eleganza è tutto.



Certo è che se qualcuno mette le mani nel mio codice non so se potrei rispondere di me stesso

[tomminno]

Originariamente inviato da ^TiGeRShArK^

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

[minerte]

Originariamente inviato da ^TiGeRShArK^

è 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?

[Kralizek]

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.

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

Originariamente inviato da tomminno

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.

[^TiGeRShArK^]

Originariamente inviato da minerte

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.

[^TiGeRShArK^]

Originariamente inviato da cdimauro

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

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.
A volte se inizi il refactoring ti capita di andare in loop e di perderci troppo tempo... ci vuole anche un pò di disciplina!

[minerte]

Originariamente inviato da ^TiGeRShArK^

In italia è un mondo a parte.

Serve qualcuno a londra?

[^TiGeRShArK^]

Originariamente inviato da minerte

Serve qualcuno a londra?

Per ora no che io sappia.

[tomminno]

Originariamente inviato da ^TiGeRShArK^

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.

[cdimauro]

Originariamente inviato da Kralizek

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.

Originariamente inviato da ^TiGeRShArK^

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.
A volte se inizi il refactoring ti capita di andare in loop e di perderci troppo tempo... ci vuole anche un pò di disciplina!

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.

[tomminno]

Originariamente inviato da cdimauro

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.

Eh già ma se la settimana in più non te la danno mai?

[shinya]

Originariamente inviato da tomminno

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

[tomminno]

Originariamente inviato da shinya

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.

[MaxArt]

Ahahah, giusto oggi ho scritto una roba tipo

Codice PHP:

...
else {
   res = this_sucks("fanculo");
} 


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.

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! "
Se questo non capita, non è raro che ripensi tutta la cosa da zero.

[Kralizek]

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

[cdimauro]

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

Originariamente inviato da tomminno

Eh già ma se la settimana in più non te la danno mai?

Ma io mica l'ho chiesta.

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.

Originariamente inviato da shinya

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 è? 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 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".

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.

Originariamente inviato da tomminno

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.

Originariamente inviato da MaxArt

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! "
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 ), poi arriva la classica modifica da fare che ti scombussola le cose, e sono costretto ad astrarre il codice e a rifattorizzarre...

[khelidan1980]

Originariamente inviato da Ryuzaki_Eru

Non ci credo

Originariamente inviato da Kralizek

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]

Originariamente inviato da Kralizek

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

Originariamente inviato da khelidan1980

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