Chiarimenti programmazione dei tasks

[cisc]

Questa discussione vorrei che abbia come scopo raccogliere dei chiarimenti sulla programmazione dei tasks per chi, come me, ha dei dubbi sulla realizzazione degli stessi.

per quanto mi riguarda, non mi è chiara il modo in cui dovremmo realizzare i tasks, ovvero la strutturazione delle classi, ci sono task che hanno ovviamente bisogno degli altri per essere eseguiti, bisogna aspettare che i tasks che servono vengano realizzati e poi basarsi sulla interfaccia pubblica realizzata, interfaccia pubblica che ognuno può realizzare come vuole?

[71104]

già, me lo chiedo anch'io: come specifiche mi sembrano un po' troppo aperte: "creare una finestra con client area da 800x600", "inizializzare OpenGL", fare questo&quello, vabbè, ma i prototipi delle funzioni? le classi?
qualcuno non dovrebbe prima architettare e strutturare le cose da questo punto di vista prima di passare alla programmazione vera e propria?

[^TiGeRShArK^]

boh...
a quanto ho capito io si dovrebbe scrivere il codice FUNZIONANTE e SCRITTO BENE.
Poi con un pò di refactoring si può spostare nei package appropriati...
ma fin qui non credo che abbia troppa importanza il package...

al massimo potremmo definire i package prima di iniziare...... così non ci incasiniamo troppo col refactoring dopo.....

per il resto...in effetti alcuni task pure a me sembravano piuttosto sequenziali....

come ci regoliamo???

[VICIUS]

Originariamente inviato da ^TiGeRShArK^

boh...
a quanto ho capito io si dovrebbe scrivere il codice FUNZIONANTE e SCRITTO BENE.
Poi con un pò di refactoring si può spostare nei package appropriati...
ma fin qui non credo che abbia troppa importanza il package...

Se volete posso creare un package con una classe e un main da poter usare come punto di partenza.

Originariamente inviato da ^TiGeRShArK^

per il resto...in effetti alcuni task pure a me sembravano piuttosto sequenziali....

come ci regoliamo???

Prendetevi un task e cominciate a scrivere un po' di codice tenendo in mente che poi andra integrato insieme ad altri pezzi. Se alcuni parti dipendono da altri mettete pure delle stub da riempire in seguito. Andate avanti con parti che potete realizare sul momento. Ad esempio la parte di riproduzione di un suono dipende si solo in parte dalla inizializazione di openal. Il codice che deve caricare il suono potete gia scriverlo.

Non commettete l'errore di isolarvi senza leggere il forum per poi riapparire magicamente tre giorni dopo 5 minuti prima di fare il commit. Se avete dubbi chiedete pure. Siamo un _Gruppo_.

ciao

[fek]

Originariamente inviato da 71104

già, me lo chiedo anch'io: come specifiche mi sembrano un po' troppo aperte: "creare una finestra con client area da 800x600", "inizializzare OpenGL", fare questo&quello, vabbè, ma i prototipi delle funzioni? le classi?
qualcuno non dovrebbe prima architettare e strutturare le cose da questo punto di vista prima di passare alla programmazione vera e propria?

Il modo in cui sono formulate le specifiche (volutamente aperte) e la mancanza di un'architettura definita, dipende fortemente dalla metodologia di sviluppo che stiamo usando, che si basa sue due principi:

1) Semplicita'
2) Testabilita'

Il primo principio di Semplicita' ci impone di scrivere solo il codice e nient'altro che il codice che risolve il task che ci e' stato assegnato. Letteralmente, nient'altro che quello. Ed impone inoltre di scrivere il minimo codice possibile per risolvere il task, ovvero impone il refactoring e l'eliminazione di tutte le duplicazioni. Da questo principio si ricava che io e Vicius non possiamo imporvi un'architettura di classi che voi vi limitate a riempire di codice, perche' senza avere la soluzione, io e Vicius non abbiamo tutte le informazioni che ci servono per creare un'architettura minimale e piu' semplice possibile. A quel punto preferiamo che voi creiate quest'architettura minimale attraverso il continuo refactoring del vostro codice.
Ovviamente vi daremo delle linee guida sull'architettura generale del sistema (separazione fra presentazione grafica e logica del gioco ad esempio), ma raggiungeremo queste linee guida attraverso il continuo Refactoring di soluzioni semplici e non come imposizione dall'alto.
Spesso servira' decidere l'interfaccia fra due task fra due persone diverse. In questo caso vi riunirete in chat e discuterete l'interfaccia pubblica fra di voi e poi passerete all'esecuzione dei vostri task. E' fondamentale che comunicate spesso e in maniera chiara fra di voi. Il secondo principio ci verra' in aiuto qui.

