[71104]

Originariamente inviato da Bonfo

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 ), qua non è che possiamo riorganizzare tutto il repository adesso che siamo arrivati a metà progetto
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 )

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

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 ); 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 ), 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 !!!

fek dice che è una buona idea
scherzo