Questo sito utilizza cookies, anche di terze parti, per mostrare pubblicità e servizi in linea con il tuo account. Leggi l'informativa sui cookies.
Username: Password: oppure
Dibattito fra Jim Coplien e Robert C. Martin sul TDD
Dibattito fra Jim Coplien e Robert C. Martin sul TDD
Inviato da netarrow 21/10/2013 20:28
commenti (5)

Aggiungi un commento

Inserisci il tuo commento qui
Esegui il login oppure registrati per inviare commenti
  • Mi sporgo piu' verso la parte di Jim, Robert in mia opinione ha bevuto un po' troppo il kool-aid del TDD. Come ogni strumento in software, conoscere TDD e usarlo nella maniera opportuna al momento opportuno e' una delle qualita' che differenzia un buon ingegnere dalle masse, ma andare a dire che non si puo' essere un professionista se non si usa TDD... dipende dalla situazione, dipende dal progetto, dipende con chi stai lavorando.

  • Anche io sono più in linea con Coplien. Trovo difficile riuscire a praticare il TDD in maniera così spinta (e così vincolante). E sicuramente non credo che non usarla mini la professionalità di uno sviluppatore. Ma credo che il TDD debba diventare più comune, diffuso e soprattutto richiesto da clienti e aziende. Spesso non si da sufficiente peso a questa tecnica perchè "non c'è tempo" o "costa troppo", per lo meno in italia. Poi è chiaro che quando ci si attacca a determinate metodologie in maniera religiosa ed estrimista è difficile evangelizzare determinate tecniche.Diciamo che posso capire il non voler far emergere tutta l'architettura dai test, ma preferire una parte di up-front-desing con magari i contracts, ma dopo qualche tempo che mi ci sono abituato trovo fondamentale riuscire a fare per lo meno il maggior numero di unit ed integration tests il prima possibile; magari nel mentre avendo un pò di prod code anche già scritto, senza seguire in maniera rigorosa sempre il red-green-refactor. L'importante è ridurre al minimo il time-to-execute, eseguendo pezzetti di codice isolati il prima possibile verificandone la funzionalità, senza avere un intero sistema funzionante o senza doverlo necessariamente tirare su tutto, e questo è il punto dove poi infatti Martin e Coplien hanno avuto la convergenza.
  • E concordo sul valore di design by contract in contrasto al TDD, combinato con peer reviews.
  • Magari i politici facessero dibattiti come gli ingegneri...