| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

Velocita

Page history last edited by PBworks 13 years, 9 months ago

Questa pagina è ricavata da una mail di Gabriele sulla mailing list. Mi pare così ben scritta che merita di essere messa in evidenza ed indicizzata da Google :)

-- Matteo

 

Ma con XP si va più lenti?!?

 

Il discorso e' molto semplice, chi vede/prova per la prima volta le pratiche di programmazione del mondo agile percepisce un senso di lentezza e tira subito le sue conclusioni: "Magari in un mondo perfetto, ma il mondo reale e' fatto di consegne, scadenze e contratti, non abbiamo il tempo per queste cose!"

 

Prima di tutto la sensazione di lentezza e' fisiologica, in quanto chi per la prima volta applica una tecnica, prova uno strumento, e' normale che si senta spaesato, goffo e di conseguenza percepisce un peggioramento rispetto all'utilizzo degli strumenti abituali

 

Consideriamo anche il fatto che le pratiche del mondo agile richiedono impegno, esercizio e disciplina, mentre l'approccio al codice del programmatore medio e' fondamentalmente istintivo (*); e questo accresce la sensazione di disagio iniziale.

 

Il punto centrale del discorso e' proprio questo: utilizzando le pratiche XP (nella fattispecie TDD, ma il discorso vale in generale) la velocita' dipende dalle capacita' degli sviluppatori.

 

Le tecniche di programmazione istintiva (cut&paste, code&fix, ecc...) danno all'inizio del progetto una falsa sensazione di velocità. Perché falsa? Perché:

 

  1. La velocita' e' destinata a diminuire progressivamente. Queste tecniche sono degenerative, raggiungono velocemente degli obiettivi (implementazione di funzionalita') nel breve periodo, ma degradano la qualita' della base di codice, il che comporta un rallentamento durante l'implementazione della funzionalita' successiva, ecc... fino al raggiungimento del collasso del codice (ovvero il momento in cui i programmatori o scappano, o si impuntano per una riscrittura dell'intero progetto (**))
  2. La velocita' iniziale non puo' essere aumentata. Le tecniche di cui sopra non sono fisicamente migliorabili attraverso l'esperienza, la pratica o l'impegno (forse solo leggermente), l'unico modo di aumentare la velocita' e' quello di aumentare il numero delle persone coinvolte nella scrittura del progetto, peccato che questo aumenti anche la velocita' di degradazione del codice, che di fatto porta ad un peggioramento della situazione in un breve periodo di tempo

 

Cosa succede invece con le pratiche agili?

  1. La velocita' durante il progetto aumenta. Le pratiche come TDD e PP consentono di migliorare costantemente la qualita' del codice durante lo sviluppo del progetto, progressivamente risulta sempre piu' facile: inserire nuove funzionalita' (migliora il design), trovare e risolvere bachi (migliora il test coverage), modificare le funzionalita' preesistenti (eliminazione della duplicazione), ecc...
  2. La velocita' iniziale puo' essere aumentata. Le tecniche agili richiedono studio, pratica e disciplina per essere utilizzate al meglio. Ogni programmatore ha la possibilita' di potersi migliorare continuamente, sia come singolo che come parte integrante di un team. La possibilita' di miglioramento dato da una continua autovalutazione non pone limiti alla velocita' raggiungibile

 

 

(*) La prova di questo fatto e' empirica, pur non essendoci una base di formazione comune le cattive pratiche di programmazione si ritrovano uguali nella maggior parte dei programmatori lasciati all'autoformazione

 

(**) Nota, nella mia carriera non ho mai visto una progetto riscritto da zero con una qualita' di codice nettamente superiore al progetto precedente, se va bene si riottiene lo stesso prodotto, spesso se ne ottiene uno di qualita' inferiore. Statisticamente i progetti di riscrittura di codice funzionante falliscono nel 80% dei casi

 

Aggiornamento -- questo post di Uncle Bob ci dà ragione

 

Aggiornamento -- non ricordo da chi ho sentito dire che se vai a 100 all'ora in cinquecento, sembra di andare fortissimo, perché trema tutto e sembra che la macchina vada a pezzi! Ma se vai a 200 all'ora in Ferrari, sembra di andare piano. Inutile spiegare che fare code&fix&cut&paste è come andare in 500.

Comments (0)

You don't have permission to comment on this page.