La lavagna parte seconda
Scritto da Michele Della Torre il 5 aprile 2008 – 21:20Il mio primo post è stato dedicato all’uso della lavagna per lo sviluppo software: ora è finito l’esaltamento iniziale dello vedere il nuovo pannello appeso al muro dell’ufficio ed è il caso di tirare le prime somme.
Io seguo la metodologia di sviluppo TDD che non prevede una fase di design iniziale, ma il design deve “nascere” in base alle esigenze del progetto e da quello che il codice comunica. Prima o poi tornerò sull’argomento.
Devo dire che per quello che rigurda il design di dettaglio, cioè la struttura di una o poche classi, il design emergente è effettivamente quello che dà i risultati migliori; quando ho provato ad applicare un approccio classico disegnando sulla lavagna un diagramma UML i risultati non sono stati altrettanto soddisfacenti.
Il problema fondamentale è che un diagramma delle classi rappresenta molto bene le relazioni tra le entità, ma non riesce a fornire alcuna indicazione su come saranno le interazioni tra di esse; prima di scrivere il codice si ha solo un’indicazione e durante la fase di implementazione rimane molto difficile, soprattutto psicologicamente, modificare o rivedere un diagramma che sulla carta (o sulla lavagna) risulta così ben equilibrato e ragionevole.
Per la progettazione di algoritmi invece la lavagna è uno strumento comodissimo, in particolare per quelli concorrenti che non possono essere facilmente sviluppati a partire dai test.