Newsgroup: it.comp.java
Titolo: Pulizia del codice.

Sto lavorando ad un progetto che necessita di effettuare uno
"snellimento" nel senso di eliminare le classi/metodi che non vengono
utilizzate e che quindi risultano inutili. C'è da dire che da
specifiche devo lasciare i get & set e fare attenzione perchè alcune
classi che sono istanziate per reflection e quindi non vanno toccate.
Considerando che fare questo lavoro a mano è praticamente impossibile,
o meglio ci vorrebbero settimane (ogni pacchetto contiene qualche
migliaio di classi) sapete consigliarmi qualche software che faccia il
tutto senza il rischio di fare grossi danni? Magari anche un plug-in
di Eclipse sarebbe utile, ovviamente il tutto non troppo automatizzato
e comunque sotto la mia supervisione.
Grazie a chi mi aiuterà perdendo 5 min del suo tempo in questa calda
giornata di agosto :-)
Ciro

 e comunque sotto la mia supervisione.
mi sembra una cosa davvero rischiosa da fare, nonchè inutile...
a fronte di pochi KB guadagnati in spazio occupato, dovresti ALMENO
ripartire da zero coi test di funzionamento... ne vale la pena ?
so che i frameworks professionali per il testing ti permettono
di monitorare un'applicazione in funzione creando reports su chi
invoca cosa, quando e perchè... ma credo che anche analizzare quei
grafi ti porterebbe via mesi....

 grafi ti porterebbe via mesi....
Per il momento ho ottenuto buoni/ottimi risultati con l'offuscamento
del codice tramite ProGuard un tool open molto intuitivo. Di fatto
l'offuscamento sfrutta le stesse semantiche degli algoritmi di
compressione quindi è una strategia che può essere utile senza un
grosso dispendio di energia e riducendo i rischi di "tagliare" cose
che possono compromettere il tutto.
Ciro

 ripartire da zero coi test di funzionamento... ne vale la pena ?
Il codice che non c'è è l'unico codice bug-free.
-- 
By ZeD

 che possono compromettere il tutto.
si, comprimere invece di modificare può essere un'approccio comodo
hai provato qualcuno di quei tool  di ottimizzazione, che sostituicono
blocchi di codice complesso con algoritmi equivalenti semplificati ?
secondo me sono come giocare col fuoco, però non si sa mai....
-- 

> Il codice che non c'è è l'unico codice bug-free.
volendo sorvolare sul fatto che un metodo mai
invocato è innoquo, sia che tu lo tolga che no...
il fatto è che monitorare l'applicazione per settimane in cerca
di roba da cancellare ti consente contemporaneamente di fare uno
splendido lavoro di debugging... ma se a quel punto vai a modificare
i sorgenti hai vanificato tutto...
a meno di esigenze specifiche, meglio qualche KB i meno di codice,
o l'aver eseguito approfonditi test di funzionamento ?
-- 

 tutto senza il rischio di fare grossi danni?
L'unico modo per non fare danni e` non toccare nulla. riguardo al tuo
problema, prova con un profiler e, se hai abbastanza potere sul
progetto, imponi l'uso di standard di programmazione e di documentazione
del codice al gruppo di programmatori
Enrico

 utilizzate e che quindi risultano inutili.
senti, te lo dico schiettamente: se il codice funziona ripulirlo da 
parti inutilizzate non � una priorit�.
non dico che il codice non sia bene pulirlo, tuttaltro, solo che � 
sbagliato farlo in una attivit� apposta una tantum. per una questione di 
costi, di fattibilit�, di risultati e tanto altro.
� realisticamente pi� fattibile stabilire regole di sviluppo e di 
refactoring, per cui ogni volta che si tocca il codice pregresso si 
fanno opportune operazioni di pulizia. e ovviamente per i nuovi sviluppi 
si fa in modo di non perdere il controllo... perch� sinceramente questo 
fatto che ad un certo punto non sai pi� come rintracciare il codice 
usato da quello obsoleto � abbastanza inquietante, la reflection c'entra 
relativamente poco, forse va capito meglio se metodi di sviluppo e 
framework utilizzati sono adeguati.
-- 
++ questo messaggio � scritto in forma ridotta per venire incontro alle 
vostre capacit� mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 fanno opportune operazioni di pulizia
... e si rifannno girare da capo tutte le suite di test per avere una
ragionevole certezza di non aver fatto cazz.... ehm... casini :D