Il secondo principio di Testabilita' ci impone di testare tutto cio' che e' umanamente possibile testare, possibilmente in automatico. All'inizio vi scrivero' spesso io i test che voglio veder passare alla conclusione del task, imponendovi anche l'interfaccia pubblica quindi. Ma dopo mi aspetto che voi scriviate i test prima di scrivere il codice e, infine, scriviate i test che mi assicurano che il task sia stato concluso con successo. Alcuni task non saranno testabili, e lo discuteremo di volta in volta; nel Ciclo 1 potete gia' notare alcuni task che non saranno testabili. Vedremo se sara' il caso di scrivere delle procedure di test manuale per questi task.

Un esempio per chiarire il concetto.
Immaginiamo il seguente task: "Implementare una griglia MxN che contiene i diamanti, inseriendo un diamante in una colonna, il diamante dovra' trovarsi alla riga 1 (fondo) dopo M turni".

Mi aspetto di vedere i seguenti test:

1- Dopo aver creato la griglia, la griglia e' vuota
2- Dopo aver inserito un diamante in una colonna X, la griglia non e' vuota
3- Dopo aver inserito il diamante in una colonna X, la griglia contiene un diamante alla posizione (M, X)
4- Dopo un turno la griglia contiene un diamante alla posizione (M-1, X), ma nessun diamante alla posizione (M, X)
5- Dopo M turni la griglia contiene un diamante alla posizione (1, X)

Questo in parole, ma e' ancora meglio avere i test in codice:

Test1:

void testEmptyGrid()
{
  Grid grid = new Grid(M, N);
  assert(grid.isEmpty());
}

Esempio del test 3:

void testPushInGrid()
{
  Grid grid = new Grid(M, N);
  grid.pushDiamond(X);
  Assert(grid.isDiamondInCell(M, X));
}

E cosi' via fino alla fine del progetto. Notare come questi test stanno anche definendo l'interfaccia pubblica della classe Grid. E notare come ne documentino l'uso in maniera chiara e inequivocabile, meglio di qualunque parola. Se non ricordo come si usa il metodo pushDiamonds()? Guardo il test relativo che mi indica un chiaro esempio d'uso.

Domanda: trovate la duplicazione che c'e' fra i due test che ho scritto, che e' ottima candidata per un refactoring.

Come il secondo principio ci verra' in contro quando ci dovremo comunicare le interfacce pubbliche?

Immaginiamo che io abbia bisogno di un metodo per cancellare un diamante dalla griglia e 71104 ha il task di implementarlo. Oltre a descrivere a parole cio' di cui ho bisogno, gli scrivo un test:

void testRemoveDiamond()
{
  Grid grid = new Grid(M, N);
  grid.pushDiamond(X);
  grid.processTurns(M);
  grid.removeDiamonds(1, X);
  
  assertTrue(grid.IsEmpty());
  assertFalse(grid.isDiamondInCell(1, X));
}

