[vari]Reinventare la ruota

[^TiGeRShArK^]

Originariamente inviato da tomminno

Scusa e perchè con le tecniche standard non è possibile rifattorizzare il codice? Praticamente mi stai fondendo una tecnica di sviluppo di un progetto software con la qualità del codice. Perchè il codice non potrebbe essere identico nei 2 casi?

Puoi sempre rifattorizzare.
Ma se non hai scritto il codice pensando prima ai test "sò cazzi tua ".
Rifattorizzare un codice non adeguatamente coperto dai test equivale a giocare ad una ruolette russa.

Sbaglio o non sempre è possibile scrivere test?
Tutte le volte che il codice gira in un contesto esterno (es codice di applicativo web .NET che gira nel contesto di IIS, oppure servizi), i test verificano il funzionamento del codice non nel contesto in cui questo girerà. Quindi potrebbero evidenziarsi bug che nei test non emergono.

Per questo puoi scrivere i mock sia a mano che con librerie che ti semplificano notevolmente il lavoro.
In moltissimi casi i test sono fattibilissimi.
E nei casi che stai considerando in questa discussione, tipici scenari enterprise a quanto ho capito, non solo sono fattibilissimi, ma anche ASSOLUTAMENTE auspicabili.

Ma il tempo di scrittura del codice aumenta (non dirmi che il codice dei test si scrive da sè). Nel mio caso il tempo per scrivere il codice quasi raddoppia (al che mi lasciano sempre perplesso le 2 settimane per pubblicare, cazzarola scrivete il codice alla velocità della luce!).

Ovvio.
Mai negato che il tempo di scrittura del codice aumenti.
Io in media sto impiegando più tempo a scrivere i test che il codice per risolvere il task.
Ma in realtà non è uno spreco è un INVESTIMENTO per il futuro.
E' un pò come la differenza tra l'affitto e il mutuo.
Con l'affitto ovviamente paghi di meno, ma alla fine non ti resta niente in mano.
Con il mutuo alla fine hai qualcosa di SOLIDO E FUNZIONALE che ti appartiene.

Meno male non sono il solo, mi sono sempre chiesto come si faccia a scrivere il test prima del codice. Ci vuole qualcuno che lo abbia in mente prima di scriverlo.

Me lo chiedevo sempre anch'io come fare.
Poi dopo tante bestemmie, frustrate e ditine spezzate con fek per diamonds, finalmente ho imparato.

P.S. A proposito.. che fine hanno fatto tutti i post nella sezione DIAMONDS????!?!??!?!?

[gugoXX]

Originariamente inviato da tomminno

Scusa e perchè con le tecniche standard non è possibile rifattorizzare il codice? Praticamente mi stai fondendo una tecnica di sviluppo di un progetto software con la qualità del codice. Perchè il codice non potrebbe essere identico nei 2 casi?

Direi che e' molto difficile che 2 approcci alla produzione software possano portare ad avere lo stesso codice.

Sbaglio o non sempre è possibile scrivere test?
Tutte le volte che il codice gira in un contesto esterno (es codice di applicativo web .NET che gira nel contesto di IIS, oppure servizi), i test verificano il funzionamento del codice non nel contesto in cui questo girerà. Quindi potrebbero evidenziarsi bug che nei test non emergono.

Ovviamente i test non sono di "Prodotto completo", ma vengono testate le singole unita'. Alcuni pattern permettono la scrittura di test piu' efficientemente che altri. P.Es. per le GUI e' consigliato MVC (Model-View-Controller) o MVVM (Model-View-ViewModel), per i quali se correttamente applicati, la logica puo' essere completamente testata.
Ci sono anche tecniche che permettono la costruzione di unit test in assenza dei contesti esterni. Queste tecniche sono conosciute con il termine di Mock, e ci sono parecchie librerie che possono aiutare a creare questi Mock object.
Il risultato dei test sara' qualcosa come "Se il contesto esterno si comportera' come io penso si debba comportare, allora se questo test viene passato significa che il codice scritto funzionera' anche con il servizio esterno".
E ci sono test chiamati di Integrazione, per verificare infine che il mock object da me creato sia corrispondente al contesto esterno relativo, per i quali ho pero' bisogno della controparte reale del servizio (puntando tipicamente alle relative macchine di QA)

Ma il tempo di scrittura del codice aumenta (non dirmi che il codice dei test si scrive da sè). Nel mio caso il tempo per scrivere il codice quasi raddoppia (al che mi lasciano sempre perplesso le 2 settimane per pubblicare, cazzarola scrivete il codice alla velocità della luce!).

Il tempo per la scrittura del codice alla fine diminuisce perche' si evitano i tempi morti e quelli per la integrazione, per la correzione di bachi postumi.
Come dicevo prima, all'inizio lo sviluppo e' piu' lento, ma man mano che si va avanti, aggiungere o modificare pezzi risulta essere piu' veloce che con tecniche tradizionali, compreso il tempo per la scrittura dei test.

Meno male non sono il solo, mi sono sempre chiesto come si faccia a scrivere il test prima del codice. Ci vuole qualcuno che lo abbia in mente prima di scriverlo.

