[vari]Reinventare la ruota

[javaboy]

Prendo spunto dalla frase che ho nella mia firma:

If you have a new fundamental assumption, throw away your old code and rewrite it from scratch. Incremental patching and modifying seems easier at first, and is the normal course of things in software development, but ends up being much harder and producing bulkier, markedly inferior code in the long run.


La frase è di Michael Abrash (guru dell'assembly x86, è ideatore dell'architettura del processore intel larrabee, ha lavorato sul kernel di windows e sull'engine di quake) ed è conosciuta come carmack's law.


Nella mia esperienza lavorativa (principalmente grossi progetti real time in c++) questa "legge" non l'ho mai vista mettere in pratica. Bisogna trascinarsi dietro codice vecchio di 20 anni, mal progettato, mal scritto e mal documentato perchè va bene perdere 2 anni a mettere le pezze ad una vecchia carcassa ma non va bene riscrivere il software da zero in un anno perchè si "reinventa la ruota".
Allo stesso modo certe volte si tende ad esagerare con l'utilizzo dei framework. Se è necessario implementare una particolare funzionalità e questa viene offerta da un framework LO SI DEVE USARE PER FORZA anche se magari l'utilizzo del framework ti porta a snaturare completamente l'architettura dell'applicazione e a buttar giù tutti i santi dal calendario ogni volta che vuoi distaccarti dal comportamento previsto.

Che ne pensate?

[javaboy]

Nella maggior parte dei progetti sui quali ho lavorato ho visto questo genere di cose:

1)Codice assolutamente inutile, morto e abbandonato ma mai cancellato per chissà quale ragione.

2)Interi moduli che facevano la stessa cosa di altri moduli.

3)Classi con oltre 10.000 righe di codice e dalle funzionalità completamente eterogenee

4)Classi diverse create col cut-paste col 99% del codice in comune

5)Varie versioni fun1, fun2, fun3 della stessa funzione modificate a casaccio e mantenute nel caso ci si accorga che forse era meglio quella vecchia...

[PGI-Bis]

In ambito lavorativo penso che la questione che vale per ogni professione valga anche per l'informatica. E' quella del maximus paraculus: se usi gli strumenti più diffusi nell'ambito in cui lavori quando le cose vanno a schifìo dirai che hai fatto ciò che la migliore esperienza del momento storico suggeriva fosse giusto.

E' uno dei cardini dell'irresponsabilità professionale.

Poniamo che io e te scriviamo un programma "enterprise" (significa bubbole ma va bene lo stesso).

Io uso il J2EE, con un database oracle, su un server IBM.
Tu usi un framework che ti inventi tu, con un sistema di immagazzinamento dati che ti inventi tu, il tutto che funziona su un cluster di portatili 386.

Una volta venduti al cliente, entrambi i nostri programmi vanno a puttane e il cliente si becca 25 milioni di euro di danni per downtime.

Di fronte al randello chiodato io posso applicare il maximus paraculus: sono professionista, ho usato le tecnologie profescional che chiunque avrebbe usato, ho usato i pattern, ho usato tutto quello che di stantìio c'è in giro, con un po' di culo risulta che il danno derivi dall'inevitabile fallacia della tecnologia.

Ma tu... oh oh oh, tu sei nella cacca fino al collo! A parità di disastro, infatti, la puttanata profescional è quasi vergine rispetto a quella che non è trita e ritrita.

E' la famosa attività "di concetto": non è importante se il risultato sia l'apocalisse a meno che non sia il frutto di uno scostamento irragionevole dai binari del così fan tutti.

Non è un caso che siano le start-up quelle che apportano le maggiori innovazioni: non hanno clienti che li possano perseguire fino alla morte, sono libere di osare strade diverse.

Nell'ambito non lavorativo, la reinvenzione della ruota è un obbligo morale!

[cdimauro]

@javaboy: il museo degli orrori insomma.

Quando posso riscrivo e/o rifattorizzo il mio codice. Infatti quasi tutto ciò che ho realizzato nei 6 anni che lavoro nella mia azienda, l'ho praticamente riscritto quando ho dovuto rimetterci mano per qualche motivo.

Questo perché col tempo mi vengono in mente nuove soluzioni, o forse più eleganti e/o efficienti per realizzare la stessa cosa. E poi, almeno per me, il codice dev'essere "bello" anche da leggere.

[lupoxxx87]

scrivere codice dev'essere arte ragazzi !

dev'essere semplice da leggere per noi una volta che dobbiamo andare a riguardarlo, ma allo stesso tempo trovare spunti che ci facciano dire "cacchio questo si che è geniale"

se poi vogliamo incasinarlo per obbligare il cliente a tornare da noi...chi più ne ha più ne metta xD

[gugoXX]

