View Full Version : Consigli da un cretino...
Non so se questo è il posto migliore per dire quello che sto per dire, ma mi sento ancora un po' perso all'interno del progetto...sono qui solo da ieri ;)
In ogni caso appena scaricato dal repository il progetto ho subito notato 2/3 cose:
1) secondo me sarebbe bene che tutto ciò che viene generato (classi, report sui risultati dei test, javadoc, ecc) si atutto contenuto in un'unica cartella target in modo che si veda subito cosa è cancellabile e molto ppiù dove andare subito a cercare i risultati del nostro run.
2)Utilizzando il task ant classpath andare ad aggiungere la cartella lib, in modo da poter lavorare sulle librerie in modo comodo, al punto da far generare dal nostro file ant un jar in lib e veder tutto funzionare senza fatica alcuna
3)Javadoc: esiste??
Ovvero mi sembra che non esista assolutamente documentazione sul codice esistente. Per uno che arriva adesso capire tutto da solo non è affatto facile.
Sarebbe bene pensare di lavorarci sopra e non solo sul codice effettivo, ma creare la documentazione anche del codice per i test
4)Questa è una sottigliezza:
si potrebbe usare il task ant junitreport per ottenere delle belle pagine HTML per vedere i risultati dei test
<!-- Task JUnit with a xml report in a file of name TEST-xxx-->
<target name="junit" depends="compile">
<echo message="==== (JUnit with report) ===="/>
<delete dir="${report.dir}"/>
<mkdir dir="${report.dir}"/>
<junit printsummary="true">
<formatter type="xml" /><!-- usefile="true" per default -->
<test name="TestClass" todir="${report.dir}"/>
<classpath refid="classpath"/>
</junit>
<junitreport todir="${report.dir}">
<fileset dir="${report.dir}">
<include name="TEST-*.xml"/>
</fileset>
<report format="frames" todir="${report.dir}"/>
</junitreport>
</target>
Non so quanto posssa essere utile, probabilmente sto dicendo delle cose ovvie già sapute, valutate e scartate...
...non bannatemi !!! :banned: :ave:
Grazie dell'idea. Quando torno a casa lo faccio :D
Grazie dell'idea. Quando torno a casa lo faccio :D
Oh...un fek che spunta ogni tanto :asd:
basterebbe una bella trasformazione xslt per i report in html :p
1) secondo me sarebbe bene che tutto ciò che viene generato (classi, report sui risultati dei test, javadoc, ecc) si atutto contenuto in un'unica cartella target in modo che si veda subito cosa è cancellabile e molto ppiù dove andare subito a cercare i risultati del nostro run. eh vabbè ciccio (alla milanese :D), qua non è che possiamo riorganizzare tutto il repository adesso che siamo arrivati a metà progetto :D
dai, non ti preoccupare, che anche così è abbastanza chiaro: tu scarica Trunk, poi i sorgenti stanno in src e i class stanno in bin; fine. :)
(volendo mettere i puntini sulle i, spesso abbiamo un problema nel repository che ipotizziamo essere dovuto a Eclipse, il quale mette una copia di tutti i sorgenti anche in bin, e magari questo confonde un attimino le idee :D)
2)Utilizzando il task ant classpath andare ad aggiungere la cartella lib, in modo da poter lavorare sulle librerie in modo comodo, al punto da far generare dal nostro file ant un jar in lib e veder tutto funzionare senza fatica alcuna :wtf:
3)Javadoc: esiste?? no :)
Ovvero mi sembra che non esista assolutamente documentazione sul codice esistente. Per uno che arriva adesso capire tutto da solo non è affatto facile.
Sarebbe bene pensare di lavorarci sopra e non solo sul codice effettivo, ma creare la documentazione anche del codice per i test vedi, dici così perché non conosci la filosofia che adottiamo qui.
qui noi non documentiamo un bel nulla, qui si lavora à la fek; noi usiamo metodologie agili di sviluppo, facciamo extreme programming e test-driven development quasi nella sua forma più dura e cattiva (che è quella in cui si aggiunge UNA SOLA linea di codice ad ogni test :stordita: ); la nostra unica documentazione sono i test: i test determinano il comportamento che il nostro programma deve avere perché un test deve passare, e quindi obbliga il programma a comportarsi in maniera da soddisfarlo; se il test passa vuol dire che il programma si comporta come vogliamo.
di tanto in tanto facciamo anche pair programming; cerca su Wikipedia la spiegazione sulle metodologie agili che ti ho citato. ;)
tu ora dirai che per capire il funzionamento del nostro programma è meglio leggere il codice piuttosto che i test; be':
1) si, è vero, perché noi scriviamo codice estremamente autoesplicativo: scriviamo in maniera il più possibile semplice e lineare (poche indentazioni e pochi if, altrimenti la complessità ciclomatica aumenta, la build oltre un certo valore non la accetta e non passa, e fek ci spezza i ditini :D), per nomi di variabili e funzioni usiamo identificatori anche molto lunghi (tanto qualsiasi IDE moderno ha il completamento automatico), cerchiamo di scrivere in una forma che si possa quasi leggere in inglese, e non usiamo quasi mai i commenti, se non per i TODO: questo perché il nostro codice si spiega da solo, e se serve un commento vuol dire che c'è qualcosa che non va, che il codice è troppo complesso e quindi non può autoesplicarsi (non a caso un TODO altro non è che una nota che ci dice che lì va sistemato qualcosa).
2) no, non è vero; primo perché anche i test sono scritti secondo le stesse regole di semplicità e linearità, ma spesso sono anche molto più semplici del codice stesso (guarda tu stesso); e poi la documentazione sono i test, sono i test che dovrebbero dirti come si comporta il programma.
3) scegli tu se è vero o no: per capire bene il funzionamento del nostro codice certe volte ti aiuta di più leggere il codice, certe altre ti aiuta di più leggere i test; ma ad ogni modo scrivere righe di documentazione è inutile, è una perdita di tempo. ;)
4)Questa è una sottigliezza:
si potrebbe usare il task ant junitreport per ottenere delle belle pagine HTML per vedere i risultati dei test
[...]la sottigliezza non era male :)
Non so quanto posssa essere utile, probabilmente sto dicendo delle cose ovvie già sapute, valutate e scartate...
...non bannatemi !!! :banned: :ave: fek dice che è una buona idea :D
scherzo ;)
Poi il Javadoc non ci serve...non ci sono volutamente commenti nel progetto, il codice deve essere autoesplicativo...
Semmai potrebbe essere utile la generazione automatica della documentazione UML ad ogni build...
+ una generazione automatica di code coverage...appena torna fek... ;)
Non sapete quanto sono felice!!!!
Dovete sapere che ho da poco seguito un corso di Ingegnreia del Software della laurea specialistica,quindi ho già un idea delle metodologie esposte...però il prof è riuscito a parlare di aria fritta per 1 mese....tutta roba campata per aria e con poco senso...
...qui invece ho visto come le stesse cose si possano toccare con mano ed essere espresse in modo chiaro e senza troppi voli pindarici.
GRAZIE!!!! :ave:
Ora veniamo al cuore della questione:
1)Avevo intuito l'uso del TDD, ma non pensavo foste così "cattivi"... :D
Ho notato il codice snello, compatto o chiaro e ho anche capito che mi scordo i javadoc :cry: :D anche se dire che la documentazione è inutile mi trova poco d'accordo...probabilmente nel software è tra le cose più delicate e non viene mai presa sul serio a sufficenza.
Devo però dire che la vostra scelta non è per faciloneria ma per scelta di un processo di sviluppo ben definito, quindi IMPARO, IMAPRO, IMPARO.... :D :D
2)71104 hai ragione sul repository...me lo tengo così :D
3)per il code coverage c'è JCoverage e dovrebbe funzionare bene in automatico
4)Mi sembra di aver trovato una volta un tool Java->UML e UML->Java...se lo trovo lo posto
5)per il classpath...sono stato poco chiaro e riprovo per maggiore chiarezza
Soprattutto nel caso di più progetti o progetti ampi in cui e necessario farsi delle librerie, è utile farsi un cartella lib (come ovviamente è stato già fatto) e aggiungerla al classpath di ant in modo tale che la possa usare durante le compilazioni.
In questo modo posso far si che il build ant di ogni sotto-progetto o libreria generi un file jar contenente tutte le classi che mi interessano e farglelo mettere in lib, in modo che il buil di un'altro progetto possa sfruttare quelle librerie da me fatte.
Ora nell'ottica di un file build "generale" che mette in esecuzione ant per ogni sottoprogetto con relativo file build, abbiamo la genereazione delle librerie e della applicazione tutto in un colpo.
Spero di essere stato più chiaro, anche se ho la sensazione di aver solo peggiorato :wtf:
Ciao
1)Avevo intuito l'uso del TDD, ma non pensavo foste così "cattivi"... :D
Ho notato il codice snello, compatto o chiaro e ho anche capito che mi scordo i javadoc :cry: :D anche se dire che la documentazione è inutile mi trova poco d'accordo...probabilmente nel software è tra le cose più delicate e non viene mai presa sul serio a sufficenza.
Devo però dire che la vostra scelta non è per faciloneria ma per scelta di un processo di sviluppo ben definito, quindi IMPARO, IMAPRO, IMPARO.... :D :D
Il problema del tenere un documentazione (a quanto ho capito) è che avendo il design che può cambiare sempre da un momento all'altro anche la documentazione andrebbe sempre cambiata, il che farebbe perdere parecchio tempo. Comunque era saltata fuori l'idea (non ricordo da chi ^^) di mettere un wiki
3)per il code coverage c'è JCoverage e dovrebbe funzionare bene in automatico
Per questo avevo già accennato qualcosa a fek che sembrava d'accordo, e ne ho parlato con vicius.
Qua ce ne sono un pò di code coverage: http://www.xpdeveloper.com/xpdwiki/Wiki.jsp?page=CodeCoverageTools
Inoltre non sarebbe male anche un mutation testing (cambia in modo automatico i valori nei test e verifica se coincidono): http://jester.sourceforge.net/
4)Mi sembra di aver trovato una volta un tool Java->UML e UML->Java...se lo trovo lo posto
Interessante, anche se mi devo ancora vedere qualcosa sull'UML che non conosco :Prrr:
Ho un po' googlato...
....e di tool Java->UML ce ne sono tanti...ma mi sembar che di tool AUTOMATICI, ovvero compatibili con un processo automatico come ant, non ce ne siano :muro: :muro: ...mi sa che dovrò nadare a caccia con il lumino ;)
Ciao
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.