Ho colleghi che lo fanno. Non sono tanti ma ci sono.
Scrivere il test quando e' stato rilevato un bug invece e' piu' semplice, e davvero aiuta nel trovare la soluzione.



Es. recente: Quando clicco su quel pulsante di qulla finestra, dovrebbe aprirsi una form che chiede un elenco di ruoli dal server di autenticazione, li presenta a video.
Associato a ciascun ruolo c'e' una checkbox. L'utente puo' scegliere di abilitare/disabilitare tanti ruoli quanti vuole.
Alla pressione del tasto OK questa nuova form deve chiudersi, e il nuovo elenco di ruoli dovra' servire all'applicazione ogni volta che si faranno chiamate per qualsiasi altro servizio.
E' stato verificato da QA che un utente sembra poter cambiare gli ruoli, ma tali ruoli non sembrano essere usati dall'applicazione.

Creo un Mock Object relativo al servizio del server di autenticazione. PEr poterlo fare e' necessario che i metodi di ciascun servizio siano esposti tramite interfaccia. Guarda caso WCF espone i metodi di ciascun servizio traminte Interface.
Creo uno Stub Object relativo al servizio del server di autenticazione. In realta' sara' gia' stato creato per qualche altro test.(La differenza tra Mock e Stub la tralascio. Per iniziare, uno Stub simula il funzionamento di un servizio esterno, un Mock invece serve per controllare che alcuni metodi esterni al test siano stati chiamati. Tali metodi possono essere remote procedure call di un servizio esterno, oppure anche metodi di oggetti interni al progetto ma da non testare con questo test in questione)

Inizio con il simulare la pressione del tasto della finestra, andando a il metodo Execute del Comando del ViewModel della finestra che e' legato al pulsante in questione. (Command Pattern)
Vado a verificare tramite il Mock Object che il corretto metodo del servizio remoto sia stato richiamato
Verifico che il Factory relativo al AbstractFactory pattern impiegato dal viewModel per la creazione di nuove finestre abbia creato una nuova finestra del tipo atteso, e ne vado a prendere il ViewModel relativo.
Ottengo il risultato fake del servizio di autenticazione tramite lo Stub, che sara' anche cio' che e' stato passato al ViewModel di questa nuova finestra.
Il ViewModel di questa nuova finestra esporra' probabilmente un elenco di ruoli. Vado a verificare che tale elenco contenga gli stessi elementi restituiti dallo Stub.
Vado a simulare la scelta di alcuni checkbox a caso, agendo sulla relativa proprieta' di ciascun ruolo, tenendo a mente quale e' stata la mia scelta.
Vado a simulare la pressione del tasto OK, richiamando il comando Execute del Command relativo al pulsante di OK, Command residente sul viewmodel di questa nuova finestra.
etc.
Lancio il test e verifico che effettivamente non capita quanto dovrebbe capitare, ma capita invece quanto QA ha dichiarato.
Quindi inizio a cercare il baco, e quando lo trovo rilancio il mio test, e se funziona sono a posto.
Verifico che il mio cambiamento non abbia rotto niente rilanciando tutti gli altri test, e in caso positivo committo sul repository del codice.
(Il quale, non fidandosi, ricompilera' tutto e rilancera' di nuovo tutti i test per conto suo. In caso di errore ci sara' una notifica sui desktop di tutti gli sviluppatori)

Cosa resta fuori da questo test?
Relativamente alla GUI resta fuori il binding tra ciascun ViewModel e la relativa finestra. Se i binding sono corretti allora abbiamo effettivamente simulato un tutto quanto richiesto.
Relativamente al servizio, dobbiamo verificare che il Mock Object e lo Stub relativi al servizio esterno si comportano effettivamente come il servizio esterno stesso.
Abbiamo probabilmente utilizzato uno Stub gia' creato in precedenza per qualche altro test. Altrimenti dobbiamo scrivere anche il test di integrazione per verificarlo. I test di integrazione vengono lanciati meno spesso degli Unit test, proprio perche' capita meno sovente che gli Stub e i Mock vengano cambiati. Essi fanno veramente uso dei servizi esterni, tipicamente nel relativo ambiente di QA.


Nelle 2 settimane di tempo si fa rientrare cio' che si riesce a far rientrare, a seconda del numero di sviluppatori presenti in quel tempo.
C'e' l'elenco delle storie ancora da risolvere, proiritizzate dal cliente a seconda della importanza che lui assegna, tra le quali ci sono anche le storie infrastrutturali scritte dal gruppo di sviluppo stesso (e prioritizzate anch'esse)
Nella metodologia Agile chiamata SCRUM all'inizio delle 2 settimane si pesano (si gioca a poker) e si concordano quali sono le storie che devono essere risolte dal gruppo di lavoro, assegnandole a ciascuna risorsa.
Nella metodologia Agile chiamanta Kanban invece le storie sono considerate una pila, e ogni volta che uno sviluppatore termina una storia va a prendere la prima disponbile e la risolve.
Al termine delle 2 settimane il tempo scade e si pubblica cosa c'e'.
Detto in soldoni, ma in realta' ci sono dei limiti al tipo di storie che possono essere scodate, che dipendono anche dal carico che QA puo' risolvere.
Quando ci sono tempi morti vengono scritti i test di copertura dei metodi scoperti a piu' alta complessita' ciclomatica.