Originariamente inviato da javaboy

Prendo spunto dalla frase che ho nella mia firma:
[i]
Nella mia esperienza lavorativa (principalmente grossi progetti real time in c++) questa "legge" non l'ho mai vista mettere in pratica. Bisogna trascinarsi dietro codice vecchio di 20 anni, mal progettato, mal scritto e mal documentato perchè va bene perdere 2 anni a mettere le pezze ad una vecchia carcassa ma non va bene riscrivere il software da zero in un anno perchè si "reinventa la ruota".
Allo stesso modo certe volte si tende ad esagerare con l'utilizzo dei framework. Se è necessario implementare una particolare funzionalità e questa viene offerta da un framework LO SI DEVE USARE PER FORZA anche se magari l'utilizzo del framework ti porta a snaturare completamente l'architettura dell'applicazione e a buttar giù tutti i santi dal calendario ogni volta che vuoi distaccarti dal comportamento previsto.

Che ne pensate?

Che in parte e' vero, tranne per la parte
...ma non va bene riscrivere il software da zero in un anno perchè si "reinventa la ruota".

Ci sono metodologie di progettazione software che permettono di avere un risultato in 1 mese circa, con qualcosa da fare vedere gia' dopo le prime 2 settimane, che possono essere applicate anche alla sostituzione di software vecchi.

E Quoto CDiMauro. La rifattorizzazione e' un punto cardine di queste metodologie. Si procede alla sostituzione parziale di un pezzo alla volta, fino a che si riesce a generalizzare comportamenti, riuscendo quindi a tagliare via intere branche di codice divenuto duplicato.

[Tommo]

Riscrivere da capo tutto, personalmente, è sempre la cosa più irresistibile

Per me è un vero gusto iniziare da 0, mettere giù i mattoni fondamentali, eccetera...
nell'ordine, ho iniziato una decina di giochi, un rasterizzatore software, un traduttore da assembly Z80 a x86, un compressore di files, una rete neurale, un paio di motori grafici e un'AI.
Chiaramente non ho mai finito nulla

Per quanto mi riguarda a questo punto la tentazione di reinventare la ruota (insieme a quella di scrivere sempre codice generico e riusabile (che non è sempre un bene anzi)) è IL MALE, e tento sempre di forzarmi a riciclare altro codice.
Chissà che almeno un gioco non riesca a finirlo

Riassumendo: se si dovesse seguire solo la logica del realizzare programmi eccellenti, si finirebbe continuamente in un ciclo di riscritture, dato che un programma finito è per definizione più brutto di come lo si immaginava.
L'unico modo per realizzare davvero qualcosa è tentare di tenere insieme la baracca anche se è brutta, possibilmente usando tecniche come quelle descritte da cdimauro...

[CwNd]

Originariamente inviato da javaboy

1)Codice assolutamente inutile, morto e abbandonato ma mai cancellato per chissà quale ragione.

La ragione è semplice. Se il codice non lo cancella chi l'ha scritto non lo cancellerà mai nessuno perchè la domanda più naturale che ci si pone in questo caso è "si sputtanerà tutto se cancello questo codice?" e per non avere problemi lo lasci li e fai finta di niente. Un po' come quando trovi il codice commentato e ti chiedi, "perchè è qui? servirà a qualcosa?". Io lo cancello sempre, al massimo tramite svn si riesce a recuperarlo.

Ti consiglio di regalare ai tuoi colleghi questo libro: http://tinyurl.com/ygv6wrm, è un must

[tomminno]

Originariamente inviato da cdimauro

@javaboy: il museo degli orrori insomma.

Normale amministrazione per lo meno anche per la mia esperienza.

Quando posso riscrivo e/o rifattorizzo il mio codice.

Ok per il tuo ma per quello scritto da altri?
Puoi permetterti di rischiare di perderti nei meandri di un programma che magari funziona da anni? Sicuramente non documentato e di cui rischi di perderti qualche "nuanche" nascosta nelle decine di if annidati?
Doppotutto la scadenza è fissa (ed è sempre troppo a ridosso).

Infatti quasi tutto ciò che ho realizzato nei 6 anni che lavoro nella mia azienda, l'ho praticamente riscritto quando ho dovuto rimetterci mano per qualche motivo.

Se la scadenza te lo consente...
Per la mia esperienza non lo consente mai, anche perchè magari ti ci vuole un mese solo per riscrivere quanto esistente e magari la modifica deve finire in produzione in meno di 2 settimane (test inclusi). E da capo progetto se qualcuno mi dicesse questo codice fa schifo lo riscrivo da 0 mi ci vuole 1 mese in più ovviamente gli direi si hai ragione il codice fa schifo, per me puoi fare tutto quello che vuoi ma in 2 settimane deve essere in produzione.
Specialmente perchè i tempi dei progetti sono stimati sul tempo necessario a realizzare la modifica, non per il rifacimento completo.

