riflessioni personali: organizzazione e metodi di lavoro

[Giakino]

Originariamente inviato da Giakino

Uhm, forse è che sono abituato a fare direttamente in maniera visuale per inserire qualcosa (lo sò, è un metodo sbagliato, infatti pian piano sto studiando anche per fare tutto solo da codice)
Però mi sfugge una cosa, qual'è proprio il modo per creare dei test? Cioè, devo pensare e vedere nella palla di cristallo che quel determinato metodo avrà determinati problemi che devo prevedere oppure esiste un modo per creare/pensare in maniera più semplice un test? Se ora ne dovessi scrivere uno non saprei nemmeno da che parte iniziare
Tornando all'esempio del programma di videoscrittura, quali potrebbero essere dei test iniziali?
fek/vicius mostrateci i vostri arcani poteri...
Per spike = semplice esperimento di programmazione più nello specifico cosa s'intende?

[cionci]

Giakino: prima di tutto bisogna suddividere il lavoro in storie...

Ad esempio: un prima storia potrebbe essere aprire una finestra usando il framework scelto e visualizzare un dialog con scritto HelloWorld...

La storia va suddivisa in task...per ogni task bisogna studiare i rispettivi test...

Ad esempio, se un task è: creare un dialog con il framework scelto

Il test sarà:

void testDialogCreation()
{
   Dialog dialog = new Dialog();
   assertFalse(dialog.isCreated()); //questa assertion si può fare bene o male con tutti i framwork

   dialog.create();
   assertTrue(dialog.isCreated());

   dialog.destroy():
   assertFalse(dialog.isCreated());
}

Un altro task sarà: visualizzare il messaggio "Hello World!" nel Dialog
Il test sarà:

void testDialogTextDisplay()
{
   Dialog dialog = new Dialog();

   dialog.setText("Hello World!");

   dialog.create();

   assertEqual(dialog.getText(), "Hello World!");

   dialog.destroy():
   assertFalse(dialog.isCreated());
}

[end.is.forever]

Ho letto un po' di generalizzazioni a mio parere azzardate, dico la mia su quello che penso sia lo sviluppo del software.
Innanzitutto UML non ha niente a che vedere con il processo di sviluppo del software, è un linguaggio che permette di descrivere una grande varietà di sistemi.

La progettazione e il design non sono assolutamente legate ad un linguaggio come l'UML (in molti casi l'output di queste fasi può essere descritto in linguaggio naturale, o con un insieme di interfacce java o di classi o con diagrammi entity-relationship, o con uno schema XML, o anche con un file XML), mi sembra che qui si stia un po' perdendo di vista cosa siano queste fasi nel processo e perchè servano.

