Newsgroup: it.comp.lang.delphi
Titolo: Metodologie

Ciao a tutti.
L'argomento di questo post riguarda un po tutto il campo dello sviluppo
software.
Quindi, forse è un po ot, ma forse no...
Negli ultimi anni l'attenzione primaria nello sviluppo software si è
un po spostata dal "ci serve un linguaggio/compilatore piu potente
veloce etc.." alle metodologie.
Credo che tutti nel ng abbiano almeno sentito parlare di scrum, xp,
prince...
Quello che mi chiedevo è:
qualcuno del ng usa qualcosa di simile o no?
Se si, cosa? Come vi trovate?
Per applicarle avete seguito corsi, vi siete documentati da soli...
Insomma, se qualcuno vive questa esperienza nel quotidiano troverei
interessanti alcune info.
Attenzione, non parlo della TEORIA....Per quella ci sono siti, manuali
articoli anche se spesso sono scritti un po male.
Parlo di PRATICA.
AS

 Parlo di PRATICA.
Io ho iniziato ad approfondire da poco "eXtreme Programming" leggendo 
alcune informazioni online sui siti più conosciuti
http://www.agilemanifesto.org/
http://www.extremeprogramming.org/
http://www.xprogramming.com/
http://www.martinfowler.com/
più che altro incuriosito dal "background" delle funzionalità di 
Refactoring introdotte in D2005 e da Unit Testing (tramite DUnit), 
facente anch'esso parte in modo stabile di D2005 grazie ad alcuni wizard.
Sono in procinto di realizzare un progetto medio/grande in cui voglio 
testare alcune delle "pratiche" introdotte da queste metodologie con gli 
adeguati strumenti sopra citati.
Quando avrò approfondito un po' l'argomento, sarò forse maggiormente in 
grado di fornire impressioni significative.
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 qualcuno del ng usa qualcosa di simile o no?
Per quanto riguarda le mie esperienze lavorative č raro quando arrivano 2
fogli di analisi "di massima", ed č ancora piů raro cercare di fare le cose
"per bene". Pensare di realizzare un progetto completamente ad oggetti o
addirittura con simili tecnologie, per me č pura fantascienza, per lo meno
nelle situazioni in cui mi č capitato di lavorare (dalla piccolissima alla
medio-grande azienda)
-- 
Lis                 
www.alessandroghezzi.it
O'Telma Formula1:   
http://snipurl.com/otelma
Soltanto le persone forti sanno confidare le proprie debolezze e chiedere
conforto (Anonimo)

 Se si, cosa? Come vi trovate?
...
Io sto cercando di portare due miei progetti (e col tempo tutti) sotto XP, 
ma non è facile passare dalla teoria alla pratica, specialmente con progetti 
già esistenti.
Un esempio pratico è la TDD (Test Driven Development).
Se devi creare un progetto ex novo sai che prima di scrivere una linea di 
codice per l'implementazione in corso devi scrivere gli unit test per 
testarla, ma quando ti porti dietro un vecchio progetto che magari non ha un 
design proprio elegantissimo perchè quando hai cominciato a svilupparlo eri 
un pischello il discorso cambia. Scrivere i test per le diverse funzioni in 
questo caso non è sempre facilissimo, le classi possono essere annidate o 
appoggiarsi direttamente alle API di sistema e sono tutte cose che 
complicano la stesura dei test. In questo caso prima di preoccuparsi di 
"coprire" di test l'applicazione, bisogna "risistemare" il codice per 
renderlo più trattabile e rompere eventuali dipendenze. A questo scopo è 
utilissimo il libro di Michael Feathers "Working effectively with legacy 
code", che puoi trovare su Amazon.
Poi utilissimo (anzi indispensabile) è anche "Design Patterns" della famosa 
Gang Of  Four (Erich Gamma ed altri) che fornisce percorsi per uno sviluppo 
veramente Object Oriented e riusabile.
Sempre per portare il vecchio codice sotto XP un altro "Must" è 
"Refactoring" di Martin Fowler.
Comunque la mia implementazione delle metodologie XP è tutt'altro che 
conclusa, anzi sono ancora in alto mare. Ho parecchie perplessità, te ne 
cito solo due:
1) Michael Feather dice che i test sui database non sono "unit test" in 
senso stretto. Dato che sviluppo gestionali (e quindi  ho a che fare quasi 
esclusivamente con database) questo significa che devo testare tutto tranne 
le operazioni al database o testo anche queste su DB di prova e me ne frego 
se non sono unit test?
2) Sto pensando di utilizzare gli OPF InstantObjects, ma questo dal punto di 
vista XP mi pone delle perplessità circa cosa deve essere messo sotto test.
Comunque sarà interessante leggere gli altri interventi di questo post, per 
vedere com'è lo stato dell'arte (nel nostro ng) nell'implementazione in 
Delphi delle metodologie agili.
Ciao
Roberto

 vista XP mi pone delle perplessità circa cosa deve essere messo sotto test.