[tomminno]

Originariamente inviato da gugoXX

E Quoto CDiMauro. La rifattorizzazione e' un punto cardine di queste metodologie. Si procede alla sostituzione parziale di un pezzo alla volta, fino a che si riesce a generalizzare comportamenti, riuscendo quindi a tagliare via intere branche di codice divenuto duplicato.

Si se il software di partenza è scritto abbastanza bene lo puoi fare, ma il tipico codice è talmente interdipendente che sostituire una parte significa dove necessariamente andare a cambiarne anche un'altra e così via a catena fino alla riscrittura completa dell'intero software.
Per non parlare di software realizzati con vecchi linguaggi ormai morti es: VB6 o ASP.
Devi riscrivere tutto da 0 usando un linguaggio più moderno.

[cdimauro]

Aggiungo soltanto un'altra cosa. Alcune volte mi capita di dover mettere mano a codice altrui. Ebbene, quando posso, me lo studio e cerco di estenderlo o trarre spunto.

Ma quasi sempre finisco col chiedere spiegazioni su cosa dovrebbe fare quel codice, per rifarmelo da zero. Perdo molto meno tempo a scrivere il codice dalla descrizione dell'algoritmo, che a cercare di capire cosa fa la sua implementazione scritta da qualcuno.

Sì, a volte reinventare la ruota è decisamente la soluzione "migliore".

[cdimauro]

Originariamente inviato da tomminno

Ok per il tuo ma per quello scritto da altri?
Puoi permetterti di rischiare di perderti nei meandri di un programma che magari funziona da anni? Sicuramente non documentato e di cui rischi di perderti qualche "nuanche" nascosta nelle decine di if annidati?
Doppotutto la scadenza è fissa (ed è sempre troppo a ridosso).

Manco a farlo apposta, ho scritto poco fa un commento a tal proposito riflettendo sugli altri che sono scritti dall'ultima volta che avevo letto il thread.

Se la scadenza te lo consente...
Per la mia esperienza non lo consente mai, anche perchè magari ti ci vuole un mese solo per riscrivere quanto esistente e magari la modifica deve finire in produzione in meno di 2 settimane (test inclusi). E da capo progetto se qualcuno mi dicesse questo codice fa schifo lo riscrivo da 0 mi ci vuole 1 mese in più ovviamente gli direi si hai ragione il codice fa schifo, per me puoi fare tutto quello che vuoi ma in 2 settimane deve essere in produzione.
Specialmente perchè i tempi dei progetti sono stimati sul tempo necessario a realizzare la modifica, non per il rifacimento completo.

