View Full Version : Di quel dicono Fowler e Beck
Faccio un "fork" di una discussione, iniziando con una replica ad una replica, perchè l'argomento è di là off topic ma è una cosa a cui io sono vivacemente interessato.
No, per diventare il nuovo Fowler devi anche condire quello che scrivi con vent'anni di esperienza e studi pratici che dimostrano che quello che dici aumenta effettivamente la produttivita', date determinate condizioni. Altrimenti sei solo un tizio con in mano due sassetti e non aggiungi nulla all'Ingegneria del Software (che ricordo essere lo studio delle metodologie di sviluppo che portano ad un aumento della produttivita').
Studi di questo tipo:
http://portal.acm.org/citation.cfm?...UIDE&coll=GUIDE
http://www.cigital.com/solutions/roi-cs1.php
Once the automated unit tests were in place, the hours that developers spent conducting manual tests plummeted (to approx. 40 hours per release), resulting in a savings of $112,000 per year in developer time. The client was also provided with metrics for demonstrating continuing ROI through the application of automated unit testing. The chart below shows the cost savings over five years. The first bar shows the costs for manual testing while the second bar shows the costs for automated testing.
Riguardo a Refactoring e TDD:
http://www.adaptionsoft.com/xp_how.html
Craig Larman's latest book quotes studies showing that "broadly, defect reduction comes from avoiding defects before they occur and from feedback" such as tests and evaluations. One study showed that as the time lag between coding and testing decreased, defect rates likewise decreased.
Test-Driven Development, together with refactoring, effectively eliminate the sad tradition of open-ended debugging, replacing it with "pre-bugging": finding and eliminating bugs at inception. The practice of continuous integration is also credited by Larman and others with lowering defect rates and increasing productivity.
Qui potrai trovare un buon numero di studi e statistiche a riguardo:
http://www.amazon.com/gp/product/01...507846&v=glance
E qui puoi trovare un'applicazione allo sviluppo dei VG:
https://www.cmpevents.com/GD06/a.as...=11&SessID=1512
Ero presente a questa lecture e nelle slide puoi trovare le loro statistiche a riguardo.
Il che riporta all'argomento del thread: senza studiare cio' che hanno fatto prima di te puoi solo cercare di risolvere problemi nuovi "alla meglio". Con lo studio, l'esperienza e la creativita puoi risolverli "al meglio". La filosofia e il problem solving sono due campi profondamente diversi.
Naturalmente ho il più assoluto rispetto per il pensiero altrui. Ma sarebbe più corretto dire "per me sono due campi profondamente diversi" perchè per qualcun'altro non lo sono affatto. Se si ha una voce autorevole (anche involontariamente) è importante dare conto delle proprie opinioni altrimenti qualcuno finisce per credere che siano fatti.
Devo precisare che la mia critica è rivolta a quello che ho letto di ciò che ha scritto Fowler (preceduto di una lunghezza da Beck) e non al risultato di chi abbia applicato il ciò di cui egli pare aver parlato: ancora non ho capito dove andare a recuperare gli studi (non gli articoli sugli studi nè le legittime esperienze di qualcuno, gli studi) perchè non sono a buon mercato e 5000 dollari per soddisfare una curiosità potrebbero non essere pochi :D. Spero sempre nelle biblioteche universitarie :) ma (neanche a farlo apposta) non c'è ingegneria nei miei paraggi ( :cry: ).
Ciò che dice in quel poco di suo che ho letto (Refactoring, Planning Extreme Programming) è infondato. E non è che la fondatezza di un discorso sia disponibile: o è o non è.
E il refactoring è particolarmente delicato perchè potrebbe anche avere un senso.
Ne piglio uno a caso: extract method.
Nell'introduzione al capitolo sei si dice che molti problemi nascono da metodi troppo lunghi. Perchè? Non si sa.
Sulla base di questo non-fatto, si dovrebbe usare lo Extract Method. Di questo Fowler ci da anche un motivo: è uno di quelli che lui applica più comunemente. Il che è una tautologia (:D so che la filosofia ti fa schifo :D ma questo è). La ragione per cui applichiamo Extract Method è che lui lo applica spesso.
Non basta. Lo stesso "motivo" prosegue con un bel: i nomi dei metodi devono essere concisi e significativi. Vi siete mai chiesti "perchè?". Qual'è la ragione per cui un ipotetico nome:
xyx(a, b, c)
sarebbe peggiore di:
sommaValori(valoreA, valoreB, valoreC)
E' intuitivo? Be', anche a me la seconda soluzione appare più significativa, ma il problema è "perchè". Sapendo perchè saprei anche quali nomi siano più significativi di altri. Ora, io non voglio insegnare a nessuno a leggere i libri, ma è a questo punto uno prende e va a vedere la bibliografia: lo sa ma non lo dice perchè l'ha detto qualcun'altro. Tralasciando il fatto che Refactoring è un caso di autoreferenzialità impressionante, nessuno dei libri citati (7 mesi di lettura) tratta di questo perchè o degli altri perchè di questo amabile volume.
La cosa divertente è che Fowler dimostra pure di saper esporre con grande onestà ciò che vuole. In quel "Per me la chiave è la distanza di significato (semantica) tra il nome del metodo e il nome del corpo" c'è un che di profondamente onesto: "per me". Il problema diventa quando parlando di refactoring qualcuno trasforma il "per me" in "per tutti".
Passare da "per me" o "per noi" a "per tutti" è un atto che richiede un dispendio enorme in ricerca, mi sembra che raramente dia i risultati "sperati" (una ricerca ovviamente non spera nulla in sè) senza il quale è profondamente disonesto per chi legge.
Tutta sta manfrina per dire che l'acquisizione di conoscenza è simile alla nutrizione: non si può buttar giù una bistecca intera, bisogna anche masticarla. E a me pare che la bistecca del TDD sia particolarmente.
Voi cosa ne pensate? (sentitivi liberi di prendermi a merluzzate se vi sembri il caso :D).
Faccio un "fork" di una discussione, iniziando con una replica ad una replica, perchè l'argomento è di là off topic ma è una cosa a cui io sono vivacemente interessato.
Secondo me era in topic, ma un tale argomento merita decisamente un suo topic a parte, quindi va benissimo proseguire qui :)
Devo precisare che la mia critica è rivolta a quello che ho letto di ciò che ha scritto Fowler (preceduto di una lunghezza da Beck) e non al risultato di chi abbia applicato il ciò di cui egli pare aver parlato: ancora non ho capito dove andare a recuperare gli studi (non gli articoli sugli studi nè le legittime esperienze di qualcuno, gli studi) perchè non sono a buon mercato e 5000 dollari per soddisfare una curiosità potrebbero non essere pochi :D. Spero sempre nelle biblioteche universitarie :) ma (neanche a farlo apposta) non c'è ingegneria nei miei paraggi ( :cry: ).
Il primo studio dovrebbe essere tu che applichi quello strumento e impari dove ti da' un aumento di produttivita' e dove non te lo da'. Ho linkato anche un libro in particolare che contiene numerosi studi a riguardi (il libro costa una qualche decina di euro).
Code Complete 2 e' un altro libro con grande abbondanza di richiami a studi piuttosto autorevoli sullo unit testing e il refactoring:
http://www.cc2e.com/
Notare che l'autore di Code Complete non e' un Agile Advocate.
Ciò che dice in quel poco di suo che ho letto (Refactoring, Planning Extreme Programming) è infondato. E non è che la fondatezza di un discorso sia disponibile: o è o non è.
Puoi dimostrare che e' infondato o lo affermi solo? Mi riporti un solo studio che lo provi? Quali alternative proponi? Non puoi parlare di affermazioni categoriche non provate e poi farne una tu in questo modo.
Come non puoi affermare che lo strumento del Refactoring (perche' e' uno strumento) e' infondato. E' come dire che il martello e' infondato. In relazione a che cosa? Per cucinare un martello non e' certo lo strumento migliore, per piantare un chiodo si'.
Quindi, dimmi, per aumentare la produttivita' in una situazione in cui le specifiche tendono a cambiare, che cosa proponi come alternativa al Refactoring?
Ne piglio uno a caso: extract method.
Nell'introduzione al capitolo sei si dice che molti problemi nascono da metodi troppo lunghi. Perchè? Non si sa.
Si sa' invece. Code Complete 2 riporta alcuni studi di IBM (cito a memoria) che dimostra come il defect rate di un metodo, calcolato in difetti per numero di righe di codice, e' proporzionale alla lunghezza del metodo. Extract Method e' una delle "cura". Che cosa proponi come alternativa per mantenere il defect rate basso?
Non basta. Lo stesso "motivo" prosegue con un bel: i nomi dei metodi devono essere concisi e significativi. Vi siete mai chiesti "perchè?". Qual'è la ragione per cui un ipotetico nome:
xyx(a, b, c)
sarebbe peggiore di:
sommaValori(valoreA, valoreB, valoreC)
E' intuitivo? Be', anche a me la seconda soluzione appare più significativa, ma il problema è "perchè". Sapendo perchè saprei anche quali nomi siano più significativi di altri. Ora, io non voglio insegnare a nessuno a leggere i libri, ma è a questo punto uno prende e va a vedere la bibliografia: lo sa ma non lo dice perchè l'ha detto qualcun'altro. Tralasciando il fatto che Refactoring è un caso di autoreferenzialità impressionante, nessuno dei libri citati (7 mesi di lettura) tratta di questo perchè o degli altri perchè di questo amabile volume.
Perche' di nuovo esistono studi precisi su come il nome di variabili e metodi influenzi il defect rate del codice e la produttivita' del team.
La cosa divertente è che Fowler dimostra pure di saper esporre con grande onestà ciò che vuole. In quel "Per me la chiave è la distanza di significato (semantica) tra il nome del metodo e il nome del corpo" c'è un che di profondamente onesto: "per me". Il problema diventa quando parlando di refactoring qualcuno trasforma il "per me" in "per tutti".
Ti rimando nuovamente agli studi di cui sopra. Anche questi sono riportati in Code Complete 2.
Voi cosa ne pensate? (sentitivi liberi di prendermi a merluzzate se vi sembri il caso :D).
Io penso che il buon programmatore debba avere il piu' ampio bagaglio di strumenti a disposizione possibili e debba saper usare lo strumento giusto al momento giusto, al di la' delle lotte di religione. Nel mio caso, fare Refactoring in maniera costante mentre scrivo codice (e scrivo codice da piu' di quindici anni) ha aumentato visibilmente la mia produttivita' e abbassato il mio defect rate. Tengo le statistiche su me stesso e sulla mia produttivita' che si basano sulla mia stima dei task ed ho notato un aumento di produttivita' notevole da quanto faccio Refactoring in maniera consapevole. E con me hanno notato questo i producer che mi gestiscono. Mai farei Refactoring due giorni prima di una milestone (saper usare lo strumento giusto al momento giusto).
A questo si aggiungono gli studi che ho letto e l'esperienza di molto altri, a formare un quadro completo sullo strumento.
Se mi proponi un'alternativa che aumenti la mia produttivita', saro' felicissimo di provarla e ancora piu' felice se si rivela davvero una valida alternativa. Se mi dici che gli argomenti a favore del Refactoring sono infondati perche' lo sono senza alternative valide, continuo con le pratiche che funzionano nelle situazioni in cui funzionano :)
Infine, come avrai notato, a me i discorsi teorici piacciono poco, sono un praticone. E il progetto Diamonds e' un'ottima prova di cio' che ho scritto qui: unit testing, refactoring, keep it simple, continuous integration sono core practice del progetto e sembrano funzionare. Il progetto va avanti da mesi, ha date di uscita prevedibili e realistiche, il defect rate e' bassissimo come la First Playable ha dimostrato (qualcosa tipo meno di 50 bug dopo un deploy al pubblico e' un numero insignificante).
Quali alternative proporresti per abbassare ulteriormente il defect rate di Diamonds e migliorarne la produttivita'?
Io parlo della questione teorica.
Non ho nulla contro il refactoring in sè e ammetto con serenità che dopo aver provato, pur rifiutando la questione teorica, trovo ormai inevitabile applicare io stesso molte di quelle mutazioni del codice che Refactoring descrive molto bene.
Ma un conto è dire che funziona e per me potrebbe anche funzionare benissimo, un conto è capire perchè funziona.
Vivendo nella famosa torre d'avorio potrei anche dire che senza il perchè non si muove un passo. Professionalmente le occasioni di parlare della fondatezza di ciò che applichiamo sono eufemisticamente pochine.
Io sono veramente e seriamente interessato agli studi, alle statistiche di applicazione del TDD e dell'ampio mondo dello sviluppo agile. Non sono interessato ai libri che fanno riferimento agli studi: la probabilità che una fonte indiretta dia un'interpretazione orientata è molto alta. C'è un problema di accesso, CHAOS costa 5000 ballerozzi e per uno "se" non sono pochi.
Gli studi (che pure vanno letti e che io NON ho letto) logicamente non dimostrano nulla: possono e vogliono dire solo se un certo fenomeno si verifichi o meno. Lo studio è poi usato per falsificare la teoria.
Comunque il mio patema non è questo.
Ora, gli studi dimostrano che il Refactoring aumenta la resa e, anche più importante, migliora il prodotto? Io ne sono felicissimo e professionalmente non posso che applicare il Refactoring.
Ma perchè il Refactoring migliora la situazione? C'è stata questa geniale intuizione che funziona, perchè... non se lo chiede nessuno. Funziona e basta. Per me è inaccettabile dire così.
Uno strumento non è fondato o infondato. E' solo adeguato o inadeguato, secondo il grado di successo al fine che garantisce: massimamente inadeguato se risulti logicamente impossibile raggiungere il fine usandolo.
Infatti io non ho detto che il Refactoring in quanto strumento è infondato. Io ho detto (e tu hai citato):
Ciò che dice in quel poco di suo che ho letto (Refactoring, Planning Extreme Programming) è infondato. E non è che la fondatezza di un discorso sia disponibile: o è o non è.
Mi esprimo con più precisione a scanso di ulteriori equivoci. Molte delle proposizioni contenute nelle "motivazioni" connesse all'uso delle tecniche di refactoring, descritte nel libro in questione, sono tautologie: l'Autore tende a dimostrare le sue affermazioni presupponendo la verità delle affermazioni stesse. Immagino che questo non richieda una puntuale evidenziazione da parte mia dei casi di cui parlo, chiunque abbia un'infarinatura di logica e quel libro può rendersene conto, ma se del caso posso darla.
Sarebbe alquanto scorretto da parte mia affermare che Fowler dica frottole e devo putroppo riquotarmi:
Ne piglio uno a caso: extract method.
Nell'introduzione al capitolo sei si dice che molti problemi nascono da metodi troppo lunghi. Perchè? Non si sa.
Non mi sembra di dire che esistano studi che negano la connessione tra lunghezza dei metodi e produttività/qualità e tantomento che non esistano studi che confermino quell'ipotesi nè che Fowler dica il falso. Dico che nel libro manca la spiegazione del perchè quel fenomeno si verifichi, cosa confermata dalle rilevazioni. E la cosa che mi "spaventa" è che il motivo manca sebbene Fowler indichi esplicitamente alcune pseudo-proposizioni come la ragione dell'applicabilità delle tecniche descritte.
Ho letto il libro di Beck sul TDD...ed ho appena iniziato Refactoring di Fowler...
Posso quindi esprimere un mio giudizio sul TDD...ovviamente non è derivato da studi teorici, ma solo dall'esperienza pratica...
Prendi il caso di Diamonds... Siamo un team non omogeneo, sia dal punto di vista culturale informatico, che dal punto di vista dell'esperienza...
Sicuramente è più facile scrivere test che scrivere una soluzione che funziona al primo colpo per un problema...su questo penso che non ci siano dubbi...
Il test stesso ti obbliga ad entrare nella mentalità della soluzione... Magari prima di scrivere il test pensavi di risolvere il tuo problema in tutt'altro modo... Ma sai che devi scrivere il codice più semplice che funziona per rendere al più presto possibile verde il test...e vai a testa bassa a scrivere il codice che fa passare il test...
Si eliminano le eventuali duplicazioni e si va al prossimo test...
Ecco che abbiamo completato una parte del nostro task....e questo praticamente senza margine di errore (o almeno il margine dipende da quanto i test coprono il dominio degli ingressi e le sequenze di chiamata)... Il TDD tende ad indirizzare le persone che scrivono il codice verso una determinata soluzione...
Prendi 10 persone e proponi in sequenza i test....vedrai che 8 su 10 arriveranno alla medesima soluzione...
I test guidano il programmatore a scrivere la soluzione che la sequenza di test vuole imporre...
Ed ecco che hai uniformato un team di sviluppo non omogeneo...ed allora mi dirai: cosa studaimo a fare ?
I refactoring sono la via cruciale di un codice funzionale e manutenibile... Le conoscenze, le esperienze e, perchè no, la genialità di ognuno di noi vengono fuori proprio nei momenti di refactoring...
Se il TDD è il conformismo che spinge tutti ad una soluzione comune, il refactoring è il suo alter ego geniale...l'intuito o l'esperienza che ti guida verso una forma già vista o inventata su due piedi...ma sempre con i test che mettono dei paletti che non puoi prevaricare...
Heilà, quasi dimenticavo di raccogliere il guanto di sfida con cui mi hai schiaffeggiato :D.
Diamonds. Beh, la dico per come la penso: per me funziona perchè avete scelto un modello di sviluppo, lo avete seguito e siete riusciti a mantenere un buon livello di comunicazione (ok, qualcosa di Beck in fondo mi va a genio :D). A prescindere dal modello: avreste potuto usare il waterfall e sareste arrivati lo stesso alla fine del tunnel.
Meglio o peggio? Eh eh, questo è un domandone. Bisognerebbe tentare l'assurdo: cancellarvi la memoria e rifare tutto con un'altro modello di sviluppo. Poi confrontare il risultato.
Ecco perchè mi appassiona la questione "teorica": è quantomeno difficile capire quanto realmente incida il TDD perchè nessuno può immaginare che si sviluppino due software identici con modelli diversi solo per vedere l'effetto che fa. Mentre sarebbe molto più facile capire la logica che presiede all'uno o all'altro metodo.
In ogni caso, io una mezza teoria riguardo allo sviluppo di sistemi complessi, passibili di mutamenti in corso d'opera, l'avrei anche. Il problema è che è mezza, non ho mai avuto l'ardire di tentarla e ci vuole un volumetto per parlarne in modo che sia criticabile, anche ferocemente.
Diamonds. Beh, la dico per come la penso: per me funziona perchè avete scelto un modello di sviluppo, lo avete seguito e siete riusciti a mantenere un buon livello di comunicazione (ok, qualcosa di Beck in fondo mi va a genio :D). A prescindere dal modello: avreste potuto usare il waterfall e sareste arrivati lo stesso alla fine del tunnel.
I non volevo limitare il discorso a Diamonds... Era solo per spiegare il perchè il TDD funziona ;)
I non volevo limitare il discorso a Diamonds... Era solo per spiegare il perchè il TDD funziona ;)
Ero rimaso alla replica di Fek, la tua non c'era ancora (ma un bel semaforo che dice "hey, guarda che qualcuno ha già risposto" non varrebbe tanto oro quanto pesa? :D)
Posso quindi esprimere un mio giudizio sul TDD...ovviamente non è derivato da studi teorici, ma solo dall'esperienza pratica...
Quel "solo" è una miniera d'oro.
Non vorrei dare l'impressione del vecchio parruccone abbarbicato sulla sua roccia che grida ai quattro venti "la teoria è bella, la pratica fa schifo". Tutt'altro, in una gara di "praticoneria" vi straccio tutti senza appello :D.
Vi dirò che non avevo pensato ai "test" come strumento di comunicazione. Io credo che la mancanza di omogeneità in un team di sviluppo deva essere risolta sul piano della comunicazione.
Dei test avevo considerato l'aspetto "meccanico". Sappiamo che tradizionalmente la soluzione di un problema è divisa in quattro parti, pianificazione, rappresentazione, esecuzione e controllo, e il TDD sposta il quarto pezzo nel primo. Molto più in là non ero arrivato :eek:
Il test come strumento di comunicazione...è un'idea molto bella, molto "sociologica".
Io parlo della questione teorica.
Ed e' proprio per questo che sbagli in maniera fondamentale nei giudizi che stai dando, perche' parli di teoria, quando anche lo stesso Russel ti darebbe sonore bacchettate ricordandoti che la teoria deve spiegare i fenomeni osservabili.
Come, a mio avviso, hai totalmente travisato il libro di Fowler che non e' una trattazione teorica, non vuole esserlo e lo dice proprio all'inizio del libro. In se' Refactoring di Fowler non e' altro che una raccolta organica di tutta una serie di pratiche e la loro formalizzazione in passi che possano essere meccanizzati in tool. Non e' altro che questo :)
E' come se tu fossi in bicicletta e ti lamentassi perche' non ti porta da Roma a New York: prendi l'aereo. La bicicletta ti porta velocemente da casa al lavoro magari, cosa che un aereo non farebbe. E cosi' e' il libro di Fowler: vuoi la spiegazione empirica del perche' l'applicazione di "Extract Method" porta ad un defect rate piu' basso? Leggi gli studi in proposito. Vuoi i passi per implementare un "Extract Method" in un tool? Leggi il libro di Fowler. Vuoi un'introduzione sulla pratica di Refactoring e che cosa vuol dire fare Refactoring nel lavoro di tutti i giorni? Leggi Fowler. Vuoi capire in quale percentuale fare Refactoring impatta produttivita' e defect rate? Hai capito l'antifona...
Gli studi (che pure vanno letti e che io NON ho letto) logicamente non dimostrano nulla: possono e vogliono dire solo se un certo fenomeno si verifichi o meno. Lo studio è poi usato per falsificare la teoria.
Vero, infatti ho chiesto uno studio che la falsifichi e ti ho chiesto quali pratiche alternative proponi. Se ne proponi. Io sono praticone, l'ho detto, sono interessato ad andare a casa alle sei con il lavoro fatto, sono anche interessato al perche' qualcosa funziona e in quali circostanze, ma sono nell'ottica del conoscere meglio lo strumento e i suoi limiti.
Dire che qualcosa e' infondato senza spiegazioni, non e' una confutazione di nulla.
Comunque il mio patema non è questo.
Mi esprimo con più precisione a scanso di ulteriori equivoci. Molte delle proposizioni contenute nelle "motivazioni" connesse all'uso delle tecniche di refactoring, descritte nel libro in questione, sono tautologie: l'Autore tende a dimostrare le sue affermazioni presupponendo la verità delle affermazioni stesse. Immagino che questo non richieda una puntuale evidenziazione da parte mia dei casi di cui parlo, chiunque abbia un'infarinatura di logica e quel libro può rendersene conto, ma se del caso posso darla.
Ma non sono affatto tautologie, rileggi il libro con piu' attenzione. La prima volta che lo lessi, non capii nulla di quello che c'era scritto. L'ho dovuto rileggere, applicare quello che c'era scritto, capire come influenzava il mio lavoro, capirne le lezioni dietro ed il cambio di mentalita' che impone una visione dello sviluppo basata sul concetto di semplicita'. Refactoring non fa altro che promuovere la "semplicita'". E sembra che tu abbia forte bisogno di questo concetto di "semplicita'", perche' ti complichi la vita dove non e' necessario. Fai Refactoring quando serve, il tuo codice e i tuoi colleghi ti ringrazieranno, anche se non hai capito il perche' funziona. (E nel libro comunque i perche' sono accennati e non sono tautologie).
Diamonds. Beh, la dico per come la penso: per me funziona perchè avete scelto un modello di sviluppo, lo avete seguito e siete riusciti a mantenere un buon livello di comunicazione (ok, qualcosa di Beck in fondo mi va a genio :D). A prescindere dal modello: avreste potuto usare il waterfall e sareste arrivati lo stesso alla fine del tunnel.
No, non avremmo potuto usare il Waterfall perche' i requisiti del nostro problema non erano conosciuti. Come, per altro, nel 99% dei casi.
Meglio o peggio? Eh eh, questo è un domandone. Bisognerebbe tentare l'assurdo: cancellarvi la memoria e rifare tutto con un'altro modello di sviluppo. Poi confrontare il risultato.
Io l'ho gia' fatto ed ho visto i risultati del tentare di ingegnerizzare una soluzione con i requisiti che cambiano e cercando di non variare il design gia' progettato in precedenza :)
Su un progetto da alcuni milioni di righe di codice, non auguro questo approccio al mio peggior nemico. Per questo cerco di meglio.
Il test come strumento di comunicazione...è un'idea molto bella, molto "sociologica".
E non e' solo un'idea, funziona in pratica :)
Spesso guardando Diamonds mi stupisco come ragazzi che hanno imparato a programmare pochi mesi fa comunichino per mezzo di test:
"Questo bug si presenta cosi' e cosi', aspetta ti scrivo un test che te lo fa vedere."
"Visto, ora risolvo il bug... il test passa adesso."
Questo dialogo sul forum di Diamonds e' all'ordine del giorno e rende la comunicazione molto "streamlined" (non saprei dirlo in italiano).
Spesso un lungo post viene riassunto in un paio di test che documentano in maniera precisa il problema. Il test, come spesso si sbaglia a pensare, non e' uno strumento di controllo del codice, e' principalmente uno strumento di design e di comunicazione e documentazione del codice. Fare TDD non vuol dire non fare design, vuol dire il contrario: invece di mesi fra la fase di design e quella di implementazione, passano minuti cosi' l'implementazione puo' dare un feedback immediato sul design. Lo strumento del Refactoring serve a semplificare il codice al punto tale da poterlo testare e eliminarne le duplicazioni. E' uno strumento di "gestione della complessita'". Funziona perche' la riga di codice piu' facile da mantenere e senza bug e' quella che non hai scritto, o quella che hai tolto.
(Oggi ho speso tutta la giornata a togliere righe di codice al lavoro)
Oddio, è certamente possibile che io abbia frainteso lo scopo del libro. Però lo vedo citato spesso come uno dei "fondamentali". Diamine, l'ho preso proprio per questo: vuoi vedere che m'han fregato? :D.
E se le ragioni non stanno lì e non sono neanche in "Extreme Programming Explained", "Planning Extreme Programming", e "Test Driven Development", oltre che nei volumi citati nella bibliografia di "Refactoring", dove vado a prenderle?
Lo chiedo anche correndo il rischio di apparire insistente perchè ho già il sospetto della fine che farà lo sviluppo agile: lo stesso della programmazione orientata agli oggetti. A furia di dire come e mai perchè, finisce tutto in un minestrone in cui la prima dabbenaggine che si dice è vera perchè l'ha detta Tizio, che l'ha sentita da Caio, che l'ha letta da Sempronio che di programmazione orientata agli oggetti non ha mai capito un cavolo.
Oddio, è certamente possibile che io abbia frainteso lo scopo del libro. Però lo vedo citato spesso come uno dei "fondamentali". Diamine, l'ho preso proprio per questo: vuoi vedere che m'han fregato? :D.
E se le ragioni non stanno lì e non sono neanche in "Extreme Programming Explained", "Planning Extreme Programming", e "Test Driven Development", oltre che nei volumi citati nella bibliografia di "Refactoring", dove vado a prenderle?
Lo chiedo anche correndo il rischio di apparire insistente perchè ho già il sospetto della fine che farà lo sviluppo agile: lo stesso della programmazione orientata agli oggetti. A furia di dire come e mai perchè, finisce tutto in un minestrone in cui la prima dabbenaggine che si dice è vera perchè l'ha detta Tizio, che l'ha sentita da Caio, che l'ha letta da Sempronio che di programmazione orientata agli oggetti non ha mai capito un cavolo.
Ti ripeto, i perche' ci sono i tutti i libri che hai citato sono anche molto chiari :)
cdimauro
03-05-2006, 08:56
Lo chiedo anche correndo il rischio di apparire insistente perchè ho già il sospetto della fine che farà lo sviluppo agile: lo stesso della programmazione orientata agli oggetti. A furia di dire come e mai perchè, finisce tutto in un minestrone in cui la prima dabbenaggine che si dice è vera perchè l'ha detta Tizio, che l'ha sentita da Caio, che l'ha letta da Sempronio che di programmazione orientata agli oggetti non ha mai capito un cavolo.
Quoto soltanto questa parte perché penso che il nocciolo della questione stia tutto qui: vorresti una dimostrazione di qualcosa che non potrai mai avere sostanzialmente per due motivi:
- non puoi definire una metrica oggettiva e precisa che tratti la "complessità" di un'applicazione;
- non puoi "misurare" bug et similia.
Si tratta di funzioni non computabili. Quindi la teoria non potrà mai darti una mano a sbrogliare questa matassa (anzi, i risultati a cui porta la teoria della computabilità fanno letteralmente cadere le braccia a un informatico, perché restringono enormemente il "campo d'azione" del software).
E' la differenza fra teoria e pratica, insomma, che nel campo dell'informatica si fa particolarmente importante e delicata.
Tanto per fare un esempio, se prendiamo il quick sort la teoria ci dice che la scelta dell'elemento mediano come pivot (che è quella "migliore") oppure di quello che sta in mezzo all'insieme non cambia di una virgola la complessità computazionale dell'algoritmo, che rimane O(nlog2n).
Eppure il primo è più "complesso" da implementare e incide pesantemente sul fattore costante della misura di complessità, in quanto richiede tempo O(nlog2n), mentre per il secondo l'implementazione è semplicissima e richiede un tempo pari a O(log2n).
Praticamente i "vantaggi" della prima scelta vengono annullati e ribaltati dai risultati sperimentali, perché la seconda si comporta abbastanza bene, ma richiede meno scrittura del codice e soprattutto una costante computazionale decisamente minore.
Ritornando al discorso di cui sopra, è evidente che le risposte che cerchi le potrai averle soltanto da un approccio pragramatico al problema (anche perché, parliamoci chiaramente, ti rimane solo questo).
D'altra parte se, come informatici, ci siamo spostati dall'assembly ai linguaggi "di scripting", dal sorgentone unico "spaghetti coded" ai moduli & classi, dal waterfall ai modelli evolutivi & agili, ecc. è perché i risultati ci mostrano che gli ultimi rappresentano strumenti "migliori" per il nostro lavoro (e la produttività).
Personalmente fra produrre teorie fini a se stesse e codice di qualità, anche se non supportato da nessuna rigorosa base teorica ma da "best practices" empiriche, preferisco quest'ultimo.
Citando Diamonds, posso dirti che un po' di giorni fa, operando un pesante refactoring del codice, sono riuscito a venirne a capo dopo un po' di ore col progetto perfettamente funzionante: i test mi hanno permesso di evidenziare subito i problemi che sono saltati fuori e di correggerli. Sistemati i test, alla prima esecuzione il gioco è partito e funzionava senza alcun intoppo.
Senza i test non so quanti giorni avrei impiegato per riuscire a venirne a capo (considera che la maggior parte dei sorgenti sono stati investiti dalle modiche).
Complimenti: sei riuscito a strapparmi un messaggio su hwupgrade dopo diverso tempo...
Il test come strumento di comunicazione...è un'idea molto bella, molto "sociologica".
Sì ed è molto importante perchè esprimono in un linguaggio comune a tutti i programmatori (il linguaggio in cui è sviluppato il progetto) ciò che vogliamo ottenere dal progetto...
Ma non ti fermare qui...commenta anche il concettto, abbastanza teorico per me, secondo cui i test guidano il programmatore ad una determinata soluzione funzionante e funzionale...
Funzionante almeno per i punti chiave espressi dai test...funzionale perchè nei test descriviamo l'interfaccia che dobbiamo implementare per arrivare alla soluzione ed il modo in cui questa debba essere usate all'interno del codice...
Inoltre ti prego di commentare il fatto che sia più semplice (dal punto di vista logico) esprimere come vorrremmo che la classe che sviluppiamo venga usata...invece di sviluppare la classe stessa senza interazioni "reali" con l'intero progetto... IMHO anche questo permette di creare il famoso "clean code" di "write clean code that works"...
In questo vedi il limite del waterfall stesso che, sì, cerca di predeterminare l'interfaccia e le interazioni, ma come sappiamo quando arriviamo a scrivere codice, molto spesso, costringe a fare continue modifiche ai "contratti" delle varie classi perchè scomode da usare nel modo in cui sono state progettate (di conseguenza comporta di passare continuamente da design ad implementazione)...
^TiGeRShArK^
03-05-2006, 14:14
Complimenti: sei riuscito a strapparmi un messaggio su hwupgrade dopo diverso tempo...
:winner:
bentornato anche in questa sezione! :D
Sulla questione dei test, fermo restando la "piacevole scoperta" (per me) del loro effetto comunicativo, io ho capito un che di diverso.
La novità non è "se" usare dei test: la verifica è uno dei momenti in cui si articola la soluzione del problema. Classicamente è l'ultimo: rappresentiamo, pianifichiamo, eseguiamo e verifichiamo. Nel TDD la pianificazione è verifica: rappresentiamo, pianifichiamo attraverso i test, eseguiamo.
Da quanto ho capito, il TDD richiede anche la ripetizione del pacchetto di test cosa che, in un contesto in cui molti modificano il codice e molto deve essere testato, direi che invoglia ad un certo grado di automazione. Sotto questo profilo mi sembra che il TDD sia ciclico e preveda il carattere incrementale dello sviluppo che, in sè, non è affatto cosa nuova. Il nuovo è, a parer mio, la pianificazione attraverso le verifiche.
Funziona? Io credo che, per come è formulata la teoria del TDD, non si possa sapere. Potremmo se il TDD dicesse "l'applicazione di questo metodo porta a zero bug": "un bug" sarebbe il criterio di falsificabilità.
Non dice questo. "migliore", "più semplice", "più facilmente manipolabile", "manipolabile con maggiore sicurezza". Non tutti concordano sul fatto che sia possibile definire una metrica delle qualità. E se le analisi comparative della qualità di due cose soffrono di un elevato grado di inattendibilità è impossibile falsificare la teoria del TDD.
Una teoria non falsificabile è un dogma: come la fede, ci credi o non ci credi.
Quello che ho scritto vale a meno che un criterio di falsificabilità esista e io non l'abbia visto (di certo non ho letto tutto sull'argomento).
Non dice questo. "migliore", "più semplice", "più facilmente manipolabile", "manipolabile con maggiore sicurezza". Non tutti concordano sul fatto che sia possibile definire una metrica delle qualità. E se le analisi comparative della qualità di due cose soffrono di un elevato grado di inattendibilità è impossibile falsificare la teoria del TDD.
Stai ancora facendo confusione fra Teoria e Strumento. TDD non e' una Teoria, e' uno Strumento. Come un martello per il falegname. Il martello non e' una teoria, e' uno strumento che il falegname usa per piantare i chiodi; non usa una sega perche' si e' accorto che con il martello fa decisamente prima. In certe situazioni lo strumento TDD funziona bene e porta ad aumenti di produttivita' misurabili e verificabili. In altre situazioni no. Sta a te conoscere lo strumento e saperlo usare quando serve.
Il resto, perdonami, ma sono chiacchiere sul sesso degl'angeli :)
Io ritengo che esista una spiegazione anche del funzionamento e dell'idoneità degli strumenti, martello compreso. A volte postuma ma c'è sempre.
Castelli in aria. Be', per indole apprezzo la franchezza. D'altronde non è che dovendo scrivere un pezzo di un sistema io mi metta a battere i pugni sul tavolo gridando "teoria, teoria, teoria!". A dire il vero una volta l'ho fatto e, naturalmente, la faccenda si è conclusa con io che ho detto grazie e arrivederci: il mondo ha continuato a girare. Strano! :D.
Io ritengo che esista una spiegazione anche del funzionamento e dell'idoneità degli strumenti, martello compreso. A volte postuma ma c'è sempre.
Va bene, ma prova a dire al falegname di piantare i chiodi a mano e non con il martello fino a che non trovi la spiegazione teorica del suo funzionamento ;)
Va bene, ma prova a dire al falegname di piantare i chiodi a mano e non con il martello fino a che non trovi la spiegazione teorica del suo funzionamento ;)
:D :D
Dici che non collabora? :D 'sti falegnami...
:D :D
Dici che non collabora? :D 'sti falegnami...
Secondo me no :D
ma la spiegazione teorica per cui un matello è meglio di una patata per piantare un chiodo c'è già, mica che non c'è :p
^TiGeRShArK^
04-05-2006, 14:16
ma la spiegazione teorica per cui un matello è meglio di una patata per piantare un chiodo c'è già, mica che non c'è :p
dipende da quanto è secca ed ergonomica la patata :O
:asd:
Rischiando di andare fuori tema, evitando al tempo stesso di ripetere la mia opinione sul TDD (che qui si sta intendendo anche come Test Driven Design), vorrei capire perchè si vuole/deve studiare l'argomento utilizzando un modello di analisi filosofico/matematico invece di un modello di analisi sperimentale.
Certe questioni di carattere filosofico ben si sposano con la (mia) curiosità scientifica, ma cozzano forte contro gran parte delle scienze umane.
D'altra parte è anche evidente che spesso l'impostazione di alcuni autori sull'argomento è ad una attenta lettura, come ci fa notare PGI-Bis, dogmatica.
Ps: gli angeli, seppur piccolo, ce l'hanno. :O
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.