Quale documentazione e' piu' precisa e sintetica di questo test? Non solo, quando il test passa, io so con assoluta certezza che 71104 avra' implementato cio' che mi serve (e possibilmente niente di piu'). E non solo, se 71104 durante un altro task introdurra' un bug che impedisce a questo metodo di funzionare correttamente, il test sara' li' a comunicarmelo immediatamente per tutto il corso del progetto! E 71104 non dovra' debuggare, potra' immediatamente correggere il bug e fare un commit pulito!
E funziona proprio cosi'. Un piccolo test, qualche minuto speso, tre grossi vantaggi che durano nel tempo. Spenderemo quel tempo molto volentieri.

In sintesi: avete totale liberta' di implementazione delle vostre classi e architetture, fino a che:
- tutti i test passano
- i controlli di stile passano
- il codice che scrivete non contiene duplicazioni
- io e Vicius non vi chiediamo di fare refactoring e semplificare l'architettura (e ve lo chiederemo)

[71104]

vabbè, ho capito, ma se Tizio deve fare la classe A, Caio deve fare B, e A deve usare un'istanza di B, come fa Tizio a sapere quali sono i prototipi e i nomi dei metodi di B? se li inventa?
oppure le classi che faremo sono tutte indipendenti tra di loro...?

[fek]

Originariamente inviato da 71104

vabbè, ho capito, ma se Tizio deve fare la classe A, Caio deve fare B, e A deve usare un'istanza di B, come fa Tizio a sapere quali sono i prototipi e i nomi dei metodi di B? se li inventa?
oppure le classi che faremo sono tutte indipendenti tra di loro...?

Tizio parla con Caio e discutono assieme l'interfaccia fra le classi. E, ancora meglio, Caio scrive qualche test che definisce l'interfaccia per Tizio da implementare.

La comunicazione fra di voi e' fondamentale. Quando avete dei dubbi, non implementate, chiedete a chi deve usare il vostro lavoro oppure a me e Vicius.

[Gica78R]

Originariamente inviato da fek

Test1:

void testEmptyGrid()
{
  Grid grid = new Grid(M, N);
  assert(grid.isEmpty());
}

Esempio del test 3:

void testPushInGrid()
{
  Grid grid = new Grid(M, N);
  grid.pushDiamond(X);
  Assert(grid.isDiamondInCell(M, X));
}

Domanda: trovate la duplicazione che c'e' fra i due test che ho scritto, che e' ottima candidata per un refactoring.

A parte la dichiarazione dell'oggetto grid
E in tal caso? Si potrebbero unificare i test 1 e 3 (pure il 2, volendo). Ma mi sa che va contro il principio di semplicita', o no?

Bocciato?

[fek]

Originariamente inviato da Gica78R

A parte la dichiarazione dell'oggetto grid
E in tal caso? Si potrebbero unificare i test 1 e 3 (pure il 2, volendo). Ma mi sa che va contro il principio di semplicita', o no?

Bocciato?

Bocciato

Ogni test dev'essere il piu' semplice possibile e idealmente testare una e una sola funzionalita'.
Inoltre, ogni test deve poter essere eseguito senza dipendenze da altri test. Nel senso che, il test 3 deve poter essere eseguito senza che sia necessario eseguire prima il test 1.

In altre parole, dimenticatevi cose come il Singleton pattern e le variabili globali e cercate di scrivere ogni classe avendo gia' in mente la sua testabilita'.

[^TiGeRShArK^]

e se si mettesse l'inizializzazione della griglia nel metodo setup???

import junit.framework.TestCase;

public class DiamondsTest extends TestCase {

  private Grid grid;
  
  protected void setUp() 
  {
    grid = new Grid(M, N);
  }


  void testEmptyGrid()
  {
    assert(grid.isEmpty());
  }


  void testPushInGrid()
  {
    grid.pushDiamond(X);
    Assert(grid.isDiamondInCell(M, X));
  }

}

altre cose nn mi vengono in mente...

[Gica78R]

EDIT: non avevo ancora letto la documentazione su Junit

[fek]

Originariamente inviato da ^TiGeRShArK^

e se si mettesse l'inizializzazione della griglia nel metodo setup???

Bingo

Avete dubbi sul procedimento che ho indicato?
E non ditemi di no, perche' quando ho cominciato a scrivere test ero strapieno di dubbi.

[fek]

Da una discussione con Raffaele e' uscito fuori uno dei principi cardine che ci seguira' durante lo sviluppo del gioco:

YOU AREN'T GONNA NEED IT
http://xp.c2.com/YouArentGonnaNeedIt.html

Fatelo vostro. Qualunque codice, metodo, classe pensate di voler scrivere perche' magari ci servira' in futuro anche se non serve nel task che dovete svolgere, non scrivetelo. Non ci servira'.

[^TiGeRShArK^]

Andando avanti così, una pillola per volta, dov'è che ci linki tutto extreme programming adventures in C#!

[cisc]

ragazzi, ma i test li dobbiamo mettere nel nuovo package it.diamonds.tests, o dobbiamo seguire l'esempio dell'Helloworld?

[fek]

I vostri test andranno nel package it.diamonds.tests oppure in package subordinati a questo, quando il progetto cresce.

[^TiGeRShArK^]

si...
a quanto ha scritto fek dovremmo metterli in src/it/diamonds/tests
però nn m sono messo a controllare il build.xml x sicurezza xkè nn ho tempo oggi!
[EDIT] stavolta mi hai battuto sul tempo!

[fek]

Originariamente inviato da AriusValaymar

Scusate ragazzi, ma non vi conviene usare un bugzilla per tracciare task e difetti? Cosi' evitate situazioni del tipo "chi fa cosa", "qual'e' lo stato di quel task" ed avete pure le notifiche automatiche per le modifiche (oltre a qualche metrica per tracciare l'andamento del processo).