Il loro scopo (delle fasi, non dell'UML) è quello di fornire ad altri una descrizione del sistema, non certo quella di fare schemini per noi per non sbagliare dopo o per perdere del tempo.
Ed è anche un ottimo modo per suddividere il lavoro.

Il processo di sviluppo del software è diventato un procedimento industriale, che necessita di formalismi per definire le varie fasi e per suddividere e identificare le responsabilità.

Chi deve costruire un palazzo sicuramente prima di prendere in mano i suoi strumenti (o molto più spesso di dire a qualcun'altro di farlo), sicuramente farà un progetto, e avrà una sua metodologia per pensare cosa fare, ma soprattutto per descrivere a chi lo paga in che modo agirà e perchè ha deciso di optare per una scelta invece che un'altra.

Ovviamente se deve costruire una casetta per cani per i fatti suoi non gli verrà mai in mente di fare una cosa del genere.
Allo stesso modo se io un giorno voglio farmi un programmino per me che mi serve non mi metterò mai a scrivere documenti del genere, ma molto più probabilmente aprirò un qualche ambiente di sviluppo e inizierò a scrivere man mano quello che mi viene in mente.

Ma se un giorno mi commissionassero di realizzare un sistema operativo, un dbms, un software intelligente o quant'altro, di sicuro mi passerebbe per la testa di stabilire prima cosa fare, e di farlo in un modo che permetta a chi mi paga di verificare quello che sto facendo, e a lavoro finito quello che ho fatto.
Senza parlare del fatto che sicuramente cercherei qualcuno che mi aiutasse e farei in modo da potergli descrivere quello che voglio che faccia.

Poi che ci siano diverse metodologie per organizzare il lavoro tra più persone e in più fasi, su questo non c'è dubbio, ma non confondiamo extreme programming con "scrivo codice senza pensare" oppure il processo test-driven con una sorta di debugging anticipato.
Sono metodi ben più articolati, che richiedono altrettanta organizzazione, esperienza e capacità di quelli "vecchio stile".

[cionci]

Originariamente inviato da end.is.forever

ma non confondiamo extreme programming con "scrivo codice senza pensare" oppure il processo test-driven con una sorta di debugging anticipato.

Ma chi l'ha scritto questo ?

Come ho detto più volte la progettazione ci deve essere sia all'inizio che durante ogni fase dello sviluppo anche con il metodo che stiamo utilizzando per Diamonds...

Riguardo alle necessità che esprimi nel tuo post...sono tutte rispettate dalla metodologia che applichiamo...

[end.is.forever]

Originariamente inviato da cionci

Ma chi l'ha scritto questo ?

Come ho detto più volte la progettazione ci deve essere sia all'inizio che durante ogni fase dello sviluppo anche con il metodo che stiamo utilizzando per Diamonds...

Riguardo alle necessità che esprimi nel tuo post...sono tutte rispettate dalla metodologia che applichiamo...

Non so nulla del vostro progetto, parlo di quello che mi sembrava essere il tema del topic.
Se poi anche tu sei d'accordo meglio.

[cionci]

Originariamente inviato da end.is.forever

Se poi anche tu sei d'accordo meglio.

Certo, l'avevo scritto anche prima

Originariamente inviato da end.is.forever

Non so nulla del vostro progetto

Dai un'occhiata e magari partecipa

[71104]

@Giakino: quello che ti ha detto cionci è come stiamo facendo noi; il termine "storia" ad es. fa parte della terminologia che usiamo noi, non penso la si usi altrove... inoltre il codice che ti ha mostrato cionci è scritto in Java (il linguaggio che stiamo usando noi); aggiungo che noi stiamo usando JUnit, un framework che facilita lo sviluppo e l'esecuzione di test automatici.
quindi quello che diceva lui era per fare un esempio pratico, ma nulla toglie che il tutto si possa generalizzare ad altri linguaggi di programmazione e ad altre metodologie di sviluppo (non è mica necessario procedere col "metodo alla fek" per utilizzare il TDD).
se non hai ben capito cos'è uno spike cerco di spiegarmi meglio con un esempio pratico; tornando al programma di videoscrittura, mettiamo che un team vuole svilupparlo solo per Windows (diciamo che il team vuole fare qualcosa di molto simile a Ms Word): se nessuno del team ha mai lavorato con le Win32, sicuramente dovrà fare moltissimi spikes, cioè programmetti per sperimentare le funzionalitàdelle Win32; esempi: un programma Win32 che apra una semplice finestra Windows, un altro programma che sperimenti l'utilizzo di una toolbar con dei pulsanti i cui command id sono associati a quelli di un menu, ecc.
nota bene: le condizioni che ho ipotizzato qui erano solo per poterti fare degli esempio e sono estremamente improbabili: se nessuno del team ha mai lavorato in Win32 è molto difficile che il team possa realizzare qualcosa di grosso, e inoltre nessuno sano di mente userebbe mai Win32 direttamente per creare grossi softwares (Office ad es. è fatto in MFC).

[Angus]

Da quello che è emerso finora mi sembra di capire che per il vostro esperimento stiate proprio battendo la 'via di mezzo': di tutto un pò e solo quando è indispensabile.
Qualche estremista si è presentato e ha detto la sua, ma non ha portato a mio parere argomentazioni convincenti a favore dell'una o dell'altra posizione.
Personalmente faccio il tifo per voi: ho cominciato a fare spikes quattro anni fa e mi ricordate quando ho iniziato a lavorare.
Vorrei però ribadire che per produttività bisogna intendere non solo la risoluzione di obiettivi a breve termine, ma anche tutto il contorno di un progetto. Attualmente sto lavorando anche a progetti cominciati quasi tre anni fa e in tutto questo tempo accadono cose che, per inesperienza, non si sa gestire: nuovi elementi del team che arrivano, altri che lasciano, documentazione insufficiente, errori di progettazione funzionale, cambi in corsa di tecnologie ormai obsolete...
Insomma un pò tutto il discorso mi ricorda la battaglia tra Java e Python per dirne una.

Qualche domanda però devo farvela:
In che fase della vostra metodologia cercate di suddividere l'applicazione in moduli (quasi) indipendenti?
Che politiche/strumenti adottate contro lo spaghetti code e a favore del riutilizzo del codice?
Chi prende le decisioni?

[cdimauro]

Una risposta per tutto: fek.

[Giakino]

Capito... java lo sto studiando (poco alla volta perchè il tempo è sempre troppo poco ), poi mi metterò a fare qualche piccolo esperimento. Ora vado alla ricerca di informazioni sull'XP (ho già trovato un sito carino in italiano )

[^TiGeRShArK^]

Originariamente inviato da Angus

CUT

una cosa ke ancora se non sbaglio è emersa è il massiccio uso di codice auto-commentante...
la finalità dei commenti infatti deve essere di spiegare perchè si fa una certa cosa in un metodo non COSA fa quel metodo.
Quindi è possibile spiegare il COSA fa quel metodo nel modo più semplice:
ovvero utilizzando dei metodi molto spcializzati che abbiano un nome autoesplicativo.
Un passo fondamentale del TDD è infatti il continuo refactoring.
Praticamente la orima cosa da fare è scrivere il test. Quindi si scrive il codice minimo ke fa passare il test e infine si implementa il metodo.
Una volta implementato il metodo però c'è ancora la fase del refactoring.
Infatti il metodo ks ottenuto sarà molto probabilmente MOLTO lontano da essere un codice "bello e funzionale". Così si procede col refactoring come si ritiene più opportuno per rendere il codice più auto-esplicativo possibile, per far si ke una classe svolga uno ed un solo compito (se una classe è troppo grande allora molto probabilmente fa qualkosa di più di quanto gli compete), e per renderlo di più facile comprensione per chi deve leggere il codice.
La cosa bella è ke grazie ai test appena scritti siamo al sicuro, dato ke anke se commettiamo un errore nel refactoring, ce ne accorgiamo subito perchè qualke test fallirà.

Per ulteriori informazioni vi consiglio di dare un okkiata al nostro codice (ma è di pubblico dominio ora ke c penso? suppongo d si! feeek, viicius, cionciiii! ) così vi renderete conto di come sia ben strutturato senza aver effettuato alcuna progettazione UML et similia a monte, ma utilizzando bensì una progettazione continua durante tutta la scrittura del codice...

[Angus]

Originariamente inviato da ^TiGeRShArK^

*snip*
La cosa bella è ke grazie ai test appena scritti siamo al sicuro, dato ke anke se commettiamo un errore nel refactoring, ce ne accorgiamo subito perchè qualke test fallirà.
*snip*

E' una lama a doppio taglio... Ma non voglio star qui a discutere di quale sia la migliore strategia, ho già espresso il mio parere.
Da quello che dici vai molto orgoglioso della struttura del codice che sta venendo fuori 'da sola'. Ma finora sembra che col refactoring vi preoccupiate di eliminare lo 'spaghetti-code', ma in quale momento cercate di capire se la struttura ad alto livello è buona o no? Per buona intendo non ridondante, con codice centralizzato, e facilmente manutenibile ed estensibile?
C'è qualcuno che se ne occupa?

[71104]

Originariamente inviato da Angus

E' una lama a doppio taglio... Ma non voglio star qui a discutere di quale sia la migliore strategia, ho già espresso il mio parere.
Da quello che dici vai molto orgoglioso della struttura del codice che sta venendo fuori 'da sola'. Ma finora sembra che col refactoring vi preoccupiate di eliminare lo 'spaghetti-code', ma in quale momento cercate di capire se la struttura ad alto livello è buona o no? Per buona intendo non ridondante, con codice centralizzato, e facilmente manutenibile ed estensibile?
C'è qualcuno che se ne occupa?

si, praticamente VICIUS
comunque a parte tutto nonostante l'esperienza di Diamonds io non riesco proprio ad apprezzare il valore del TDD: secondo me questi test hanno un costo di manutenzione troppo alto perché ad ogni refactoring i test ovviamente falliscono, e spesso non è il codice che non va, sono proprio i test (vanno mantenuti anch'essi).
se il punto forte di una qualsiasi metodologia è agire poco producendo molto, i test causano esattamente il contrario: fanno agire precisamente il doppio del necessario (se non di più).
i test sono l'unico punto della metodologia di fek sui quali non concordo.

[cionci]

Originariamente inviato da 71104

i test sono l'unico punto della metodologia di fek sui quali non concordo.

In pratica non concordi con la metodologia fek in toto...la TDD è il punto fondamentale... Altrimenti non si potrebbe applicare tutto il metodo...

Comunque non è vero che i test hanno bisogno di manutenzione, se ne avessero bisogno allora sono stati scritti male... Inoltre Eclipse aiuta con il refactoring, visto che c'è la possibilità di cambiare il nome ai metodi cambiando automaticamente tutte le occorrenze nel codice... Con questo raramente bisogna rimettere mano ai test...

[Angus]

Originariamente inviato da cionci

*snip*
Inoltre Eclipse aiuta con il refactoring, visto che c'è la possibilità di cambiare il nome ai metodi cambiando automaticamente tutte le occorrenze nel codice... Con questo raramente bisogna rimettere mano ai test...
*snip*

TDD: Tool Driven Development

[cionci]

Originariamente inviato da Angus

TDD: Tool Driven Development

IMHO molte metodologie di sviluppo non sono applicabili senza gli adeguati strumenti... Ad esempio fare i diagrammi UML a mano richiederebbe tempi di qualche ordine maggiori rispetto a farli con un tool ad hoc... Stessa cosa per il TDD, senza Eclipse che aiuta nel refactoring bisognerebbe rimettere mano ai test ogni volta che si rinominano i metodi (e a gran parte del codice)...

[^TiGeRShArK^]

Originariamente inviato da Angus

E' una lama a doppio taglio... Ma non voglio star qui a discutere di quale sia la migliore strategia, ho già espresso il mio parere.
Da quello che dici vai molto orgoglioso della struttura del codice che sta venendo fuori 'da sola'. Ma finora sembra che col refactoring vi preoccupiate di eliminare lo 'spaghetti-code', ma in quale momento cercate di capire se la struttura ad alto livello è buona o no? Per buona intendo non ridondante, con codice centralizzato, e facilmente manutenibile ed estensibile?
C'è qualcuno che se ne occupa?

ovviamente col refactoring intendevo anke l'eliminazione delle duplicazioni e delle ridondanze, anzi questo è uno dei punti principali, soprattutto all'interno dei test.
Inoltre queste operazioni dovrebbero essere un pò tutti a farle...
vista l'elevata leggibilità del codice chiunque può mettere mano al codice quando vede qualcosa ke non lo convince e effettuare del refactoring per migliorarne la struttura.

dimenticavo un messaggio subliminale:
LEGGETE EXTREME PROGRAMMING ADVENTURES IN C#

[Angus]

Originariamente inviato da cionci

IMHO molte metodologie di sviluppo non sono applicabili senza gli adeguati strumenti... Ad esempio fare i diagrammi UML a mano richiederebbe tempi di qualche ordine maggiori rispetto a farli con un tool ad hoc... Stessa cosa per il TDD, senza Eclipse che aiuta nel refactoring bisognerebbe rimettere mano ai test ogni volta che si rinominano i metodi (e a gran parte del codice)...

Ovviamente concordo in pieno.

[cionci]

Inoltre abbiamo dei canoni strettissimi di complessità da rispettare per metodi e classi (addirittura per le espressioni)...e questo permette una elevata leggibilità del codice...
Se questi canoni non sono rispettati la build con ant fallisce e quindi fino a quando non si sono raggiunti i canoni non dovrebbe essere fatto il commit...

[leadergl]

sto seguendo con molto interesse questa discussione ed il progetto, Diamonds, su cui state lavorando...però volevo farvi alcune domande...

sono studente in informatica e quindi queste cose mi interessano abbastanza così come scrivere del codice leggibile, veloce e stabile.

Nel privato uso VisualBasic, all'univ ho usato Pascal ed adesso mi sto avvicinando a C..quindi prendo ad esempio il VisualBasic.

Quando creo una funzione od una procedura per un mio programma in VisualBasic come faccio a scrivere il relativo codice di test? e come faccio a testare la relativa funzione?

Non posso farlo con la generazione dell'eseuguibile...dovrei farlo in debugging? ma non perderei una marea di tempo? ...si insomma con quale metodologia creo ed eseguo codice di test per i miei algoritmi VisualBasic?

so che forse sono leggermente OT e mi scuso...però credo che bene o male possa far parte della discussione...