Il 22/08/09 01:12, STB_Caos ha scritto:

suite che dovresti comunque adattare e far girare avendo fatto le 
modifiche, se usi una strategia test driven.
-- 
++ questo messaggio è scritto in forma ridotta per venire incontro alle 
vostre capacità mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/


Seeee, figurati se in un progetto cosi' alla deriva hanno i test driven, le
suite o usano tecniche di refactoring .....
Ciao
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 le suite o usano tecniche di refactoring .....
non serve mica avere un progetto alla deriva perchè qualcuno
ti chieda di fare cose stupide come "ripulire" il codice...
basta che il *solito* manager so-tutto-io decida che è una OTTIMA
idea... specie se è il *solito* giovane laureato con lode in
economia e marketing, che SA LUI come deve essere il prodotto
per sfondare sul mercato...

per sfondare sul mercato...
Di sicuro non si impunter� su cose come la pulizia del codice sorgente,
concetto che magari gli � oscuro. I brillantoni  tendono a rompere sul
look and feel, sul pulsante accattivante, sui dettagli, non sulla sostanza.
Scorpio 

 sostanza.
non so, a me pare una classica *ideona* da manager rampante quella
di potare il codice per risparmiare sulla banda... me lo vedo il
sapientino in completo grigio col blackberry ultimo modello che
sa appena accendere: "comprare altra banda ci costa troppo, riducete
la roba da trasferire"... :D

 --
No però adesso ci do un occhio, fatto sta che nè io nè il mio
capoprogetto amiamo molto i sistemi automatizzati però vale la pena
tentare. ;-)
Grazie del consiglio.
Ciro

 framework utilizzati sono adeguati.
La tua riflessione è quantomai giusta ma quando si fa parte di una
un'area di azienda che si chiama "Sviluppo e ricerca di nuovi
prodotti" è difficile avere una linea guida troppo rigida. Molto
spesso capita che parti da un progetto per fare una cosa e poi finisci
in tutt'altro solo per scelte commerciali e quindi per ridurre tempi e
costi di sviluppo si cerca di utilizzare del codice già scritto in
altre occasioni. L'applicazione di cui parlo in questo thread infatti
è un kernel sui cui vengono montante 4-5 applicazioni diverse ognuno
con caratteristiche simili ma non di certo equivalenti e soprattutto
con esigenze differenti. E' normale che dopo 5-6 anni di sviluppo ci
siano parti del codice inutilizzato è una cosa normale e se non fosse
che abbiamo una ridotta banda di rete nemmeno ci saremmo posti il
problema di ridurre le dimensioni.
Ciro

 la roba da trasferire"... :D
Il problema non è comprarla, il problema è che non si può proprio
avere, queste applicazioni vanno inviate tramite GPRS ad un pc
industriale che sfreccia a 300km/h in giro per tutto lo stivale e come
dicevo più su anche un risparmio di 50kb sul totale può essere un
vantaggio a patto ovviamente di non compromettere nulla ai fini della
funzionalità.
Ciro


Beh definire un progetto alla deriva e dubitare della professionalità
di chi ci lavora non mi sembra un buon approccio ad una discussione.
Ti posso assicurare che il refactoring e il test driven li usiamo e
come il punto è che dopo anni di sviluppo è normale che ci sia del
codice obsoleto e/o non utilizzato, hai voglia ad applicare alla
lettera i criteri dell'ingegneria del software.
Ciro

 Scorpio
Parole sante, prima si fa' a cazzotti con il grafico e poi con il
commerciale è un classico di ogni programmatore. :-D
Ciro

 funzionalità.
auguri, vi aspetta un luuuuungo lavoro ;)

 Ciro
solo per capire meglio il problema, dato che 30-50kB sembrano farti comodo:
1) quanto pesa tutta l'applicazione? (hai parlato di migliaia di classi)
2) � impossibile fare un aggiornamento differenziale o incrementale?
--
sv.

 2) è impossibile fare un aggiornamento differenziale o incrementale?
