Extreme Programming
Ne avevo già parlato in un precedente post,
ma provo ad illustrare altri aspetti che avevo ignorato.
Una delle cose che viene data per scontato in XP è che si sappia pensare ad oggetti che è un prerequisito per il simple design.
Ma cosa significa veramente?
Nella programmazione tradizionale o formale un oggetto è dato dai suoi dati (attributi) e i metodi che agiscono su tali dati.
Questo però porta ad un esplosione del numero di classi perché basta un solo dato diverso e devo creare una nuova classe.
L'idea centrale del...
Una delle pratiche più invasive di extreme programming oltre al pair programming è il TDD (Test Driven Development) ed è anche la più difficile da padroneggiare.
In questo post cercherò di analizzare i motivi, fornendo alcuni spunti su come superare le difficoltà.
Le cose più difficili da accettare soprattutto se si ha già una certa esperienza è il fare emergenere il design dai test.
Questo implica di non anticipare eventuali feature successive o test successivi e scrivere il codice minimo indispensabile per fare passare il test appena scritto. Nella fase di refactoring poi si toglieranno tutti gli smell introdotti a partire dal più...
Il coach del mio team xp di nome Nautilus
ci ha proposto un'interessante esercizio per mettere alla prova la qualità della nostra codebase.
Scrivere il test dello scenario che si vuole sviluppare come lo vorremmo, ignorando l'attuale architettura, misurando il tempo impiegato.
Provare poi a scriverlo usando i nostri oggetti misurando nuovamente il tempo impiegato.
Nel caso specifico la coppia, in quanto sviluppiamo in pair, ha impiegato 2 minuti a scrivere il test per il primo caso e tre
pomodori (circa un ora e mezza) nel secondo caso.
La differenza tra i due tempi indica quanto la nostra codebase è lontana dalla qualità che vorremmo...
Continua l'elenco dal post precedente
Iterazione 7
Dal libro Design Patterns:
Preface to Book
Introduction
What is a Design Pattern?
Design Patterns in Smalltalk MVC
Describing Design Patterns
Introduzione Creational patterns
Factory Method (pag. 107)
Extreme programming explained: embrace change - Beck Cap 5 e Cap 6
The Three Laws of TDD - Bob Martin
OCP sul libro Agile Software Development, Principles,...
Vorrei condivere il percorso di studio del team xp per approfondire la conoscenza della programmazione ad oggetti e del ciclo di sviluppo software.
Il percorso è utile sia per chi non conosce l'argomento e vuole apprendere le tecniche di sviluppo seguendo il paradigma OOP, sia per chi vuole ripassare concetti già noti.
Iterazione 1
Improving Software Productivity - Barry W. Boehm, TRW
Iterative and Incremental Development - Robert C. Martin (Engineering Notebook C++ Report, Feb, 1999)
Iterative and Incremental Development (IID) - Robert C. Martin Engineering (Notebook Column April, 1999, C++ Report.)
Iterazione 2
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative...
Ogni tanto, nello sviluppo software, emerge qualche meme come ad esempio: tutte le dipendenze devono essere
disaccoppiate tramite un interface, tutte gli oggetti devono essere creati tramite factory, l'accesso ad un database
deve avvenire tramite un ORM, il TDD genera un buon design ecc.
Cosa hanno in comune tutte le frasi precedenti? Semplice: creano scorciatoie per evitare di pensare.
Sarebbe bello se potessimo scrivere codice seguendo alla lettera un manuale, ma sarebbe anche terribilmente noioso
e probabilmente verremmo sostituiti da qualche tipo di bot.
Prendiamo la prima affermazione: tutte le dipendenze devono essere disaccoppiate tramite un interface
e cerchiamo di capire da dove nasce questa esigenza. Il...
Se avete seguito i passi del post precedente
e provate a lanciare il test dovrebbe aprirsi una finestra che si chiude quasi istantaneamente.
Proviamo ora a simulare il click ad un pulsante. Per prima cosa aggiungiamo il controllo alla main window ricordandoci
di dargli un nome (nel nostro caso buttonControl).
Lo xaml dovrebbe essere qualcosa di analogo:
<Window x:Class="WPFAndNUnit.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Canvas>
<Button Name="buttonControl" >A button</Button>
</Canvas>
</Window>
Ora...
Gli acceptance test servono a verificare che una user story
sia stata realizzata correttamente, quindi sono test definiti insieme al cliente o addirittura scritti dal cliente.
L'applicazione che stiamo scrivendo utilizza wpf, quindi la nostra necessità è quella di poter aprire finestre,
cliccare sui pulsanti, ecc. all'interno di un test automatico.
Esistono approcci alternativi a quello che propongo in questo post, come ad esempio le
TestApi, le quali utilizzano le
automation api mentre per l'input del mouse e della tastiera
utilizzano l'API SendInput.
Le TestApi fanno molto di più di quello che a noi serve e quindi ho cercato un approccio più adatto al nostro caso.
Per...
Per stimare o sviluppare una user story a volte è necessario documentarsi su aspetti tecnici che non padroneggiamo. Nel mondo agile questa pratica viene chiamata spike
Uno degli aspetti che si sottovalutano degli spike è che con il tempo costituiscono una knowledge base molto utile per lo sviluppatore. Un altro aspetto importante è che non vengono fatti esperimenti sul codice di produzione.
Personalmente gli spike li committo in un repository chiamato Spikes cercando di dare dei nomi significativi alle varie solution in modo da poterli ritrovare facilmente in seguito...
il post di Riccardo mi ha dato l'occasione per riflettere su un disagio che sento presso le aziende che intendono iniziare o già utilizzano i metodi agili.
Credo che la questione sia dovuta alla differenza della situazione delle aziende italiane, formate soprattutto da PMI, rispetto a quelle anglosassoni.
In generale ho visto l'interesse ad utilizzare alcune pratiche agili (soprattutto l'introduzione dei test e la continuous integration) in situazioni dove è presente quello che io chiamo il cowboy programming.
Sostanzialmente una situazione...
Leggi la prima parte qui
Scelgo le ultime due colonne da cui partire per la valorizzazione in quanto sono le più semplici, infatti, ho un valore per ogni titolarità.
Abbiamo bisogno di:
Creare le colonne Rendita e Valore
Mappare le colonne con i campi RenditaCatastale e ValoreFabbricato della classe Titolarita
Formattare il numero come 1.000,00
Aggiungere una riga per ogni Titolarita
Partiamo dalla grid. L'implementazione attuale è la seguente e non fa ancora nulla:
public class Grid
...
Devo riempire una grid con i seguenti dati:
La quale rappresenta un esempio di una lista di fabbricati di una pratica ICI. Ogni riga rappresenta la titolarità di un fabbricato quindi sono rappresentati tre fabbricati di cui il primo con due titolarita.
Come vediamo la rappresentazione dei dati ha un pò di logica ad esempio la prima colonna ha due formattazioni diverse in base ad un valore booleano, poi dalla seconda colonna i dati legati al fabbricato vengono ripetuti se ci sono diverse titolarità ed infine ci...
Una cosa fastidiosa nell'usare il TDD con Visual Studio è la mancanza di strumenti pensati per chi scrive i test prima del codice.
ReSharper risolve parzialmente il problema; ad esempio quando da un test creiamo la classe sotto test viene creata nello stesso file. Si può spostare in un altro file, ma rimane nel progetto di test.
Cercando in rete ho trovato un plugin di resharper che ovvia al problema: TDD Productivity Plugin for Resharper. Si installa tramite un setupkit ed è compatibile con le versioni 4.5...
Il nostro processo di valutazione di un candidato, per essere assunto nel team agile in azienda, comprende una mezz'ora di pair programming (il cosidetto pomodoro).
E' una pratica molto utile, che consiglio vivamente, e permette di capire molto più a fondo le reali capacità di uno sviluppatore. Anche perchè alla fine della fiera, scriverà codice e quindi perchè non valutare come lo scrive?
Riporto qui la dinamica di una sessione di pair la quale ha fatto emergere un aspetto importate, ma spesso trascurato del TDD. Abbiamo scelto come esercizio da sviluppare in TDD Back to...
Ringrazio il mio collega per avermi suggerito i tre essays su Cose as Design di Jack W. Reeves. mi hanno dato alcuni spunti di riflessione e ne consiglio vivamente la lettura.
L'autore sostiene ed argomenta un concetto secondo me tanto semplice quanto vero: Il design è il codice. L'articolo è stato pubblicato nel 1992 sul C++ Journal, un periodo in cui era diffusa l'idea che il coding fosse un'attività di basso profilo. Un'idea passata quasi inosservata e poi ripresa da Ward Cunningham in ...
Aprite visual studio (o l'ide che preferite; si anche notepad o TextEdit vanno bene).
Caricate la parte di codice di cui andate più orgogliosi, su cui avete riflettuto per settimane fino ad ottenere la più perfetta sinfonia di design che la vostra mente potesse concepire.
Respirate.
Cancellate.
Riscrivete lo stesso codice in un altro modo.
I vostri colleghi ringrazieranno.
Fonte: Throwing away code
Nel mio precedente post ho affrontato il problema di come sviluppare usando il TDD un'applicazione multithreading.
In questo post, cercherò di approfondire su come testare la sincronizzazione per l'accesso ad una risorsa condivisa.
L'obiettivo che voglio raggiungere è scrivere un test che fallisca se non applico un meccanismo di sincronizzazione (in questo caso la lock) per l'accesso alla risorsa e abbia successo quando viene introdotta la sincronizzazione. Il fatto che il test abbia successo deve essere sistematico e non...
Il multithreading aggiunge complessità al design di un'applicazione. Occorre prestare attenzione alle differenti problematiche legate alla sincronizzazione, race condition, ecc.
In questi giorni sto realizzando un'applicazione in cui devo salvare dei messaggi di log su un database e per non rallentare il chiamante la scrittura sul database avviene in modo asincrono.
Voglio realizzare questa funzionalità in TDD e riporto qui i passi che ho effettuato e la soluzione ...
Continua l'implentazione del Model View Presenter utilizzando il TDD (Test Driven Development), in questi post affronteremo la gestione del click sui pulsanti Ok e Cancel.
Ecco la terza ed ultima parte di un caso reale di implementazione di MVP in .NET tramite il TDD
La continuazione del post su una implementazione concreta del model view presenter tramite la tecnica del TDD
Esempio concreto di sviluppo tramite il TDD di una GUI che utilizza le Windows Form.
Per chi sviluppa in TDD utilizzare i Mock Objects è una delle basi dell'interaction based testing.
Per facilitare questo compito sono disponibili alcune librerie in rete. Fino all'anno scorso ho utilizzato TypeMock, ora con l'anno nuovo ho voluto provare un'altra libreria ed ho scaricato Rhino Mocks.
Le prime impressioni sono positive in quanto l'object model mi sembra più chiaro rispetto a TypeMock. Ho avuto qualche difficoltà con in metodi che non ritornano valori (void).
Vediamo un esempio pratico:
Supponiamo di voler creare un mock object della seguente interfaccia:
public interface ICustomerList
{
void Add(Customer customer);
int Count { get;}
...
Segnalo l'articolo Introducing Behaviour-Driven Development (BDD) di Dan North.
Per me che pratico TDD da alcuni anni è stato illuminante perchè il BDD guida la scrittura dei test dal punto di vista del comportamento del sistema.
Secondo l'articolo è importante rimanere focalizzati sulla domanda:
What’s the next most important thing the system doesn’t do?
Voglio provare ad introdurre le pratiche suggerite nel mio prossimo progetto e verificarne i benefici.
Segnalo il post Flexibility vs Efficiency.
Fonte: joel reddit
Nell'articolo viene paragonato l'approccio agile a quello waterfall, sostenendo che il metodo waterfall è più efficiente nel caso in cui non ci siano cambiamenti durante la realizzazione di un progetto, mentre il secondo reagisce velocemente alle modifiche (praticamente tutti i progetti software).
Joel Spolsky ha creato un semplice test di dodici domande per valutare la qualità di un gruppo di sviluppo software. Le risposte consentite sono si o no dopodicè si fa la somma dei si:
Usate un sistema per il versionamento del codice?
Potete compilare una build in un solo passo?
Fate compilazioni giornaliere?
Avete un database dei bug?
Sistemate i bug prima di scrivere nuovo codice?
Avete una tabella di marcia aggiornata?
Avete delle specifiche?
I programmatori lavorano in un posto tranquillo?
Usate i migliori strumenti sul mercato?
Avete dei tester?
I candidati scrivono codice durante il colloquio?
Fate test...
All'università nel mio piano di studi ho avuto l'esame Controlli Automatici, il primo giorno di lezione è stata data la definizione di attuatore e sistema retroazionato che riporto qui:
Un comando in input viene eseguito senza conoscere il valore dell'uscita, esempio quando regolo la velocità di un ventilatore girando una manopola.
In questo caso il controllore conosce il valore dell'uscita e può regolare l'input di conseguenza, esempio in un climatizzatore imposto la temperatura desiderata e in base alla temperatura misurata viene modificata la potenza.
Torniamo all'informatica:
I metodi agili analogamente ai controlli automatici corrispondo all'introduzione della retroazione (feedback) a tutti...
Ecco il link: Code Reviews vs. Pair Programming?
Sono completamente d'accordo sulla conclusione:
The good news is you don’t need to choose between code reviews and pair programming. Just do both!
Per esperienza personale posso dire che entrambi migliorano notevolmente la qualità del codice.