[tomminno]

Originariamente inviato da ^TiGeRShArK^

Puoi sempre rifattorizzare.
Ma se non hai scritto il codice pensando prima ai test "sò cazzi tua ".
Rifattorizzare un codice non adeguatamente coperto dai test equivale a giocare ad una ruolette russa.

Boh tanto i test li devi comunque riscrivere. Se rifattorizzi cambi il codice quindi cambiano anche i test.

Per questo puoi scrivere i mock sia a mano che con librerie che ti semplificano notevolmente il lavoro.

Con i mock testi sempre il codice, non il contesto in cui girerà. Quando esegui i test il codice gira in un ambiente che non è quello a cui è destinato.
Codice perfettamente funzionante ai test può in realtà risultare buggato.

In moltissimi casi i test sono fattibilissimi.
E nei casi che stai considerando in questa discussione, tipici scenari enterprise a quanto ho capito, non solo sono fattibilissimi, ma anche ASSOLUTAMENTE auspicabili.

E come si fanno? Io più che i tradizionali test con NUnit e TypeMock non riesco a fare.
Ad esempio mi è capitato ieri un codice perfettamente funzionante che passava tutti i test ma nel contesto in cui girava (un sito web in Sharepoint) dava errore (dovuto al caching dei dati di Sharepoint).
Risultato ho dovuto modificare il codice per risolvere il problema. Ma i test sul codice erano corretti ed erano ok, solo che occorreva qualche linea di codice in più, ovviamente non testabile, che andasse ad interagire con il sistema, in tal caso il codice nel contesto reale di esecuzione non forniva più errore ma mostrava il comportamento atteso e previsto dai test.

[tomminno]

Originariamente inviato da gugoXX

Direi che e' molto difficile che 2 approcci alla produzione software possano portare ad avere lo stesso codice.

Non capisco perchè no. La stessa persona davanti allo stesso problema potrebbe benissimo scrivere lo stesso codice.

Ci sono anche tecniche che permettono la costruzione di unit test in assenza dei contesti esterni. Queste tecniche sono conosciute con il termine di Mock, e ci sono parecchie librerie che possono aiutare a creare questi Mock object.

Non riuscirei mai a scrivere un Mock che mi simuli il contesto di esecuzione del processo w3wp di IIS e quindi mi consenta di testare il codice in un contesto di esecuzione simile a quello reale.
Capita di avere l'ok in NUnit o CC.NET e poi l'errore su IIS. Cosa cambia? Il contesto.

Il risultato dei test sara' qualcosa come "Se il contesto esterno si comportera' come io penso si debba comportare, allora se questo test viene passato significa che il codice scritto funzionera' anche con il servizio esterno".

Assunzione forte che ho verificato personalmente non rivelarsi vera.
Magari scopri sempre qualcosa di nuovo sul contesto esterno, magari ti manca qualche interazione che non sai di dover fare in assenza della quale il tuo codice in realtà non funziona.

Un caso banale banale di un codice che cerca di accedere al registro di windows sulla chiave CurrentUser. Scrivi tutti i test che ti pare, ti danno tutti ok perchè il codice funziona. Poi il tuo codice viene eseguito in un servizio e in realtà scopri che non funziona. E' un bug del software c'è poco da fare.
Ma non ne hai segnalazione nei test.

Altri casi come path di esecuzione differenti portano, sempre nello stesso contesto, alla non esistenza di alcune variabili di sistema.
Ad esempio sempre quella schifezza di Sharepoint: un codice può risultare perfettamente funzionante se richiamato tramite interfaccia web, ma non funzionare se richiamato da un workflow, perchè mancano i presupposti del sistema affinchè quel codice funzioni correttamente (permessi piuttosto che variabili non esistenti).
Tutto concorre a fare bug nell'applicazione.

Il tempo per la scrittura del codice alla fine diminuisce perche' si evitano i tempi morti e quelli per la integrazione, per la correzione di bachi postumi.

Quali sarebbero i tempi morti?

