<< Perché si può volere un leader | Home | Eliminare gli sprechi: esempi >>

Eliminare gli sprechi


    Lean Software Development descrive principi e pratiche utili a introdurre i metodi agili nella propria organizzazione. E lo fa dal punto di vista del Manager e del Responsabile tecnico di progetto.




Un principio del Lean Software Development è


  1. Eliminare gli sprechi


    Un cliente/utente quando dice che una certa cosa secondo lui   non da più valore   al suo software, programmare quella cosa è uno spreco. 

    Anche una cosa che   rallenta   lo sviluppo e il rilascio di una funzionalità che serve all'utente è spreco



Tags :   |  |  |

Print | posted @ venerdì 5 settembre 2008 04:46

Comments on this entry:

Gravatar # Re: Eliminare gli sprechi
by robymes@hotmail.com (Roberto Messora) at 05/09/2008 12:12
Ergo Luca, se wrappare Entity Framework rallenta il rilascio di funzionalità utili al cliente, è uno spreco...
saluti
Roberto
Gravatar # re: Eliminare gli sprechi
by Andrea at 05/09/2008 23:48
Secondo me è uno spreco, perchè si decide di allocare risorse per qualcosa che non è stato richiesto. Anche se non rallenta il lavoro è comunque un costo che viene sostenuto e che il cliente deve pagare. Inoltre, come dicevo, non si ha nessuna certezza che il costo di astrarre EF sia inferiore ad affrontare, in futuro, la migrazione ad un'altra tecnologia (sempre messo che questa migrazione avvenga). Non si sà infatti come sarà questa nuova tecnlogia, nè quali tool per la conversione saranno disponibili, ecc.

Inoltre, immaginate se anni fà si fosse sviluppato un'astrazione di Windows Forms e ora si dovesse sostituire il backend con WPF. Per quanto bravo fosse lo sviluppatore incaricato di questo lavoro, secondo me il risultato sarebbe tutt'altro che ottimale, in quanto le tecnologie sono molto differenti e sei costretto a lavorare sul lowest common denominator.

Concordo che la possibilità di investire in qualcosa come l'astrazione di EF (che ha effetto positivo soltanto sulla qualità interna del codice) è possibile proporle al committente e discuterne.
Gravatar # re: Eliminare gli sprechi
by Andrea at 13/09/2008 20:05
Mi spiego meglio. Con MVC, hai disaccoppiato la logica dall'interfaccia utente, ma non hai disaccoppiato l'interfaccia utente da Windows Forms. Disaccoppiare l'interfaccia utente da Windows Forms significa appunto scrivere un toolkit come wxWidget.

Tornando all'argomento iniziale, EF, secondo me è bene disaccoppiare il codice di accesso ai dati dalla logica applicativa, ma disaccoppiare il codice di accesso ai dati dal framework di persistenza, wrappandolo, è un'operazione costosa e difficilmente giustificabile.
Gravatar # re: Eliminare gli sprechi
by Andrea at 15/09/2008 17:58
Ciao Luca, purtroppo mi ero perso quel tuo post. Molto utile, soprattutto perchè fornisce una terminolgia comune.

La scrittura di un wrapper coincide quindi con l'approccio "Skin and Wrap the API", che penso fosse quello preso in considerazione da Roberto.

"Responsability-Based extraction", che è l'approccio da me usato scrivendo i QueryHelper, mi sembra una pratica abbastanza comune e strettamente legata a "separation of concerns", utile non solo per isolare la dipendenza da EF, ma anche per la scrittura di test e la manutenzione.

Anche avendo un wrapper di NH o di EF a disposizione, a mio parere, sarebbe comunque bene fare "Responsibility-based extraction". Rimanendo nel nostro esempio, effettuare le query dall'interfaccia utente, siano esse fatte con il nostro wrapper o direttamente con EF, è comunque una pratica da evitare, soprattutto perchè non consente di scrivere unit test per queries. Inoltre, isolare le query - manualmente o usando dei tool di refactoring - è un'operazione a costo praticamente nullo.
Gravatar # re: Eliminare gli sprechi
by Andrea at 15/09/2008 18:22
PS

Riprendendo l'altro esempio, usare MVC (o rifattorizzare a MVC) può essere visto come una "Responsibility-Based extraction", mentre scrivere un wrapper come wxWidget è un approccio "Skin and Wrap the API".

Probabilmente, come dici tu stesso nell'altro post, in presenza di API molto complesse è sufficiente fare "Responsibility based extraction".

Se invece si tratta di isolare un'API semplice, per esempio un singolo controllo GDI+ di terze parti, sono convinto anch'io che "Skin and wrap the API" è un approccio valido e da tenere sicuramente in considerazione.
Comments have been closed on this topic.