Se usi opf di fatto sviluppi in architettura MDA.
Grazie del tuo intervento
AS

 Grazie del tuo intervento
Un altro intervento (lunghetto):
In un altro post relativo a Firebird tu hai citato il commento di Mohammad 
B. Abdulfata dicendo che ti faceva riflettere
http://tinyurl.com/8h3yy
Nell'articolo tra le altre cose critica 4 dei pilastri fondamentali della 
metodologia xp:
"
1. Always have a customer available on site.
2. Unit test before you code.
3. Program in pairs.
4. Forfeit detailed design in favor of incremental, daily releases and 
refactoring."
Contrariamente all'autore, io ho scelto di implementare xp perchè i vantaggi 
impliciti nelle metodologie mi sembrano talmente evidenti che non possono 
non funzionare.
Partendo dall'ultimo punto dove l'autore commenta che abbandonare l' 
"upfront design" sia una pratica talmente ridicola che non necessita di 
essere commentata, io ho una immagine opposta.
Mi immagino seduto con il cliente, che mi prospetta l'elenco delle 
funzionalità che si aspetta dall'applicazione, magari un elenco corposo, io 
che sviscero tutte le problematiche relative e alla fine di un lungo lavoro 
di analisi produco un bel progetto (upfront design) che mi viene approvato. 
Poi dopo tot mesi vado alla consegna e installazione dell'applicazione, e 
alla prova dei fatti con il cliente si scopre che sul modulo 1 non ci siamo 
capiti e non era quello che volevano, il modulo 2 tutto sommato è inutile 
perchè in produzione non verrà mai usato e il modulo 3 va bene ma mancano 
alcuni dati fondamentali che per essere implementati richiedono di ripensare 
all'architettura del software (esagero).
Al contrario, usando xp io tengo buono il cliente e gli consegno presto solo 
il minino pacchetto (es. 20%) di funzionalità utilizzabile in produzione, e 
lo rassicuro dicendogli che le rimanenti funzionalità (80%) verranno 
rilasciate con implementazini successive e ravvicinate,. sviluppandole per 
ordine di urgenza. Così facendo, implementazione dopo implementazione, 
capita spesso che il software evolva in maniera completamente diversa da 
quello che si era previsto (sia il cliente che il programmatore), con 
differenze anche piuttosto radicali e senza perdite di tempo (e di denaro) 
per nessuno. Il software evolve di vita propria in maniera quasi magica.
Circa lo scrivere unit test prima di scrivere codice anche qui il vantaggio 
è evidente. L'autore commenta che prima di implementare la nuova 
funzionalità non hai idea di quello che deve fare, quindi come fare a 
scrivere il test?
Si potrebbe replicare: come fare a scrivere il codice se non sai cosa deve 
fare? E' chiaro che un'idea di ciò che deve fare la nuova funzionalità 
solitamente uno la ha, e scrivere i test significa scrivere i requisiti che 
quella funzionalità dovrà rispettare e questo può (e deve) essere fatto 
prima di scrivere il codice della nuova funzionalità. Poi l'autore commenta 
che mantenere i test mentre il codice cambia sia testualmente "un incubo". 
Ma è proprio questa la principale utilità dei test: tu cambi 
l'implementazione di un metodo public di una classe fondamentale e ti 
saltano il 30% dei test, ed è giusto. E finchè non riesci a far passare 
tutti i test introducendo le opportune modifiche non ti alzi da quella 
sedia. Così facendo si usa al minimo il debug per rintracciare 
malfunzionamenti imprevisti (che però non viene abbandonato).
Sull'avere un cliente che lavori allo sviluppo del software nello staff, 
credo sia un'ipotesi da interpretare. Alla lettera è quasi impossibile, ma 
se l'applicazione è distribuita e la societa di sviluppo un pò articolata, 
il "cliente" potrebbe essere l'ufficio vendite che tratta con i clienti e 
raccoglie lamentele e suggerimenti, o più semplicemente un bel forum dove i 
tuoi clienti scaricano tutti i loro commenti (e i loro nervi) sulla tua 
applicazione.
Il Pair Programming è un pò più difficile. Sono il primo che ringhia se 
qualcuno si avvicina alla mia tastiera, ma nel mio caso il problema non si 
pone perchè lavoro da solo. Immaginandomi però in uno staff di 
programmatori, oltre al vantaggi di avere due teste che controllano errori 
al posto di una, la programmazione in coppia turnando le coppie può avere il 
beneficio di far sì che le conoscenze acquisite da un programmatore si 
distribuiscano a tutto lo staff (anche se non l'ho mai provato).
Roberto 

 cosa sola
Scusa, in effetti davo per scontato che si trattasse di applicazioni MDA. La 
mia domanda circa cosa testare la riformulo cosě: All'interno 
dell'applicazione, quelle classi di oggetti che accedono al database per 
popolare dataset o eseguire query (esempio la classe TClienti scritta da me 
o l'oggetto instant object sviluppato con il wizard) va testato oppure no? 
se sě, la classe in questione la collego non al db di produzione, ma ad un 
db di prova, soprattutto se la classe esegue query di modifica dei dati. 

 distribuiscano a tutto lo staff (anche se non l'ho mai provato).
Un semplice esempio di pair programming?
Prova a parlare di quel problema con qualcuno.. raccontagli tutto, le
prove le idee i test le alternative cosa hai fatto etc etc etc.
Se la controparte resiste, menter racconti arrivi al punto.
Il problema della pair programming non è sul piano tecnico, ma su
quello umano.
Ci sono 2 cose che non devi fare alle persone: toccarrgli il portafolgi
e dirgli di cambiare il modo di lavorare....
AS

 Se hai una applicazione MDA
Scusate l'ignoranza...cos'è un'applicazione MDA?
-- 
Lis                 
www.alessandroghezzi.it
O'Telma Formula1:   
http://snipurl.com/otelma
La paura del pericolo è mille volte più terrificante del pericolo presente
(Daniel Defoe)

 Un altro intervento (lunghetto):
Molto, molto interessante...grazie ad entrambi
-- 
Lis                 
www.alessandroghezzi.it
O'Telma Formula1:   
http://snipurl.com/otelma
E' meglio essere ottimisti ed avere torto piuttosto che pessimisti ed avere
ragione (Albert Einstein)

se usi eco sviluppi in mda.
il db è solo storage per la persistenza sul quale fai solo
insert-update-delete
la logica è tutta nella applicazione.
Vantaggi
indipendenza dal tipo di db utilizzato
logica in un unico posto
Svantaggi
avendo un accesso al db generico ti perdi le ottimizzazioni lato client
ti serve eco, oppure usi altri software tipo powerdesigner sybase. In
una parola, UML
MDA= Model Driver Architecture
AS
AS

Dimenticavo... la butto li...
Qualcuno usa ITIL?
AS

> MDA= Model Driver Architecture
sorry:
MDA= Model Driven Architecture 
AS

 Scusate l'ignoranza...cos'è un'applicazione MDA?
Forse Model Driven Architecture?
Io non l'ho mai usata ma sono interessatissimo alle possibilità di
applicazione in Delphi ;-)
Ciao Vittorio

 applicazione in Delphi ;-)
Per chi vorrà utilizzarlo, le componenti principali di ECO saranno 
incluse in tutte le edizioni di D2006: questo dovrebbe stimolare 
senz'altro l'avvicinamento alle tecnologie MDA.
Non so se riuscirò ad acquistarlo però... vedremo. :-/


 Scusate l'ignoranza...cos'è un'applicazione MDA?
Grazie a tutti...ho cercato anche qualcosa con google e mi avete chiarito un
pò le idee. 
-- 
Lis                 
www.alessandroghezzi.it
O'Telma Formula1:   
http://snipurl.com/otelma
L'uomo può credere all'impossibile, non crederà mai all'improbabile (Oscar
Wilde)

 Non so se riuscirò ad acquistarlo però... vedremo. :-/
Ciao Marco,
ci sono voci sui costi delle versioni aggiornamento di D2006?
Ciao, Vittorio

 ha scritto nel messaggio 
news:1129112687....@o13g2000cwo.googlegroups.com...
se usi eco sviluppi in mda.
Vantaggi


in poche parole:
1) niente stored procedure
Quello che faresti nelle stored procedure lo fai da codice
2) il database è progettato per CONTENERE le istanze delle classi che
necessitano di persistenza e non per gestire tabelle come siamo soliti
fare.
3) niente validazione dei dati sul db
quello che fanno i check contraints lo fai da codice
Questo non è esaustivo.. serve solo a darti un idea.
AS

 ci sono voci sui costi delle versioni aggiornamento di D2006?
Al momento no. :-/