Visto l'approccio agile che fek sta impiegando (user stories, integrazione continua, tdd, ...) credo che un issue tracker sarebbe un buon complemento.

I miei .02 euro

Ps: bello il progetto e l'approccio scelti.

Abbiamo un volontario per lo spike su bugzilla

Per ora i task sono pochi e riesco a seguirli a mano con un fogliettino excel, ma quando le cose crescono la tua idea e' validissima.
Automatizzare anche questo aspetto puo' essere molto utile. Io sono abituato ad un sistema di dev tracking dell'Electronic Arts e durante questi anni mi ci sono trovato ragionevolmente bene, quindi sono del tutto favorevole ad un sistema free di questo tipo.

Che cosa serve per usarlo?

L'unico problema che mi viene in mente e' mettere troppa carna a fuoco fin dall'inizio. Posso immaginare i dubbi di chi ha visto quest'approccio per la prima volta e gia' mi augura immani sofferenze perche' lo costringo a scrivere i test e fare refactoring.

[AriusValaymar]

Originariamente inviato da fek

Abbiamo un volontario per lo spike su bugzilla

1. Veramente ero solo un post da "critico di passaggio"
2. Cos'e' uno spike?

Originariamente inviato da fek

Per ora i task sono pochi e riesco a seguirli a mano con un fogliettino excel, ma quando le cose crescono la tua idea e' validissima.
Automatizzare anche questo aspetto puo' essere molto utile. Io sono abituato ad un sistema di dev tracking dell'Electronic Arts e durante questi anni mi ci sono trovato ragionevolmente bene, quindi sono del tutto favorevole ad un sistema free di questo tipo.

Io sono stato abituato ad usare bugzilla perche' i principali progetti che mi interessano usano questo strumento e sono troppo pigro per andare a sperimentare con altri (sebbene JIRA sia veramente forte). Qua potete trovare un elenco di tracker, se volete provarne altri (secondo me bugzilla è ancora il migliore in ambito free).

Originariamente inviato da fek

Che cosa serve per usarlo?

Io uso la 2.18.3 (l'ultima stabile al momento): l'installazione con gentoo è molto facile, la configurazione anche (be', sempre che funzioni tutto il resto ). Qui trovi tutti i requisiti.

[fek]

Originariamente inviato da AriusValaymar

1. Veramente ero solo un post da "critico di passaggio"
2. Cos'e' uno spike?

E io speravo ti offrissi come volontario
Sicuro di non volere partecipare?

Io sono stato abituato ad usare bugzilla perche' i principali progetti che mi interessano usano questo strumento e sono troppo pigro per andare a sperimentare con altri (sebbene JIRA sia veramente forte). Qua potete trovare un elenco di tracker, se volete provarne altri (secondo me bugzilla è ancora il migliore in ambito free).

Preziosissimo. Ti ringrazio. Vicius, fra qualche ciclo ti scateni tu su questa roba?

Io uso la 2.18.3 (l'ultima stabile al momento): l'installazione con gentoo è molto facile, la configurazione anche (be', sempre che funzioni tutto il resto ). Qui trovi tutti i requisiti.

Quindi c'e' bisogno di un server linux? Abbiamo solo un WinServer a disposizione, gentilissima offerta di Antares.