Verifico che il mio cambiamento non abbia rotto niente rilanciando tutti gli altri test, e in caso positivo committo sul repository del codice.
(Il quale, non fidandosi, ricompilera' tutto e rilancera' di nuovo tutti i test per conto suo. In caso di errore ci sara' una notifica sui desktop di tutti gli sviluppatori)

La notifica automatica a tutti gli sviluppatori mi manca. Abbiamo vari plugin che avvisano delle modifiche ma niente di automatico da parte del server se non email di segnalazione.
Cosa usate per il continous integration? Noi abbiamo CruiseControl .NET.

Nelle 2 settimane di tempo si fa rientrare cio' che si riesce a far rientrare, a seconda del numero di sviluppatori presenti in quel tempo.

Nel mio caso i progetti perdono priorità ad ogni rilascio quindi i tempi generalmente si dilatano: il primo dopo 6 settimane il secondo generalmente dopo 4 per eventuali correzioni, il terzo è capace anche dopo 6 mesi, perchè le priorità sono diventate altre (già dopo il primo rilascio il team dedicato al secondo spesso viene dimezzato, per essere riallocato sui nuovi progetti) e il rapporto costo/benefici di un terzo o successivo rilascio è considerato negativamente.

Direi tutto fuorchè sviluppo agile, ma dopotutto sceglie chi paga, ovvero il cliente.

[gugoXX]

Originariamente inviato da tomminno

Non capisco perchè no. La stessa persona davanti allo stesso problema potrebbe benissimo scrivere lo stesso codice.

difficile che le stesse persone, ma interagenti su un codice in modo diverso, arrivino a dare lo stesso risultato.
Ma tanto e' aria fritta, un po' come se cercassi di convincermi che per risolvere un problema esiste un solo codice ottimale.
Se hai una vaga idea di come fare a dimostrarlo, sei sulla buona strada per dimostrare la riducibilita' dei problemi NP-Completi.

Non riuscirei mai a scrivere un Mock che mi simuli il contesto di esecuzione del processo w3wp di IIS e quindi mi consenta di testare il codice in un contesto di esecuzione simile a quello reale.
Capita di avere l'ok in NUnit o CC.NET e poi l'errore su IIS. Cosa cambia? Il contesto.

Assunzione forte che ho verificato personalmente non rivelarsi vera.
Magari scopri sempre qualcosa di nuovo sul contesto esterno, magari ti manca qualche interazione che non sai di dover fare in assenza della quale il tuo codice in realtà non funziona.

Ogni test ha il suo scopo, preciso e limitato.
Costruire uno Stub per un web server e' abbastanza semplice, e farai uso di quello.
Altri sono i test di integrazione. Puoi testare limitatamente "quanto" hai capito del servizio esterno in un test specifico. Un test come questo avrebbe magari tirato fuori il bug sulla cache di Sharepoint.
Nota anche che non e' tuo scopo testare le funzionalita' di terze parti, ma solo l'integrazione, ovvero solo quanto da te fatto.

Un caso banale banale di un codice che cerca di accedere al registro di windows sulla chiave CurrentUser. Scrivi tutti i test che ti pare, ti danno tutti ok perchè il codice funziona. Poi il tuo codice viene eseguito in un servizio e in realtà scopri che non funziona. E' un bug del software c'è poco da fare.
Ma non ne hai segnalazione nei test.

Questo e' un apporccio sbagliato per un test.
Quando testi il tuo codice non dovrai fare accesso al registro di Windows, ma dovrai itnerfacciarlo ad uno Stub e magari anche un Mock del registro di Windows, che restituisce risultati ben precisi utilizzati per validare quel codice.
Questo Mock, se ben fatto, restituira' valori ben precisi per il CurrentUser.
Un altro test (integrazione) invece servira' per verificare quanto hai capito del registro di Windows, e cerchera' magari di leggere e scrivere delle chiavi.

La notifica automatica a tutti gli sviluppatori mi manca. Abbiamo vari plugin che avvisano delle modifiche ma niente di automatico da parte del server se non email di segnalazione.
Cosa usate per il continous integration? Noi abbiamo CruiseControl .NET.

Usiamo TeamCity e il suo plugin per Visual Studio, con compresa la notify bar per le notifiche di cui sopra.

Comunque ritengo vhe la programmazione di SharePoint sia piu' simile ad un "Configurare" un tool di terze parti piuttosto che uno "Sviluppare" software. Stessa cosa direi per monoliti come SAP.
Ovvio che immersi in un contesto come quello e' difficile fare qualunque cosa, e semplicemente ci si fida del prodotto e di quanto si ha capito.

Concluderei con una considerazione.
Ovviamente quanto qui esposto non serve per te, e ne tu pensavi oramai piu' che sarebbe mai potuto servirti.
Lo sto esponendo per eventuali altri lettori che non si siano ancora addormentati.
Se vai a leggere uno dei documenti linkati sopra, noterai un altro grafico, sul quale si puo' notare la natura media dei detrattori dell'Agile programming.
Essi sono nella stragrande maggioranza dei casi persone che non l'hanno ancora mai provato (e quindi poco attendibili nelle critiche).
Quando inoltre fanno piu' di 3 domande, non lo fanno allo scopo di capire se e' una metodolgia che puo' loro servire, ma piuttosto come critica gratuita, e fanno parte di organizzazioni che molto probabilmente non lo adotteranno mai.
E tu le 3 domande le hai gia' fatte...

[tomminno]

Originariamente inviato da gugoXX

Questo e' un apporccio sbagliato per un test.
Quando testi il tuo codice non dovrai fare accesso al registro di Windows, ma dovrai itnerfacciarlo ad uno Stub e magari anche un Mock del registro di Windows, che restituisce risultati ben precisi utilizzati per validare quel codice.
Questo Mock, se ben fatto, restituira' valori ben precisi per il CurrentUser.
Un altro test (integrazione) invece servira' per verificare quanto hai capito del registro di Windows, e cerchera' magari di leggere e scrivere delle chiavi.

Sta di fatto che il programma reale poi non funziona ugualmente anche se hai fatto tutti i test con e senza Mock verso il registro.

Il programma ha un bug indipendentemente dal fatto che si comporti come previsto nei test (ovvero il test di mancato accesso al registro).

Poichè un servizio non può accedere al CurrentUser sei obbligato a cambiare il codice ed accedere a Users, ma questo non significa che il vecchio codice fosse sbagliato in sè, è il contesto che lo rende sbagliato. Ma i test questo non te lo dicono.
Questo caso è ovviamente solo un esempio, mi è capitato tempo fa che un collega riutilizzasse codice esistente per il suo nuovo servizio, i test erano tutti ok, come provavi il codice svincolato dal servizio tutto funzionava perfettamente, ma una volta inserito nel reale contesto di esecuzione non funzionava...

Comunque ritengo vhe la programmazione di SharePoint sia piu' simile ad un "Configurare" un tool di terze parti piuttosto che uno "Sviluppare" software. Stessa cosa direi per monoliti come SAP.

Finchè qualcuno non si mette in testa di fare un sito "enterprise" utilizzando Sharepoint come base...
A tutti i problemi di progetto sollevati (numero massimo di record globali gestibili, mancanza di transazionalità, ecc) il cliente ha risposto che va bene così perchè il vantaggio dell'utilizzo di dati destrutturati è stato considerato prevalente rispetto ai problemi evidenziati. Ma è ovvio che poi una volta in produzione tutto questo risulterà un grave handicap, ma il cliente rifiuta di prendere atto di questo. Quando ci sbatterà il muso saranno dolori perchè dovremo trovare soluzioni a problemi architetturali in tempi rapidi.

Programmare all'interno di Sharepoint è una rogna allucinante. Possibilità di debug pari a 0, possibilità che il codice smetta di funzionare da un momento all'altro altissima (basta che qualche utente modifichi qualche impostazione e il codice sottostante sicuramente smetterà di funzionare, tutto già previsto anche nei test). Possibilità di eseguire i test dentro Sharepoint praticamente nulla, ovvero io vedrò sempre verde anche quando niente funzionerà più.

Se vai a leggere uno dei documenti linkati sopra, noterai un altro grafico, sul quale si puo' notare la natura media dei detrattori dell'Agile programming.
Essi sono nella stragrande maggioranza dei casi persone che non l'hanno ancora mai provato (e quindi poco attendibili nelle critiche).
Quando inoltre fanno piu' di 3 domande, non lo fanno allo scopo di capire se e' una metodolgia che puo' loro servire, ma piuttosto come critica gratuita, e fanno parte di organizzazioni che molto probabilmente non lo adotteranno mai.
E tu le 3 domande le hai gia' fatte...

Ci sono delle pratiche dell'agile programming che nel mio contesto di lavoro non sono assolutamente applicabili (su tutti pubblicare in produzione, il rischio di fare danni costosi da rimediare sarebbe troppo alto) e ci sono assunti che sempre nel mio contesto non risultano veri (il cliente non si accorge subito degli errori).
Infine le iterazioni: le priorità dei progetti cambiano molto velocemente, difficilmente un progetto arriva a 3 pubblicazioni. Dopo 2 è già concluso (3 mesi al massimo, non si parla comunque di tempi lunghi).
Oltretutto i miei rilasci sono spesso condizionati a rilasci contemporanei da parte di aziende esterne (oppure legati a campagne di marketing), non potrei mai modificare il sistema interno senza che anche i sistemi esterni siano aggiornati.
Insomma mi ritrovo con troppi vincoli per addentrarmi completamente nello sviluppo agile, di cui fondamentalmente ho adottato soltanto i test sul codice (e non credo nemmeno che si possa definire Test Driven, visto che i test vengono scritti dopo il codice).

[zakmckraken]

Ciao a tutti!
Ma..una domanda, se uno lavora in un progetto in cui sono coinvolti 6 gruppi da una ventina di persone, in 4 localita'diverse che devono lavorare su sei moduli di una applicazione enterprise. Moduli che richiedono accesso a WebServices esterni, code JMS, interfacce web complesse (100/150 forms), reportistica su pdf/excel, tutto in multilingua, telecamere e sensori, su commessa statale quindi con un capitolato.
Io vedrei sinceramente piu'realistico un'approccio tipo UP piu'che uno agile, solo definire le interfacce diventa un delirio (premetto che parlo di un progetto reale ed in corso di completamento) !! Oltre che i clienti tipicamente vogliono sapere quanto tempo ci vorra'e quanto spendera'per il progetto, finche si parla di un sito web o di una applicazione medio piccola posso capire (penso ad un post qualche pagina fa che diceva appunto questo) ma un coso tipo quello descritto sopra non puo'essere non deterministico (imho).
Potrei essere daccordo a sviluppare secondo metodologie agili le sottoparti di cui sono composti i singoli moduli ma non senza una analisi corposa e precisa di interfacce interazioni e use cases su tutto il progetto.

Ripeto, tutto imho, intanto sto cercando di capire meglio il tutto...

[fero86]

Originariamente inviato da gugoXX

Esattamente in che senso?

nel senso: "esattamente, quel grafico é una gran cavolata, non é il risultato di una statistica ma una curva disegnata appositamente per esporre un concetto opinabile in quanto molto variabile da un caso all'altro."

Cosa itendi per "senza riscontro statistico"?

che sono un sacco di belle teorie non verificate ne' formalmente ne' empiricamente. all'inizio della pagina l'autore dice che queste teorie vengono soltanto dalla sua esperienza e da quella di migliaia di altre fantomatiche persone:

One of the great debates raging within the IT industry is whether or not agile software development techniques work. My experience, and the experience of thousands of others, is that they do.

dice che é soltanto la sua opinione:

One of several reasons why agile techniques are so effective, in my opinion, is that they reduce the feedback cycle between the generation of an idea (perhaps a requirement or a design strategy) and the realization of that idea. [...] In this article I explore this idea in detail.

Per dichiarare determinate percentuali come 72%, 19% etc. avranno pure dei dati sotto mano immagino.

ecco, sarei stato felice di leggerli nella pagina che mi hai linkato, nella quale non vedo 72, non vedo 19 e non vedo neanche eccetera.

ad ogni modo, tornando al mio argomento iniziale, ci tenevo a precisare che quel grafico era una fesseria perché nella discussione si é detto che quando si osserva qualcosa empiricamente bisogna riportare i dati a testimoniarlo (e giá tocca fidarsi che i dati siano reali e onesti) e i tre grafici che sconquassano il layout della pagina precedente sono i dati che tu hai riportato, ma va precisato che l'ultimo dei tre non raffigura dei dati raccolti, é solo un disegno creato ad hoc per esporre un concetto che a mio dire resta molto opinabile finché qualcuno non lo supporta con dei dati veri e onesti. tutto qui.

[gugoXX]

Originariamente inviato da zakmckraken

Ciao a tutti!
Ma..una domanda, se uno lavora in un progetto in cui sono coinvolti 6 gruppi da una ventina di persone, in 4 localita'diverse che devono lavorare su sei moduli di una applicazione enterprise. Moduli che richiedono accesso a WebServices esterni, code JMS, interfacce web complesse (100/150 forms), reportistica su pdf/excel, tutto in multilingua, telecamere e sensori, su commessa statale quindi con un capitolato.
Io vedrei sinceramente piu'realistico un'approccio tipo UP piu'che uno agile, solo definire le interfacce diventa un delirio (premetto che parlo di un progetto reale ed in corso di completamento) !! Oltre che i clienti tipicamente vogliono sapere quanto tempo ci vorra'e quanto spendera'per il progetto, finche si parla di un sito web o di una applicazione medio piccola posso capire (penso ad un post qualche pagina fa che diceva appunto questo) ma un coso tipo quello descritto sopra non puo'essere non deterministico (imho).
Potrei essere daccordo a sviluppare secondo metodologie agili le sottoparti di cui sono composti i singoli moduli ma non senza una analisi corposa e precisa di interfacce interazioni e use cases su tutto il progetto.

Ripeto, tutto imho, intanto sto cercando di capire meglio il tutto...

Sembra uno di quei progetti da me descritti all'inizio, come esempio di progetti che giungono prima o poi a problemi che possono minare l'intera fattibilita'.
Giunti alla fine mi dirai quanto tempo si spendera' per l'integrazione finale di tutte le parti, nonostante le interfaccie e interazioni siano state ben decise a priori.
Sempre che il cliente non cambi idea alla fine su qualche funzionalita' che magari va ad intaccare proprio il substrato comune, la prima volta che gli farete vedere qualcosa.

L'approccio Agile in questi casi suggerisce di iniziare con un piccolo gruppo di lavoro a creare le interfaccie e tutta la sovrastruttura. Ma non solo a studiare. Proprio a scrivere e creare il codice relativo a questa sovrastruttura.
Poi in seguito si possono aggiungere gli altri seguenti gruppi di lavoro, ognuno a seguire un modulo specifico, che potranno scrivere e testare le loro parti direttamente con quello che sara' l'architettura finale, mostrando di volta in volta al cliente.

Comunque il progetto che sto seguendo ora non e' cosi' grande in quanto a numero di persone coinvolte, ma e' comunque complesso in quanto a moduli. un modulo principale (le tue interfaccie di cui sopra) e 4 domini seguiti da diversi gruppi di sviluppo, ciascuno con sviluppatori GUI e ServerSide, e l'approccio seguito e' stato proprio questo.

Ah, il fatto che nella metodologia agile si stimoli parecchio il pair programming e il peer reviewing rende anche il gruppo di lavoro stesso resistente alle persone che se ne vanno. A meno che non se ne vadano tutte insieme c'e' sempre il giusto livello di competenza nel gruppo.
Sviluppare in 2 davanti allo stesso monitor da soddisfazioni incredibili. E' un ottimo mezzo di passaggio di conoscenze tra piu' esperti a meno esperti, un modo per condividere trucchi, evitare errori banali e parere mio si sviluppa piu' in fretta che in 2 macchine separatamente.

[gugoXX]

Originariamente inviato da fero86

nel senso: "esattamente, quel grafico é una gran cavolata, non é il risultato di una statistica ma una curva disegnata appositamente per esporre un concetto opinabile in quanto molto variabile da un caso all'altro."

Hai letto da qualche parte che quel grafico in particolare e' una statistica?
Hai mai visto il grafico risultato da una statistica, pensi che una parabola perfetta possa essere uno di questi?
Pensi che a qualcun altro all'infuori di te possa essere venuto in mente che quello e' il grafico di una vera raccolta dati?
Riesci a trovare grossi errori nella stima dei tempi riportati?
Ritieni spesso che quanto riportato da altri sia "fesseria"?

[fero86]

Originariamente inviato da ^TiGeRShArK^

boh...
non l'ho manco aperta quella pagina..
ma so solo che quelle teorie che secondo alcuni sarebbero "campate in aria" nella pratica funzionano perfettamente.

mi sento chiamato in causa visto che sono l'unico ad aver usato quell'espressione mi pare.

permettimi di obiettare che, non avendo aperto la pagina, non hai neanche idea di quali teorie si stia parlando. é troppo scontata come obiezione?

[pequeno]

Originariamente inviato da gugoXX

...per le GUI e' consigliato MVC (Model-View-Controller) o MVVM (Model-View-ViewModel)...

Per quanto riguarda la metodologia Agile, la trovo molto interessante e, sebbene la scrittura dei test possa sembrare tediosa, consente un'elevata manutenibilità del codice (a lungo andare fa la differenza).

Per quanto concerne il testing di applicativi web, quali tool/framework utilizzate di solito (per l'interfaccia, test interattivi, etc.)? HttpUnit o simili??

[gugoXX]

Originariamente inviato da pequeno

Per quanto riguarda la metodologia Agile, la trovo molto interessante e, sebbene la scrittura dei test possa sembrare tediosa, consente un'elevata manutenibilità del codice (a lungo andare fa la differenza).

Per quanto concerne il testing di applicativi web, quali tool/framework utilizzate di solito (per l'interfaccia, test interattivi, etc.)? HttpUnit o simili??

Viene applicato MVVM anche per le interfaccie web, e viene testata solo ma tutta la logica (Il ViewModel) negli unit test scritti dagli sviluppatori.
Per il test delle form invece si demanda a QA, che di solito per l'automazione dei test puramente GUI usa framework come QTP.
La QA di un altro gruppo di lavoro usa un framework chiamato SAHI, che e' open source.

Uno dei miei collaboratori QA mi dice ora di avere usato in passato un altro tool chiamato Selenium per automatizzare i test per web.

[fero86]

Originariamente inviato da gugoXX

Hai letto da qualche parte che quel grafico in particolare e' una statistica?

prendi un bel respiro e rilassati: non é un problema che nessuno l'abbia detto.

Hai mai visto il grafico risultato da una statistica, pensi che una parabola perfetta possa essere uno di questi?

e secondo te io cosa stavo obiettando allora?

Pensi che a qualcun altro all'infuori di te possa essere venuto in mente che quello e' il grafico di una vera raccolta dati?

il mio discorso é un altro: con un disegno che espone un concetto opinabile non supportato da una verifica onestaci facciamo poco. chi mi dice che quel disegno rappresenti la realtá delle cose?

Riesci a trovare grossi errori nella stima dei tempi riportati?

non ho abbastanza persone, ne' risorse economiche ne' motivazioni per verificare raccogliendo dati, e a quanto pare non ne aveva neanche chi ha fatto il disegno. tuttavia non significa che non ci possano essere grossi errori.

Ritieni spesso che quanto riportato da altri sia "fesseria"?

é il segreto del successo.

[fero86]

Originariamente inviato da ^TiGeRShArK^

P.S. A proposito.. che fine hanno fatto tutti i post nella sezione DIAMONDS????!?!??!?!?

mi dispiace dirtelo ma quel progetto é morto: era un progetto agile

[gugoXX]

In sostanza avevi capito poco, non hai i mezzi per verificare e ritieni che il parere altri sia a priori una fesseria, motivandolo come segreto di successo.

Vabbe'. Buon proseguimento.

mi dispiace dirtelo ma quel progetto é morto: era un progetto agile

Piu' che altro mi sembra di avere capito che fosse un progetto open-source e non pagato. Non molti sono disposti a lavorare con continuita', solo per la causa.

[fero86]

Originariamente inviato da gugoXX

In sostanza avevi capito poco,

ah si? e spiegami tu allora, mi sembra troppo facile uscirsene con "buon proseguimento".
ma ho idea che non mi spiegherai un bel nulla, vero? chissá perché.

Piu' che altro mi sembra di avere capito che fosse un progetto open-source e non pagato.

non era solo open-source, era addirittura public domain: chiunque puó farcene quello che gli pare, ma io francamente non ho trovato molto semplice accedere a sti sorgenti.

[^TiGeRShArK^]

Originariamente inviato da tomminno

Sta di fatto che il programma reale poi non funziona ugualmente anche se hai fatto tutti i test con e senza Mock verso il registro.

Il programma ha un bug indipendentemente dal fatto che si comporti come previsto nei test (ovvero il test di mancato accesso al registro).

Poichè un servizio non può accedere al CurrentUser sei obbligato a cambiare il codice ed accedere a Users, ma questo non significa che il vecchio codice fosse sbagliato in sè, è il contesto che lo rende sbagliato. Ma i test questo non te lo dicono.

E per quale motivo?
Basta dare i privilegi di utente locale al servizio e può fare quello che vuole su currentUser utilizzando le credenziali dell'utente inserito.
Quello che dici vale per i network e i local system services.
Quindi il problema non è un problema dei test ma dalla tua scarsa conoscenza del dominio che ti ha fatto scrivere un mock errato dato che il mock corretto non permette ai servizi di sistema e di rete di accedere alle chiavi del current user dato che utilizza un account legato alla macchina e non all'utente.

Questo caso è ovviamente solo un esempio, mi è capitato tempo fa che un collega riutilizzasse codice esistente per il suo nuovo servizio, i test erano tutti ok, come provavi il codice svincolato dal servizio tutto funzionava perfettamente, ma una volta inserito nel reale contesto di esecuzione non funzionava...

Anche in questo caso bisogna costruire il mock in maniera corretta, se i test non passano vuol dire che non si è capito come funziona il sistema con cui interfacciarsi ed il mock è errato.

Finchè qualcuno non si mette in testa di fare un sito "enterprise" utilizzando Sharepoint come base...
A tutti i problemi di progetto sollevati (numero massimo di record globali gestibili, mancanza di transazionalità, ecc) il cliente ha risposto che va bene così perchè il vantaggio dell'utilizzo di dati destrutturati è stato considerato prevalente rispetto ai problemi evidenziati. Ma è ovvio che poi una volta in produzione tutto questo risulterà un grave handicap, ma il cliente rifiuta di prendere atto di questo. Quando ci sbatterà il muso saranno dolori perchè dovremo trovare soluzioni a problemi architetturali in tempi rapidi.

Programmare all'interno di Sharepoint è una rogna allucinante. Possibilità di debug pari a 0, possibilità che il codice smetta di funzionare da un momento all'altro altissima (basta che qualche utente modifichi qualche impostazione e il codice sottostante sicuramente smetterà di funzionare, tutto già previsto anche nei test). Possibilità di eseguire i test dentro Sharepoint praticamente nulla, ovvero io vedrò sempre verde anche quando niente funzionerà più.

Questo è purtroppo abbastanza vero.
L'ambiente + orrendo su cui ho lavorato è proprio sharepoint.
Però in realtà puoi debuggare se il problema è nel codice che hai scritto tu, non puoi fare niente se per caso ti scompare la webpart che è stata correttamente deployata e ti dice che non la trova sparandoti errori del cazzo nei log.
L'unico modo che avevo per risolverla, dopo aver creduto di non aver capito una mazza di come effettuare il dispose di SPWeb e di SPSite era fare un clean, fare un retract della soluzione, uscire da visual studio, rientrare ribuildare e ri-deployare.
Ma questo non ha nulla a che fare col codice.
Il mio codice per le webpart era praticamente PROCEDURALE dato che per fortuna non sono di una complessità elevata e avevo paura di qualche strano comportamento (tipo col redirect che non funziona a seconda del punto del codice in cui lo metti e della tecnica utilizzata... bisogna provare tute le combinazioni possibili per farlo andare. ).
Ecco, questa è una situazione in cui mi concentrerei sui santi da invocare piuttosto che sulla programmazione.
Mi è capitato di scrivere codice davvero banale, roba da 10 minuti, e di metterci due giorni a farlo funzionare.
La cosa buona è che almeno pagavano bene e ora ho finito di metterci mano finalmente.

Ci sono delle pratiche dell'agile programming che nel mio contesto di lavoro non sono assolutamente applicabili (su tutti pubblicare in produzione, il rischio di fare danni costosi da rimediare sarebbe troppo alto) e ci sono assunti che sempre nel mio contesto non risultano veri (il cliente non si accorge subito degli errori).
Infine le iterazioni: le priorità dei progetti cambiano molto velocemente, difficilmente un progetto arriva a 3 pubblicazioni. Dopo 2 è già concluso (3 mesi al massimo, non si parla comunque di tempi lunghi).
Oltretutto i miei rilasci sono spesso condizionati a rilasci contemporanei da parte di aziende esterne (oppure legati a campagne di marketing), non potrei mai modificare il sistema interno senza che anche i sistemi esterni siano aggiornati.
Insomma mi ritrovo con troppi vincoli per addentrarmi completamente nello sviluppo agile, di cui fondamentalmente ho adottato soltanto i test sul codice (e non credo nemmeno che si possa definire Test Driven, visto che i test vengono scritti dopo il codice).

Diciamo che il problema è che con sharepoint la parte di programmazione è marginale come dicevo prima.

[^TiGeRShArK^]

Originariamente inviato da fero86

mi dispiace dirtelo ma quel progetto é morto: era un progetto agile

A parte che è morto per mancanza di tempo di noi tutti che ricordo lavoravamo normalmente durante il giorno e avevamo magari anche altri progetti da seguire.....
Ma sono stati proprio CANCELLATI i post.

[banryu79]

Originariamente inviato da ^TiGeRShArK^

Ma sono stati proprio CANCELLATI i post.

Peccato perchè ogni tanto andavo a consultare quel materiale a scopo di studio e per curiosità, sia per vedere come erano state concepite le storie che per quanto riguardava la parte più strettamente inerente le pratiche di TDD.

@GugoXX: grazie per le esaurienti informazioni e spiegazioni; per me sono state molto interessanti. Il pair-programming mi piacerebbe molto provarlo un giorno.