Your Comments.

• # re: TDD

  Pardon, un typo, "stake-older" e' ovviamente "stakeholder".
  
  -LV
  

  Left by LudovicoVan at 12/03/2008 11:10
• # re: TDD

  Per TDD si intende Test Driven Development (secondo Kent Beck e Martin Fowler),
  quindi si intende il processo dello sviluppo tramite test.
  
  Per quanto concerne il Desing, è morto il vecchio concetto di desing.
  
  In realtà in Desing viene creato, sviluppando le carte del cliente.
  Ma in realtà questo può variare al variare delle richieste del cliente.
  
  Sempre citando Martin Fowler: http://martinfowler.com/articles/designDead.html#id21790
  
  Quindi rimango fermo nell'idea che il TDD serve solamente allo sviluppo del codice; il
  design è qualcosa che nasce da se e viene sottoposto a refactoring permanente.

  Left by Salvatore Di Fazio at 12/03/2008 13:15
• # re: TDD

  P.S.
  
  Salvatore:
  > il design è qualcosa che nasce da se
  > viene sottoposto a refactoring permanente.
  
  Hai perfettamente ragione.
  
  In effetti sto rivedendo le mie posizioni, e in effetti le ho gia' riviste, anche in quanto a Refactoring.
  
  Quello che mi lascia perplesso del Refactoring e' che _tendenzialmente_ tendo a tenere il codice sempre minimale, sempre pulito e *sempre funzionante*, cioe' al terzo Ctrl-Shift-B, di solito, gia' lancio lo unit test con qualcosa di funzionante e *chiuso*, un po' come se tenessi "sempre tutto il work in progress mock-ato"...
  
  Spero che questo dia un'idea del tipo di perplessita' che mi frullano.
  
  Grazie di nuovo, questa cosa mi sta portando idee molto interessanti... le quali ovviamente ancora vi ho per lo piu' gia' menzionato tutte :O
  
  Grazie.
  
  -LV
  

  Left by LudovicoVan at 12/03/2008 14:17
• # re: TDD

  Forse ho scritto male ciò che volevo esprimere o forse non avete letto ciò che mensionavo :D
  
  Il TDD(esign) non esiste. :)
  
  Il Desing, inteso come metodologia non Agile, in Agile non esiste.
  
  Esempio di carta:
  1 - questo pulsante deve fare questa operazione
  
  Già questo è design.
  
  Prendi la carta, la sviluppi tramite TDD nella maniera più semplice a te possibile, ed hai creato:
  - test
  - codice
  - desing
  
  Se domani il cliente vuole cambiare qualcosa su quel comportamento:
  
  - riparti dal test
  - refactoring del codice
  - hai fatto il refactoring del desing
  
  
  Leggi l'articolo di Martin Fowler sulla morte del design è molto chiaro.
  
  

  Left by Salvatore Di Fazio at 12/03/2008 19:48
• # re: TDD

  Salvatore, non sono d'accordo.
  
  L'esempio che proponi non e' design, ma functional (o user) requirement.
  
  Martin Fowler non dice assolutamente che il design e' morto, ma e' cambiato. Si e' solo trasformato.
  
  Tante' che se si parla molto di Design Patterns, vorra' dire che il design c'e' ancora ;-)
  
  Uno degli strumenti piu' potenti del refactoring e' infatti il buon design, il qual compito e' quello di soddisfare i requisiti funzionali, di testabilita' e possibilmente prevedere certe evoluzioni future.
  
  Se per te design significa diagrammi UML e tanti bei documenti, allora quel design e' morto. Ma quello non e' design, ma uno degli output del design.

  Left by Pierre at 12/03/2008 20:15
• # re: TDD

  Il come è dato dal codice, mentre sviluppi il codice sviluppi il design, appunto xchè non puoi esser certo a priori che il design che stai sviluppando sia quello corretto.

  Left by Salvatore Di Fazio at 13/03/2008 19:16
• # re: TDD

  Julio,
  il requisito del cliente, quello che lui ti chiede, e' incompleto per definizione. Ecco perche' distinguo chiaramente design (test) da validazione (testing).
  
  Lo scopo finale del design e' soddisfare i requisiti funzionali del cliente. La validazione viceversa serve solo a definire l'exit criteria.

  Left by Pierre at 13/03/2008 20:56