E già dotata di aggiornamento differenziale ed ogni componente viene
inviato  compresso in tar.gz con delflate sulla macchina remota.
Ovviamente non sempre l'aggiornamento differenziale è applicabile,
dipende dalla situazione soprattutto per quanto riguarda le nuove
feature e visto che stiamo facendo ottimizzazione guardiamo sempre il
caso peggiore.
Ciro

 sostanza.
Cosa vitale e di assoluta importanza per il successo di un prodotto.  
Ricordiamoci che i nostri prodotti li usano gli essere umani, gli utenti,  
il cui 80%-90% non gli interessa se il tuo bel ciclo for e' ottimizzato,  
ma se il workflow e' semplice, e perche no, gradevole alla vista,  
apprezzera il prodotto = venderai di piu. Ad ogni modo, credo che l'ordine  
nel codice sia altrettanto fondamentale, non fosse altro che per la  
santia' mentale di chi ci deve lavorare.
Ciao,
Co

La precedente era una considerazione di carattere generale, non credo che  
su un app di un mega che va trasferita via gprs si faccia i pignoli sulla  
UI ( se UI esiste :) )

 Cosa vitale e di assoluta importanza per il successo di un prodotto.
E chi lo nega ? E' assolutamente fondamentale, concordo: per� capisci
che nel post precedente, l'idea del laureato in economia e commercio che
si "lancia" in considerazioni relativi alla banda di trasferimento dati 
lascia un po'
il tempo che trova :-)
Il mio era un post semiserio :-)
Scorpio 


E invece c'è anche quella, quindi si cerca di ottimizzare la
dimensione delle immagini, si massimizza l'uso dei componenti nativi
per evitare librerie esterne, insomma è un lavoraccio, affascinante
sicuramente perchè impari cose che in altri contesti difficilmente
applicheresti e in più ti abitui a scrivere codice ottimizzato, però
delle volte il collo di bottiglia rete/hw della macchina diventa
asfissiante. Il punto è che certe applicazioni non dovrebbero essere
scritte in Java però quando non hai il controllo dell' hw su cui
vengono installate le applicazioni, la portabilità diventa una
priorità.
Ciro

 Il mio era un post semiserio :-)
Il punto è che non lo fanno solo i giovani laureati in economia, il
nostro commerciale (dirigente di tutta la struttura) ha più di 60 anni
e ogni tanto se ne esce con delle genialate da ROTFL cubico, eppure in
un modo o nell'altro bisogna accontentarlo e quindi si gioca la
partita tutto sul compromesso :-)
Ciro

Ciao Ciro,
  se hai un buon insieme di test, io proverei Cobertura [1].
Attenzione che Cobertura NON ti dir� quali metodi non
sono MAI usati, ma quali parti di codice sono "coperte"
dai tuoi unit test.
Quindi se i tuoi test coprono tutti i casi che ti interessano,
bene. In caso contrario, prima scrivi i test, poi lanci Cobertura.
Ciao,
  Guido.
[1]: 
http://cobertura.sourceforge.net/index.html

 bene. In caso contrario, prima scrivi i test, poi lanci Cobertura.
scusa ma non capisco cosa c'entri la stima di copertura con
l'identificazione  del codice inutilizzato; al massimo potrà
dirti se hai scritto dei test decenti...
tra l'altro se hai scritto test che coprono solo i casi che
ti interessano, hai fatto un gran brutto lavoro ed è il caso
che tu ci metta una pezza MOLTO PRIMA di metterti a cancellare
roba che reputi inutile...
mi permetto poi un piccolo appunto davvero cavilloso ;)
le stime di copertura non riescono a dirti se in un codice complesso
(pieno di if-else, switch, cicli innestati etc) vengono prima o poi
eseguiti tutti i blocchi... può succedere che reciclando del codice
complesso ci si ritrova a non usarlo "tutto", perchè nelle nuove
condizioni alcune parti non verranno mai usate...
magari invece di cancellare metodi conviene controllare che gli
algoritmi non siano ridondanti