Dalla mia ho un paio di vantaggi: in azienda in Python ci lavoro quasi esclusivamente io (adesso finalmente c'è un collega che sta seguendo le mie orme ), e poi con questo linguaggio scrivo codice molto velocemente.

Comunque un po' di tempo per la rifattorizzazione lo si trova. Non dico sempre, ma dopo diversi mesi mi capita di trovare qualche giorno a disposizione per poterlo fare.

Oppure, mentre lavoro a un nuovo progetto o funzionalità per uno esistente, se mi capita di rimettere mano a codice già scritto e mi accorgo che c'è un pattern ricorrente, rifattorizzo solo quel pezzetto, lasciando il resto com'è.

Originariamente inviato da tomminno

Si se il software di partenza è scritto abbastanza bene lo puoi fare, ma il tipico codice è talmente interdipendente che sostituire una parte significa dove necessariamente andare a cambiarne anche un'altra e così via a catena fino alla riscrittura completa dell'intero software.
Per non parlare di software realizzati con vecchi linguaggi ormai morti es: VB6 o ASP.
Devi riscrivere tutto da 0 usando un linguaggio più moderno.

OK, ma a me capita di rado una situazione del genere. Vuoi perché, appunto, ci lavoro soltanto io. Vuoi perché ho la tendenza a scrivere codice con una certa interfaccia ben definita e "stabile" nel tempo, per cui la rifattorizzazione quasi sempre mi comporta un cambiamento dell'implementazione e non dell'interfaccia, quindi garantendo il funzionamento del codice già esistente che ne fa uso.

[tomminno]

Originariamente inviato da cdimauro

Dalla mia ho un paio di vantaggi: in azienda in Python ci lavoro quasi esclusivamente io (adesso finalmente c'è un collega che sta seguendo le mie orme ), e poi con questo linguaggio scrivo codice molto velocemente.

Te parti dalla visione di un progetto portato avanti da una singola persona. Nel mio caso i progetti coinvolgono almeno 3 persone che devono intervenire su parti diverse di un sistema che comporta modifiche a più software. In tali circostanze è impensabile anche solo proporre le tempistiche per la riscrittura.
Poi alle volte date le capacità di chi andrà a mettere mano al codice il risultato di una riscrittura non sarebbe difforme dall'originale...

[astorcas]

io ormai sono entrato nell'ottica "A lavoro scrivo porcherie e a casa mi do all'arte della programmazione". Più che altro è un mix di rassegnazione e menefreghismo

[tomminno]

Originariamente inviato da astorcas

io ormai sono entrato nell'ottica "A lavoro scrivo porcherie e a casa mi do all'arte della programmazione". Più che altro è un mix di rassegnazione e menefreghismo

A volte se vuoi fare un dispetto è più facile riuscirci se scrivi codice con tutti i crismi, in modo che sia praticamente incomprensibile a gente che scrive programmi tutti nel main.

[javaboy]

Originariamente inviato da tomminno

Se la scadenza te lo consente...
Per la mia esperienza non lo consente mai, anche perchè magari ti ci vuole un mese solo per riscrivere quanto esistente e magari la modifica deve finire in produzione in meno di 2 settimane (test inclusi). E da capo progetto se qualcuno mi dicesse questo codice fa schifo lo riscrivo da 0 mi ci vuole 1 mese in più ovviamente gli direi si hai ragione il codice fa schifo, per me puoi fare tutto quello che vuoi ma in 2 settimane deve essere in produzione.
Specialmente perchè i tempi dei progetti sono stimati sul tempo necessario a realizzare la modifica, non per il rifacimento completo.

Il problema è che per rispettare una milestone si produce del codice che moltiplicherà per 10 il tempo necessario a rispettare le milestone successive.
E' necessario trovare il coraggio di fermarsi e buttare il codice vecchio a volte.
Un altro problema è che i programmatori vengono considerati infima manovalanza intercambiabile, non puoi far lavorare una persona per 3 mesi e poi allocarla su un altro progetto passando la patata bollente a un altro che impiegherà mesi a capire quel che è stato fatto dal collega.

[javaboy]

Molto spesso poi manca una figura di programmatore capo o direttore tecnico: ci sono i project manager che perdono completamente il contatto con gli aspetti tecnologici e i programmatori: tutti allo stesso livello, tutti allo sbaraglio.

Ogni programmatore pensa al suo orticello e a soddisfare il requisito nel minor tempo possibile, in questo modo si crea del codice spazzatura.

[astorcas]

Originariamente inviato da javaboy

Molto spesso poi manca una figura di programmatore capo o direttore tecnico: ci sono i project manager che perdono completamente il contatto con gli aspetti tecnologici e i programmatori: tutti allo stesso livello, tutti allo sbaraglio.

Ogni programmatore pensa al suo orticello e a soddisfare il requisito nel minor tempo possibile, in questo modo si crea del codice spazzatura.

bene... dunque è una realtà comune, non solo dei posti dove ho lavorato fino ad ora

[khelidan1980]

Originariamente inviato da javaboy

P
Bisogna trascinarsi dietro codice vecchio di 20 anni, mal progettato, mal scritto e mal documentato perchè va bene perdere 2 anni a mettere le pezze ad una vecchia carcassa ma non va bene riscrivere il software da zero in un anno perchè si "reinventa la ruota".

20 anni? Ti va di lusso qui ci si trascina dietro servizi cobol scritti negli anni 70

Originariamente inviato da javaboy

Nella maggior parte dei progetti sui quali ho lavorato ho visto questo genere di cose:

1)Codice assolutamente inutile, morto e abbandonato ma mai cancellato per chissà quale ragione.

2)Interi moduli che facevano la stessa cosa di altri moduli.

3)Classi con oltre 10.000 righe di codice e dalle funzionalità completamente eterogenee

4)Classi diverse create col cut-paste col 99% del codice in comune

5)Varie versioni fun1, fun2, fun3 della stessa funzione modificate a casaccio e mantenute nel caso ci si accorga che forse era meglio quella vecchia...

Ordinaria amministrazione!

[cdimauro]

Originariamente inviato da tomminno

Te parti dalla visione di un progetto portato avanti da una singola persona. Nel mio caso i progetti coinvolgono almeno 3 persone che devono intervenire su parti diverse di un sistema che comporta modifiche a più software. In tali circostanze è impensabile anche solo proporre le tempistiche per la riscrittura.
Poi alle volte date le capacità di chi andrà a mettere mano al codice il risultato di una riscrittura non sarebbe difforme dall'originale...

Non mi sono spiegato bene allora. La parte a cui lavoro io la gestisco quasi esclusivamente io (a parte il nuovo aiuto; finalmente), ma ai progetti in cui sono coinvolto lavorano diverse persone (con linguaggi diversi).