Pragmatic Programming

Da Wikipedia, l'enciclopedia libera.

Il pragmatic programming è una metodologia agile ideata da Andrew Hunt e Dave Thomas e che parte dalla banale osservazione che in un qualunque progetto si faranno errori e quindi niente sarà definitivo.

La soluzione quindi è lavorare tenendo presente questo difetto di base, così si forniranno spesso nuove versioni senza mai considerare niente definitivo, ossia: ogni cambiamento o aggiunta deve essere reversibile. Una filosofia di lavoro, più che pragmatica, rassegnata all'inevitabilità dell'errore e dell'imprevisto.

La soluzione suggerita è l'uso di CVS (Concurrent Versions System) e l'utilizzo proposto diventa parte della metodologia con il nome di Version Control. La funzionalità più utile della metodologia è quella di poter visionare ed ottenere disponibile l'intero progetto (ed il suo status) alla data richiesta dal project manager, questo deriva dal fatto di avere organizzato Version Control come una macchina del tempo, o forse meglio come una linea del tempo, sovrastante l'intero progetto gestito.

[modifica] Principi base

I punti chiave di Version Control sono sei:

difendere i beni, gli elementi preziosi, del progetto (ossia mai perdere una buona idea);
sapere tornare sui propri passi (cioè sapere annullare le decisioni sbagliare);
imparare come condividere il codice in sicurezza e lavorare in parallelo;
imparare ad evitare i costosi stop allo sviluppo del progetto;
gestire strumenti e codice di terze parti;
capire come e quando tornare indietro in tempo (e riprendere il lavoro partendo da una precedente versione).

Gli stessi autori insieme a Mike Clark suggeriscono anche l'utilizzo di molti degli altri strumenti gratuiti disponibili per lo sviluppo software, come ad esempio Junit e Nunit per i test unitari, e propongono gli strumenti adatti per ottenere la massima automazione nelle diverse fasi del progetto: stesura della documentazione, integrazione del software, test unitari e funzionali, rilascio delle versioni.

[modifica] La regola del Tre

Spesso nei loro articoli gli autori utilizzano un trio di concetti o regole per analizzare, decidere, risolvere, aspetti o problemi dello sviluppo software.

Ci suggeriscono come scegliere la materia prima dello sviluppo software, ossia i programmatori. La nostra scelta deve cadere sui programmatori che:

non usano una sola soluzione per problema e imparano dagli errori fatti;
non hanno troppa paura per fare errori;
non si annoiano a spiegare cosa stanno facendo e perché.

Indicano come Version Control, Unit Testing, Automation siano la soluzione ideale ai tre errori che semplicemente rovinano un progetto:

non guardare mai indietro (una volta finito, un pezzo di codice è finito);
mai mollare' il codice scritto (anzi affezionarsi e tenerselo stretto);
affrontare i diversi passi dello sviluppo in maniera differente ogni volta (non definire regole precise).

Scendono nel dettaglio della programmazione indicando come il buon codice Object-Oriented debba essere: