I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.
75 messaggi this document does not accept new posts
secondo me... Di Herr Franz postato il 28/09/2009 08:08
Secondo me i casi sono 3 :
o si mette a farla da capo, dicendo che era l'unico metodo ,
o fa finta di metterci mano per un mesetto e poi chiede di passare al punto uno,
o la guarda , non ci capisce niente , e passa prima al punto 2 e poi al punto uno.
A vostre spese.
Questo si chiama goto informatico detto anche "ma va' a...". -- Herr Franz
o si mette a farla da capo, dicendo che era l'unico metodo ,
o fa finta di metterci mano per un mesetto e poi chiede di passare al punto uno,
o la guarda , non ci capisce niente , e passa prima al punto 2 e poi al punto uno.
A vostre spese.
Questo si chiama goto informatico detto anche "ma va' a...". -- Herr Franz
@ Herr Franz Di Guido postato il 29/09/2009 17:01
Il fatto che se è un programmatore in J(f)ava ti risponde che il goto non è disponibile 
> Secondo me i casi sono 3 :
> o si mette a farla da capo, dicendo che era l'unico metodo ,
> o fa finta di metterci mano per un mesetto e poi chiede di passare al punto uno,
> o la guarda , non ci capisce niente , e passa prima al punto 2 e poi al punto uno.
> A vostre spese.
> Questo si chiama goto informatico detto anche "ma va' a...".
>
> -- Guido
> Secondo me i casi sono 3 :
> o si mette a farla da capo, dicendo che era l'unico metodo ,
> o fa finta di metterci mano per un mesetto e poi chiede di passare al punto uno,
> o la guarda , non ci capisce niente , e passa prima al punto 2 e poi al punto uno.
> A vostre spese.
> Questo si chiama goto informatico detto anche "ma va' a...".
>
> -- Guido
I famosi Tests!! Di Luca Bertoncello postato il 28/09/2009 08:22
Bella, l'idea!
Ce l'aveva anche il mio (ex!) capo (quello che e' scappato l'anno scorso).
Ha fatto "assumere" uno studente per scrivere i vari Tests intanto che io ancora dovevo scrivere il codice.
I Tests non hanno MAI funzionato, ma il programma va a meraviglia...
Per fortuna, poi, il tipo e' andato via, che voleva farmi riscrivere il codice per farlo funzionare con i Tests (e probabilmente poi, non funzionare AFFATTO nel mondo reale...).
Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)
Ciao -- Luca Bertoncello
Ce l'aveva anche il mio (ex!) capo (quello che e' scappato l'anno scorso).
Ha fatto "assumere" uno studente per scrivere i vari Tests intanto che io ancora dovevo scrivere il codice.
I Tests non hanno MAI funzionato, ma il programma va a meraviglia...
Per fortuna, poi, il tipo e' andato via, che voleva farmi riscrivere il codice per farlo funzionare con i Tests (e probabilmente poi, non funzionare AFFATTO nel mondo reale...).
Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)
Ciao -- Luca Bertoncello
@ Luca Bertoncello Di Davide Bianchi postato il 28/09/2009 08:30
> Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)
Come sei perspicace...
-- Davide Bianchi
Come sei perspicace...
-- Davide Bianchi
@ Davide Bianchi Di Elder postato il 30/09/2009 12:51
> > Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)
>
> Come sei perspicace...
>
questo vuol dire che ci aspettano altre storie su di lui, bello
(per noi, non per te temo 
)
--
Elder
>
> Come sei perspicace...
>
questo vuol dire che ci aspettano altre storie su di lui, bello
(per noi, non per te temo )
--
Elder
@ Luca Bertoncello Di Anonymous coward postato il 28/09/2009 09:35
> Bella, l'idea!
>
> Ce l'aveva anche il mio (ex!) capo (quello che e' scappato l'anno scorso).
> Ha fatto "assumere" uno studente per scrivere i vari Tests intanto che io ancora dovevo scrivere il codice.
> I Tests non hanno MAI funzionato, ma il programma va a meraviglia...
>
> Per fortuna, poi, il tipo e' andato via, che voleva farmi riscrivere il codice per farlo funzionare con i Tests (e probabilmente poi, non funzionare AFFATTO nel mondo reale...).
>
> Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)
>
> Ciao
I test di unità (cosė si chiamano) sarebbero anche una bell'idea in linea teorica: scrivi una piccola porzione di codice che testa una funzionalità e poi passi il tuo sorgente al framework di testing che ti dice quanta roba funziona e quanta roba c'è da sistemare. Se aggiungi una nuova feature puoi vedere dove questa va ad influire e con che conseguenze.
Il problema è che si tratta dell'ultima novità in fatto di OOP e quindi tutti i baboon coders che a malapena distinguono un'interfaccia da una classe astratta ci si sono fiondati sopra come api sul miele. -- Anonymous coward
>
> Ce l'aveva anche il mio (ex!) capo (quello che e' scappato l'anno scorso).
> Ha fatto "assumere" uno studente per scrivere i vari Tests intanto che io ancora dovevo scrivere il codice.
> I Tests non hanno MAI funzionato, ma il programma va a meraviglia...
>
> Per fortuna, poi, il tipo e' andato via, che voleva farmi riscrivere il codice per farlo funzionare con i Tests (e probabilmente poi, non funzionare AFFATTO nel mondo reale...).
>
> Spero che 'sto tipo l'abbiate sfanculizzato alla svelta (ma qualcosa mi dice di no...)
>
> Ciao
I test di unità (cosė si chiamano) sarebbero anche una bell'idea in linea teorica: scrivi una piccola porzione di codice che testa una funzionalità e poi passi il tuo sorgente al framework di testing che ti dice quanta roba funziona e quanta roba c'è da sistemare. Se aggiungi una nuova feature puoi vedere dove questa va ad influire e con che conseguenze.
Il problema è che si tratta dell'ultima novità in fatto di OOP e quindi tutti i baboon coders che a malapena distinguono un'interfaccia da una classe astratta ci si sono fiondati sopra come api sul miele. -- Anonymous coward
OO : siamo uomini o utenti? Di Franz postato il 28/09/2009 08:53
Io, lo ammetto, non sono mai stato un grande fan della OOP.
La uso, ne vedo i benefici, non intendo dire che sia da gettare completamente... pero'...
Per me la OOP ha contribuito a trasformare i programmatori in Utenti, di codice che altri hanno creato (spesso male), senza capire esattamente cosa succeda "dietro le quinte".
Un mio amico, ex coder, chiamava windows -l'allora 3.11- "Pupazzetti&Bamboline" ed i programmatori visual-basic li chiamavamo poi "utenti".
Il risultato di tutto questo è che il computer con il quale è stata gestita la missione Apollo nel 1969, non riuscirebbe a far girare notepad, oggigiorno.
E' quello che fa si che Excel conntentga buona parte del codice del Flight Simulator.
Dietro a questi "grandi successi" c'e' sempre un genio che si mette in testa di creare un'altro livello di astrazione sopra a quelli gia' esistenti. -- Franz
La uso, ne vedo i benefici, non intendo dire che sia da gettare completamente... pero'...
Per me la OOP ha contribuito a trasformare i programmatori in Utenti, di codice che altri hanno creato (spesso male), senza capire esattamente cosa succeda "dietro le quinte".
Un mio amico, ex coder, chiamava windows -l'allora 3.11- "Pupazzetti&Bamboline" ed i programmatori visual-basic li chiamavamo poi "utenti".
Il risultato di tutto questo è che il computer con il quale è stata gestita la missione Apollo nel 1969, non riuscirebbe a far girare notepad, oggigiorno.
E' quello che fa si che Excel conntentga buona parte del codice del Flight Simulator.
Dietro a questi "grandi successi" c'e' sempre un genio che si mette in testa di creare un'altro livello di astrazione sopra a quelli gia' esistenti. -- Franz
@ Franz Di Kent Morwath postato il 28/09/2009 22:35
> Io, lo ammetto, non sono mai stato un grande fan della OOP.
Chiunque si trovi a creare applicazioni GUI Windows, o si cimenti con le OCI di Oracle apprezza rapidamente una libreria OO ben fatta. E anche MacOSX è in gran parte basato sugli oggetti ereditati da NextStep
> Per me la OOP ha contribuito a trasformare i programmatori in Utenti, di
Solo quelli che non mettono a disposizione i sorgenti delle librerie, e quelli che quando li hanno non ci buttano un occhio.
> visual-basic li chiamavamo poi "utenti".
VB fino a .NET non è mai stato veramente OO per il semplice fatto che mancava l'ereditarietà (e pertanto anche il polimorfismo, se non via COM).
> la missione Apollo nel 1969, non riuscirebbe a far girare notepad,
Mah, il software a bordo dell'Apollo ha avuto i guai suoi.., per chi vuole la storia completa: http://en.wikipedia.org/wiki/Apollo_Guidance_Computer
> Dietro a questi "grandi successi" c'e' sempre un genio
A volte è necessario, perché altrimenti la complessità di un sistema va ben oltre le possibilità di gestione. Poi ci sono i talebani come alcune librerie Java che per gestire la pressione di un pulsante bisogna implemetare quattro design pattern e otto classi Perché cosė è più "elegante".
--
Kent Morwath
Chiunque si trovi a creare applicazioni GUI Windows, o si cimenti con le OCI di Oracle apprezza rapidamente una libreria OO ben fatta. E anche MacOSX è in gran parte basato sugli oggetti ereditati da NextStep
> Per me la OOP ha contribuito a trasformare i programmatori in Utenti, di
Solo quelli che non mettono a disposizione i sorgenti delle librerie, e quelli che quando li hanno non ci buttano un occhio.
> visual-basic li chiamavamo poi "utenti".
VB fino a .NET non è mai stato veramente OO per il semplice fatto che mancava l'ereditarietà (e pertanto anche il polimorfismo, se non via COM).
> la missione Apollo nel 1969, non riuscirebbe a far girare notepad,
Mah, il software a bordo dell'Apollo ha avuto i guai suoi.., per chi vuole la storia completa: http://en.wikipedia.org/wiki/Apollo_Guidance_Computer
> Dietro a questi "grandi successi" c'e' sempre un genio
A volte è necessario, perché altrimenti la complessità di un sistema va ben oltre le possibilità di gestione. Poi ci sono i talebani come alcune librerie Java che per gestire la pressione di un pulsante bisogna implemetare quattro design pattern e otto classi
Perché cosė è più "elegante".
--
Kent Morwath
riassumendo: Di Nik postato il 28/09/2009 09:47
> DB - Ma tu che ne pensi?
> IO - Che e' un coglione.
quando una parola dice tutto...... -- ...
> IO - Che e' un coglione.
quando una parola dice tutto...... -- ...
Ma tu guarda che combinazione Di Stefano L. postato il 28/09/2009 10:48
Questa mattina arrivo in ufficio e sulla mia scrivania trovo una rivista. (Chissa' chi l'ha messa)
La sfoglio e noto che parla di... AG !
Scorro qualche articolo, AgileProgrammint, TestingAutomatico, MassimizzareLaComunicazione, PairProgramming, Refactoring....ecc.
Chissa' come mai mi viene in mente il famoso commento di Fantozzi alla corrazzata Potemkin
-- Stefano L.
La sfoglio e noto che parla di... AG !
Scorro qualche articolo, AgileProgrammint, TestingAutomatico, MassimizzareLaComunicazione, PairProgramming, Refactoring....ecc.
Chissa' come mai mi viene in mente il famoso commento di Fantozzi alla corrazzata Potemkin
-- Stefano L.
TDD Di Johnny postato il 28/09/2009 10:55
Quando lavoravo come programmatore a $noiVendiamoSuonerie usavamo Test Driven Development: prima si scrivevano i test e poi si scriveva il test per non farli fallire.
Sembra una stupidata, ma non lo è: ti garantisco che se parti da zero, alla fine ti ritrovi con il codice molto pulito e diventa semplice anche fare una modifica.
Ovviamente questa metodologia ha i suoi svantaggi, ma in certi contesti (non nel tuo caso!) funziona bene -- Johnny
Sembra una stupidata, ma non lo è: ti garantisco che se parti da zero, alla fine ti ritrovi con il codice molto pulito e diventa semplice anche fare una modifica.
Ovviamente questa metodologia ha i suoi svantaggi, ma in certi contesti (non nel tuo caso!) funziona bene -- Johnny
aggettivo per ST Di mau postato il 28/09/2009 11:09
> DB - Ma tu che ne pensi?
> IO - Che e' un coglione.
ce la scrivi in olandese?
--
Mau
> IO - Che e' un coglione.
ce la scrivi in olandese?
--
Mau
@ mau Di Davide Bianchi postato il 28/09/2009 11:15
> ce la scrivi in olandese?
Wat denk je?
Wat Hij een idioot is.
Tevreden? -- Davide Bianchi
Wat denk je?
Wat Hij een idioot is.
Tevreden? -- Davide Bianchi
@ Davide Bianchi Di Anonymous coward postato il 28/09/2009 11:25
> > ce la scrivi in olandese?
>
> Wat denk je?
> Wat Hij een idioot is.
>
> Tevreden?
Hai barato, non è la traduzione "letterale" -- Anonymous coward
>
> Wat denk je?
> Wat Hij een idioot is.
>
> Tevreden?
Hai barato, non è la traduzione "letterale" -- Anonymous coward
@ Anonymous coward Di Davide Bianchi postato il 28/09/2009 11:28
> Hai barato, non è la traduzione "letterale"
No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.
-- Davide Bianchi
No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.
-- Davide Bianchi
@ Davide Bianchi Di Anonymous coward postato il 28/09/2009 11:32
> > Hai barato, non è la traduzione "letterale"
>
> No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.
>
>
>
nel senso che non esiste una traduzione di co$$$one in olandese? -- Anonymous coward
>
> No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.
>
>
>
nel senso che non esiste una traduzione di co$$$one in olandese? -- Anonymous coward
@ Anonymous coward Di Davide Bianchi postato il 28/09/2009 11:39
> nel senso che non esiste una traduzione di co$$$one in olandese?
Non letterale. -- Davide Bianchi
Non letterale. -- Davide Bianchi
@ Davide Bianchi Di Antonio postato il 02/10/2009 13:46
> > Hai barato, non è la traduzione "letterale"
>
> No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.
Infatti le traduzioni sono come le donne:
Se sono belle non sono fedeli, se sono fedeli non sono belle
:)
>
>
> -- Antonio
>
> No che non e' una traduzione letterale. Le traduzioni letterali sono impossibili in molti casi.
Infatti le traduzioni sono come le donne:
Se sono belle non sono fedeli, se sono fedeli non sono belle
:)
>
>
> -- Antonio
Concordo, a meta' Di Alex postato il 28/09/2009 11:30
Mi aggrego al disprezzo per l'Agile e in particolare per il Test-Driven Programming che considero una minkiata, nonostante sia da una decina d'anni che evengelisti vari cercano di convincermi che "e' cosė che si fa software nel ventunesimo secolo".
Sono un po' meno d'accordo circa la critica verso la programmazione ad oggetti, visto che non solo programmo ad oggetti, bensi' lavoro addirittura con gli ODBMS quando in fase di analisi e' palese che il modello di dati ha ordini di gerarchia ed ereditarieta' tali, che gestirli con il relazionale e' da ingenui.
-- Alex
Sono un po' meno d'accordo circa la critica verso la programmazione ad oggetti, visto che non solo programmo ad oggetti, bensi' lavoro addirittura con gli ODBMS quando in fase di analisi e' palese che il modello di dati ha ordini di gerarchia ed ereditarieta' tali, che gestirli con il relazionale e' da ingenui.
-- Alex
@ Alex Di Angkarn postato il 28/09/2009 13:07
> Sono un po' meno d'accordo circa la critica verso la programmazione ad oggetti, visto che non solo programmo ad oggetti, bensi' lavoro addirittura con gli ODBMS quando in fase di analisi e' palese che il modello di dati ha ordini di gerarchia ed ereditarieta' tali, che gestirli con il relazionale e' da ingenui.
>
Concordo, trovo che la OOP, se si sa usare è l'approggio giusto per la programmazione di qualcosa di complesso. Ma serve misura, come in tutte le cose. Sennò poi ci si trova con diecimila classi e tremila interfacce per fare più o meno la medesima cosa (elementare).
-- Angkarn
>
Concordo, trovo che la OOP, se si sa usare è l'approggio giusto per la programmazione di qualcosa di complesso. Ma serve misura, come in tutte le cose. Sennò poi ci si trova con diecimila classi e tremila interfacce per fare più o meno la medesima cosa (elementare).
-- Angkarn
La vera coglionaggine... Di Yakky postato il 28/09/2009 11:54
... sta nel voler applicare rigidamente l'unica buzzord che si conosce a qualunque problema.
In determinati contesti e con determinati gruppi di lavoro l'Agile Programming funziona, in molti ambiti la OOP è un'ottima soluzione, ma quando ti viene chiesto di correggere 4/8/10 bug in un'applicazione non puoi dire: "Si però gli Unittest di qui, e il CoreCoding di là": correggi quei foxxuti bug e stai zitto. -- Yakky
In determinati contesti e con determinati gruppi di lavoro l'Agile Programming funziona, in molti ambiti la OOP è un'ottima soluzione, ma quando ti viene chiesto di correggere 4/8/10 bug in un'applicazione non puoi dire: "Si però gli Unittest di qui, e il CoreCoding di là": correggi quei foxxuti bug e stai zitto. -- Yakky
TDD Di Giorgio Sironi postato il 28/09/2009 12:40
Kudos per Yakky. Mi sconcerta vedere quante persone insultino il pair programming, lo unit testing, il refactoring.
I test si scrivono prima del codice perché a) cosė si è sicuri che falliscano nel caso il codice regredisca e b) perché cosė si è sicuri che il codice in produzione sia testabile. E codice testabile significa codice che presente low coupling, quindi riutilizzabile e che facilita la manutenzione. Certe cose sembrino buzzword perché in Italia siamo talmente indietro che non ne esiste ancora una traduzione molto diffusa (test delle unità e basso accoppiamento non mi suonano molto bene). Testing automatico non è difficile da comprendere, significa avere uno strumento per far testare a una macchina mille funzionalità invece che aprire un'applicazione e farlo a mano.
Quando usate google per cercare qualcosa, ricordatevi che loro usano TDD: http://googletesting.blogspot.com/ -- Giorgio Sironi
I test si scrivono prima del codice perché a) cosė si è sicuri che falliscano nel caso il codice regredisca e b) perché cosė si è sicuri che il codice in produzione sia testabile. E codice testabile significa codice che presente low coupling, quindi riutilizzabile e che facilita la manutenzione. Certe cose sembrino buzzword perché in Italia siamo talmente indietro che non ne esiste ancora una traduzione molto diffusa (test delle unità e basso accoppiamento non mi suonano molto bene). Testing automatico non è difficile da comprendere, significa avere uno strumento per far testare a una macchina mille funzionalità invece che aprire un'applicazione e farlo a mano.
Quando usate google per cercare qualcosa, ricordatevi che loro usano TDD: http://googletesting.blogspot.com/ -- Giorgio Sironi
@ Giorgio Sironi Di Alex postato il 28/09/2009 15:30
> Quando usate google per cercare qualcosa, ricordatevi che loro usano TDD:
Anche Vista e' stato sviluppato con il Test-Driven Programming.
-- Alex
Anche Vista e' stato sviluppato con il Test-Driven Programming.
-- Alex
@ Alex Di Andrea postato il 28/09/2009 15:54
> Anche Vista e' stato sviluppato con il Test-Driven Programming.
E con ottimi risultati direi!
-- Andrea
E con ottimi risultati direi!
-- Andrea
@ Alex Di Davide Inglima postato il 28/09/2009 16:24
>> Quando usate google per cercare qualcosa, ricordatevi che loro usano TDD:
> Anche Vista e' stato sviluppato con il Test-Driven Programming.
Ok, hai qualche link a suffragio di questo?
Grazie. -- http://limacat.blogspot.com
> Anche Vista e' stato sviluppato con il Test-Driven Programming.
Ok, hai qualche link a suffragio di questo?
Grazie. -- http://limacat.blogspot.com
@ Test scettici Di FDG postato il 28/09/2009 16:13
Con un martello puoi ottenere risultati diversi: ci puoi piantare un chiodo o te lo puoi dare in testa. Vuoi dire che dobbiamo buttare il martello? No, affatto! Una bella martellata in testa a volte è risolutiva!
Scherzi a parte, il problema non è lo strumento ma chi lo usa. C'è gente che si nutre di parole ma non capisce un tubo. -- FDG
Scherzi a parte, il problema non è lo strumento ma chi lo usa. C'è gente che si nutre di parole ma non capisce un tubo. -- FDG
@ FDG Di Riccardo Cagnasso postato il 28/09/2009 22:40
> Con un martello puoi ottenere risultati diversi: ci puoi piantare un chiodo o te lo puoi dare in testa. Vuoi dire che dobbiamo buttare il martello? No, affatto! Una bella martellata in testa a volte è risolutiva!
>
> Scherzi a parte, il problema non è lo strumento ma chi lo usa. C'è gente che si nutre di parole ma non capisce un tubo.
>
Come non concordare?
Il problema e' che le varie "tecniche avanzate di sviluppo del software" hanno un senso se chi le applica e' gia' bravo con le "tecniche base" non si se mi spiego... -- Riccardo Cagnasso
>
> Scherzi a parte, il problema non è lo strumento ma chi lo usa. C'è gente che si nutre di parole ma non capisce un tubo.
>
Come non concordare?
Il problema e' che le varie "tecniche avanzate di sviluppo del software" hanno un senso se chi le applica e' gia' bravo con le "tecniche base" non si se mi spiego... -- Riccardo Cagnasso
@ FDG Di Luca BG postato il 29/09/2009 10:30
> Scherzi a parte, il problema non è lo strumento ma chi lo usa.
Quello è secondo me uno dei problemi. L'altro è l'utilizzo degli strumenti giusti per il problema da affrontare. Se devi fare un pezzo meccanico complicato, usi un tornio a controllo numerico, ma magari per togliere due sbavature al pezzo finito fai prima e meglio con una lima... Qui, idem: quello che può andare bene per un progetto ad ampio respiro e di notevole complicazione, può essere un pochettinino "overkill" per eliminare 4 bug (per valori molto grandi di 4...) -- Luca BG
Quello è secondo me uno dei problemi. L'altro è l'utilizzo degli strumenti giusti per il problema da affrontare. Se devi fare un pezzo meccanico complicato, usi un tornio a controllo numerico, ma magari per togliere due sbavature al pezzo finito fai prima e meglio con una lima... Qui, idem: quello che può andare bene per un progetto ad ampio respiro e di notevole complicazione, può essere un pochettinino "overkill" per eliminare 4 bug (per valori molto grandi di 4...) -- Luca BG
Gli idioot si aggrappano a tutto. Di Davide Inglima postato il 28/09/2009 16:29
Come da oggetto, non importa quale la combinazione di pantone e profumo, quando hanno voglia di colorare la loro cazzata per coprire la loro incapacità gli idioot si aggrappano a tutto, anche a cose che potrebbero funzionare (in mano altrui).
Detto questo, per esperienza personale TDD ho trovato che funziona, e fra rendermi odioso e inviso a tutto lo staff per rendere TDD obbligatorio e fare le 4 del mattino per trovare il bug inserito dallo stagista/conslutante/professionista/creatore del megaframework che se ne é andato per lidi migliori preferirei rendermi odioso a tutti ed usare TDD.
--
http://limacat.blogspot.com
Detto questo, per esperienza personale TDD ho trovato che funziona, e fra rendermi odioso e inviso a tutto lo staff per rendere TDD obbligatorio e fare le 4 del mattino per trovare il bug inserito dallo stagista/conslutante/professionista/creatore del megaframework che se ne é andato per lidi migliori preferirei rendermi odioso a tutti ed usare TDD.
--
http://limacat.blogspot.com
Agile Programming, sintomatologia Di Earwig postato il 28/09/2009 17:43
direi che FDG ha centrato il problema...
L'Agile Programming (o almeno alcuni dei suoi dettami) POTREBBE essere una bella cosa(non per me, ma se si ha la predilezione verso il masochismo...): il problema e' che, soprattutto in italia, non funzionera' nel 99% dei casi.
Questo per un motivo semplicissimo: il primo presupposto dell' AP consiste nel fatto che il cliente (o chi ne fa le veci, tipicamente un project manager) si trovi "sul campo" a lavorare fianco a fianco con il programmatore.
Peccato che in un paese dove il 99% di questi individui si autoconvincono che per fare il proprio lavoro basti saper scimmiottare lo slang di $famosadittadiconsulenzaglobalemassiccia&incazzata...questo non avverra' mai o quasi.
-- Earwig
L'Agile Programming (o almeno alcuni dei suoi dettami) POTREBBE essere una bella cosa(non per me, ma se si ha la predilezione verso il masochismo...): il problema e' che, soprattutto in italia, non funzionera' nel 99% dei casi.
Questo per un motivo semplicissimo: il primo presupposto dell' AP consiste nel fatto che il cliente (o chi ne fa le veci, tipicamente un project manager) si trovi "sul campo" a lavorare fianco a fianco con il programmatore.
Peccato che in un paese dove il 99% di questi individui si autoconvincono che per fare il proprio lavoro basti saper scimmiottare lo slang di $famosadittadiconsulenzaglobalemassiccia&incazzata...questo non avverra' mai o quasi.
-- Earwig
Sono un programmatore... Di Verzasoft postato il 29/09/2009 01:16
...è normale che non ho capito una singola parola di tutta questa pagina?? Ero convinto che il codice si scrivesse in una maniera sola...
--
Verzasoft
@ Verzasoft Di Davide Bianchi postato il 29/09/2009 08:41
> Ero convinto che il codice si scrivesse in una maniera sola...
Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.
-- Davide Bianchi
Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.
-- Davide Bianchi
@ Davide Bianchi Di Sandra postato il 29/09/2009 10:52
> > Ero convinto che il codice si scrivesse in una maniera sola...
>
> Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.
Uhhh! I paroloni! Che bella cosa!!!
Avvenne in Italia. Richiedo a un grafico "Tesoro, potresti disegnarmi un'iconcina per la tale funzione?" "Nessun problema, dammi una deadline". Sono rimasta basita, ho preso in mano (si fa per dire) wikipedia e ho fatto una ricerca. "Dė, ma sei scemo?!? In Italia ESISTE l'espressione data_di_scadenza, sai? Puoi usarla, non c'è una legge specifica che lo vieti!".
A parte ciò sono programmatore di vecchia data, ho iniziato sul buon vecchio Clipper (ho ancora i dischi!!!) e il caro Oracle e col tempo sono rimasta affezionata al tipo di programmazione. E di sicuro sono rimasta affezionata al sistema: analisi - sviluppo - test!
Ma magari sono io strana! -- Sandra
>
> Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.
Uhhh! I paroloni! Che bella cosa!!!
Avvenne in Italia. Richiedo a un grafico "Tesoro, potresti disegnarmi un'iconcina per la tale funzione?" "Nessun problema, dammi una deadline". Sono rimasta basita, ho preso in mano (si fa per dire) wikipedia e ho fatto una ricerca. "Dė, ma sei scemo?!? In Italia ESISTE l'espressione data_di_scadenza, sai? Puoi usarla, non c'è una legge specifica che lo vieti!".
A parte ciò sono programmatore di vecchia data, ho iniziato sul buon vecchio Clipper (ho ancora i dischi!!!) e il caro Oracle e col tempo sono rimasta affezionata al tipo di programmazione. E di sicuro sono rimasta affezionata al sistema: analisi - sviluppo - test!
Ma magari sono io strana! -- Sandra
@ Sandra Di Davide Bianchi postato il 29/09/2009 12:40
> "Nessun problema, dammi una deadline".
Che e' successo a "per quando la vuoi"?
> A parte ciò sono programmatore di vecchia data, ho iniziato sul buon vecchio Clipper
CLIPPER! Quanti ricordi! Versione '87 o 5.x?
> Ma magari sono io strana!
Sei in buona compagnia.
-- Davide Bianchi
Che e' successo a "per quando la vuoi"?
> A parte ciò sono programmatore di vecchia data, ho iniziato sul buon vecchio Clipper
CLIPPER! Quanti ricordi! Versione '87 o 5.x?
> Ma magari sono io strana!
Sei in buona compagnia.
-- Davide Bianchi
@ Davide Bianchi Di Alex postato il 29/09/2009 13:34
>>E di sicuro sono rimasta affezionata al sistema: analisi - sviluppo - test!
No, ora la moda e': test - sviluppo - analisi - refactoring
E' come dire:
1. costruiamo le poltrone di forma a piacere
2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
3. chiediamo ai clienti se si sentono comodi
4. in caso di risposta negativa, ripetere il ciclo
>>Ma magari sono io strana!
> Sei in buona compagnia.
Aggiungetemi pure alla lista.
Per quanto riguarda la storia che Vista e' stato sviluppato con il TDD, chiedo venia: ricordavo male l'ho letto 4 anni fa. E' stato sviluppato con gli Automated Tests, il che non vuol (necessariamente) dire che i test li abbiano scritti prima del codice.
Va detto tuttavia che se un test scritto con il senno di poi non garantisce la funzionalita' di un componente, per me non la garantisce neanche uno scritto alla cieca.
-- Alex
No, ora la moda e': test - sviluppo - analisi - refactoring
E' come dire:
1. costruiamo le poltrone di forma a piacere
2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
3. chiediamo ai clienti se si sentono comodi
4. in caso di risposta negativa, ripetere il ciclo
>>Ma magari sono io strana!
> Sei in buona compagnia.
Aggiungetemi pure alla lista.
Per quanto riguarda la storia che Vista e' stato sviluppato con il TDD, chiedo venia: ricordavo male l'ho letto 4 anni fa. E' stato sviluppato con gli Automated Tests, il che non vuol (necessariamente) dire che i test li abbiano scritti prima del codice.
Va detto tuttavia che se un test scritto con il senno di poi non garantisce la funzionalita' di un componente, per me non la garantisce neanche uno scritto alla cieca.
-- Alex
@ Alex Di Adriano postato il 29/09/2009 14:27
> No, ora la moda e': test - sviluppo - analisi - refactoring
>
> E' come dire:
>
> 1. costruiamo le poltrone di forma a piacere
> 2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
> 3. chiediamo ai clienti se si sentono comodi
> 4. in caso di risposta negativa, ripetere il ciclo
Sarò io, ma comunque quei test iniziali mi sembrava fossero fatti seguendo un'analisi iniziale, per piccolo che sia. Se la tua ditta immagina un progetto TDD cosė, probabilmente è una di quelle a cui si fa riferimento nell'articolo sui soldi pubblicato qui.
Ci sono diversi problemi col TDD, come ad esempio il fatto che i test coprono il programmabile, e che c'è molta funzionalità e usabilità che non è esaminabile con unit tests. Quello citato non è uno. Č un problema dell'essere idioti, non di usare TDD. -- Saludos
Adriano
>
> E' come dire:
>
> 1. costruiamo le poltrone di forma a piacere
> 2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
> 3. chiediamo ai clienti se si sentono comodi
> 4. in caso di risposta negativa, ripetere il ciclo
Sarò io, ma comunque quei test iniziali mi sembrava fossero fatti seguendo un'analisi iniziale, per piccolo che sia. Se la tua ditta immagina un progetto TDD cosė, probabilmente è una di quelle a cui si fa riferimento nell'articolo sui soldi pubblicato qui.
Ci sono diversi problemi col TDD, come ad esempio il fatto che i test coprono il programmabile, e che c'è molta funzionalità e usabilità che non è esaminabile con unit tests. Quello citato non è uno. Č un problema dell'essere idioti, non di usare TDD. -- Saludos
Adriano
@ Adriano Di Alex postato il 30/09/2009 10:22
> Se la tua ditta immagina un progetto TDD cosė, probabilmente è una di quelle a cui si fa riferimento nell'articolo sui soldi pubblicato qui.
Diciamo che cerco proprio di non immaginarmela, ho sempre gestito i miei team con RUP e, come dice il buon Davide, con la testa.
Oggigiorno la vera minaccia alla riuscita di un progetto e' la mancanza di professionalita' delle persone coinvolte (project managers, analisti, progettisti, sviluppatori, testers). Recentemente si e' diffuso il concetto TOTALMENTE SBAGLIATO che non importa se chi lavora sia skillato o meno. E Agile e' un invito ad andare in questa direzione, per questo non mi piace: io voglio lavorare con gente competente, non con sedicenti architects con 2 anni di esperienza in sviluppo e un attestato di partecipazione ad un seminario di Scrum. In compenso piace ai manager perche' li si illude di poter risparmiare sulle risorse.
-- Alex
Diciamo che cerco proprio di non immaginarmela, ho sempre gestito i miei team con RUP e, come dice il buon Davide, con la testa.
Oggigiorno la vera minaccia alla riuscita di un progetto e' la mancanza di professionalita' delle persone coinvolte (project managers, analisti, progettisti, sviluppatori, testers). Recentemente si e' diffuso il concetto TOTALMENTE SBAGLIATO che non importa se chi lavora sia skillato o meno. E Agile e' un invito ad andare in questa direzione, per questo non mi piace: io voglio lavorare con gente competente, non con sedicenti architects con 2 anni di esperienza in sviluppo e un attestato di partecipazione ad un seminario di Scrum. In compenso piace ai manager perche' li si illude di poter risparmiare sulle risorse.
-- Alex
@ Alex Di Anonymous cobra postato il 30/09/2009 12:12
> >>E di sicuro sono rimasta affezionata al sistema: analisi - sviluppo - test!
si chiama waterfall (mai sentito il corrispondente "a cascata"). in progetti rognosi quando hai finito analisi e sviluppo, le specifiche sono cambiate: l'applicazione va benissimo ma non serve piu'. inoltre non riesci a reagire ai cambiamenti in modo veloce: tutto diventa una comunicazione tra fornitore e cliente.
> No, ora la moda e': test - sviluppo - analisi - refactoring
che confusione! mescoli TDP e generico agile...
> E' come dire:
>
> 1. costruiamo le poltrone di forma a piacere
> 2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
> 3. chiediamo ai clienti se si sentono comodi
> 4. in caso di risposta negativa, ripetere il ciclo
no. in teoria (ma non essendo nemmeno io un fan del TDP potrei sbagliarmi)
1. crea un modello di cuscino, schienale etc..
2. prepara un test per vedere se sono comodi
3. applica 2 ad 1 fino a che va bene
4. fai provare al cliente.
>
> >>Ma magari sono io strana!
vorrei vedere come vai al supermarket o compri i vestiti: progetti tutto prima di entrare in negozio e compri come da lista della spesa o provi quello che ti sembra bene e ti guardi allo specchio? comprare spaghetti o un abito e' un progetto diverso e non usi lo stesso processo
> > Sei in buona compagnia.
>
> Aggiungetemi pure alla lista.
> Per quanto riguarda la storia che Vista e' stato sviluppato con il TDD, chiedo venia: ricordavo male l'ho letto 4 anni fa. E' stato sviluppato con gli Automated Tests, il che non vuol (necessariamente) dire che i test li abbiano scritti prima del codice.
> Va detto tuttavia che se un test scritto con il senno di poi non garantisce la funzionalita' di un componente, per me non la garantisce neanche uno scritto alla cieca.
Fammi capire: tu sviluppi una funzione senza sapere quello che deve fare? -- Anonymous cobra
si chiama waterfall (mai sentito il corrispondente "a cascata"). in progetti rognosi quando hai finito analisi e sviluppo, le specifiche sono cambiate: l'applicazione va benissimo ma non serve piu'. inoltre non riesci a reagire ai cambiamenti in modo veloce: tutto diventa una comunicazione tra fornitore e cliente.
> No, ora la moda e': test - sviluppo - analisi - refactoring
che confusione! mescoli TDP e generico agile...
> E' come dire:
>
> 1. costruiamo le poltrone di forma a piacere
> 2. obblighiamo tutti a nascere con le chiappe adattate alla poltrona appena costruita
> 3. chiediamo ai clienti se si sentono comodi
> 4. in caso di risposta negativa, ripetere il ciclo
no. in teoria (ma non essendo nemmeno io un fan del TDP potrei sbagliarmi)
1. crea un modello di cuscino, schienale etc..
2. prepara un test per vedere se sono comodi
3. applica 2 ad 1 fino a che va bene
4. fai provare al cliente.
>
> >>Ma magari sono io strana!
vorrei vedere come vai al supermarket o compri i vestiti: progetti tutto prima di entrare in negozio e compri come da lista della spesa o provi quello che ti sembra bene e ti guardi allo specchio? comprare spaghetti o un abito e' un progetto diverso e non usi lo stesso processo
> > Sei in buona compagnia.
>
> Aggiungetemi pure alla lista.
> Per quanto riguarda la storia che Vista e' stato sviluppato con il TDD, chiedo venia: ricordavo male l'ho letto 4 anni fa. E' stato sviluppato con gli Automated Tests, il che non vuol (necessariamente) dire che i test li abbiano scritti prima del codice.
> Va detto tuttavia che se un test scritto con il senno di poi non garantisce la funzionalita' di un componente, per me non la garantisce neanche uno scritto alla cieca.
Fammi capire: tu sviluppi una funzione senza sapere quello che deve fare? -- Anonymous cobra
@ Anonymous cobra Di Davide Bianchi postato il 30/09/2009 12:17
> no. in teoria (ma non essendo nemmeno io un fan del TDP potrei sbagliarmi)
> 1. crea un modello di cuscino, schienale etc..
> 2. prepara un test per vedere se sono comodi
> 3. applica 2 ad 1 fino a che va bene
> 4. fai provare al cliente.
Ottimo. E che e' successo al buon-vecchio "misura il culo del cliente e fai il cuscino giusto la prima volta"?
Che in termini informatici significa "interroga il cliente, scrivi le specifiche e fai il programma in funzione di quelle". -- Davide Bianchi
> 1. crea un modello di cuscino, schienale etc..
> 2. prepara un test per vedere se sono comodi
> 3. applica 2 ad 1 fino a che va bene
> 4. fai provare al cliente.
Ottimo. E che e' successo al buon-vecchio "misura il culo del cliente e fai il cuscino giusto la prima volta"?
Che in termini informatici significa "interroga il cliente, scrivi le specifiche e fai il programma in funzione di quelle". -- Davide Bianchi
@ Davide Bianchi Di Alex postato il 30/09/2009 12:42
> Che in termini informatici significa "interroga il cliente, scrivi le specifiche e fai il programma in funzione di quelle".
D'accordissimo con te, ma questo succede se: o il cliente ha le idee chiare, o l'analista funzionale che interroga il cliente ha le idee chiare.
Se entrambi sono ex programmatori che hanno ricevuto la promozione perche' erano delle scamorze e piuttosto che fargli scrivere codice e' meglio fargli fare i project manager... allora la vedo dura che il buon vecchio metodo funzioni: non funzionera' ne' Agile, ne' RUP. E qui mi riaggancio al discorso che gli attori del panorama informatico d'oggigiorno non sono piu' Al Pacino e Robert de Niro, ma Scamarcio e Muccino.
-- Alex
D'accordissimo con te, ma questo succede se: o il cliente ha le idee chiare, o l'analista funzionale che interroga il cliente ha le idee chiare.
Se entrambi sono ex programmatori che hanno ricevuto la promozione perche' erano delle scamorze e piuttosto che fargli scrivere codice e' meglio fargli fare i project manager... allora la vedo dura che il buon vecchio metodo funzioni: non funzionera' ne' Agile, ne' RUP. E qui mi riaggancio al discorso che gli attori del panorama informatico d'oggigiorno non sono piu' Al Pacino e Robert de Niro, ma Scamarcio e Muccino.
-- Alex
@ Alex Di Anonymous coward postato il 30/09/2009 14:39
> Se entrambi sono ex programmatori che hanno ricevuto la promozione perche' erano delle scamorze e piuttosto che fargli scrivere codice e' meglio fargli fare i project manager... allora la vedo dura che il buon vecchio metodo funzioni: non funzionera' ne' Agile, ne' RUP.
Ok, a questo punto sono curioso del perchè l'Agile Programming incoraggi i code monkeys. Semmai, direi che affiancare (nel pair-programming) un'esperto a un novellino sarebbe benefico per la qualità del codice e per il novellino. Pure l'imparare a scrivere test non sembra troppo controproducente. Spiegheresti cosa intendevi? -- Anonymous coward
Ok, a questo punto sono curioso del perchè l'Agile Programming incoraggi i code monkeys. Semmai, direi che affiancare (nel pair-programming) un'esperto a un novellino sarebbe benefico per la qualità del codice e per il novellino. Pure l'imparare a scrivere test non sembra troppo controproducente. Spiegheresti cosa intendevi? -- Anonymous coward
@ Anonymous coward Di Alex postato il 30/09/2009 16:38
> Ok, a questo punto sono curioso del perchè l'Agile Programming incoraggi i code monkeys
Sei a favore dell'Agile e a quanto pare dell'XP. Di conseguenza hai una visione code-centrica di tutto il processo. Nel processo di produzione di soluzioni software enterprise non esiste solo il codice del programma e il codice dei test. Esistono lo studio di fattibilita, l'analisi funzionale, l'analisi tecnica, la progettazione e solo alla fine lo sviluppo, i test funzionali, i test di carico e i test di accettazione (UAT).
Agile promette di poter fare come i gamberi, partire dal risultato e, dando un colpo al cerchio e uno alla botte, far funzionare il tutto. Semplicemente come processo non mi soddisfa, in progetti piccoli può anche funzionare, se devo fare un sitarello di 10 pagine mica mi metto a disegnare i diagrammi di Gantt per coordinare le risorse. Prendo un junior gli faccio buttare giu' il codice e lo seguo per vedere se sta facendo giusto.
In progetti veramente grandi ti assicuro che non conviene neanche provarci: o si ha le idee chiare su cosa si vuole fare, o la teoria dell'Emerging Design te la puoi scordare. Insomma, stando alla mia esperienza personale, quando si parla di Software Engineering, Darwin ha torto.
O forse ho torto io. Boh.
-- Alex
Sei a favore dell'Agile e a quanto pare dell'XP. Di conseguenza hai una visione code-centrica di tutto il processo. Nel processo di produzione di soluzioni software enterprise non esiste solo il codice del programma e il codice dei test. Esistono lo studio di fattibilita, l'analisi funzionale, l'analisi tecnica, la progettazione e solo alla fine lo sviluppo, i test funzionali, i test di carico e i test di accettazione (UAT).
Agile promette di poter fare come i gamberi, partire dal risultato e, dando un colpo al cerchio e uno alla botte, far funzionare il tutto. Semplicemente come processo non mi soddisfa, in progetti piccoli può anche funzionare, se devo fare un sitarello di 10 pagine mica mi metto a disegnare i diagrammi di Gantt per coordinare le risorse. Prendo un junior gli faccio buttare giu' il codice e lo seguo per vedere se sta facendo giusto.
In progetti veramente grandi ti assicuro che non conviene neanche provarci: o si ha le idee chiare su cosa si vuole fare, o la teoria dell'Emerging Design te la puoi scordare. Insomma, stando alla mia esperienza personale, quando si parla di Software Engineering, Darwin ha torto.
O forse ho torto io. Boh.
-- Alex
@ Alex Di Adriano postato il 30/09/2009 18:02
> Sei a favore dell'Agile e a quanto pare dell'XP. Di conseguenza hai una visione code-centrica di tutto il processo.
Ma anche no. Non ho ancora usato mai Agile o XP (difficile fare pair programming essendo un solo programmatore). Ma tra quello che dicono, se uno legge attentamente, e le tue critiche, trovo un pò di differenza. In loro favore, mi pare si sia capito. Affiancare un esperto a un novellino forse toglie tempo all'esperto, vero, ma mi pare in teoria un eccellente metodo di addestrare qualcuno, di programmare facendo che tutti conoscano il codice del progetto, di avere una buona seconda opinione, o di disfarsi di una zavorra velocemente. Dipende dai caratteri dei programmatori affiancati, però.
> Nel processo di produzione di soluzioni software enterprise non esiste solo il codice del programma e il codice dei test. Esistono lo studio di fattibilita, l'analisi funzionale, l'analisi tecnica, la progettazione e solo alla fine lo sviluppo, i test funzionali, i test di carico e i test di accettazione (UAT).
D'accordissimo, ma mi sa che questi ci sono anche nell'Agile, o almeno, in quello che userei io. Come ho già detto prima, almeno. I test unitari, da quanto ho capito, sono:
- basati su uno studio di cosa si deve fare
- progettati per essere il più piccoli possibile ciascuno
- non un 'adesso faccio i test e poi è tutto pronto', che leggo solo dai detrattori.
> Agile promette di poter fare come i gamberi, partire dal risultato e, dando un colpo al cerchio e uno alla botte, far funzionare il tutto. Semplicemente come processo non mi soddisfa, in progetti piccoli può anche funzionare, se devo fare un sitarello di 10 pagine mica mi metto a disegnare i diagrammi di Gantt per coordinare le risorse. Prendo un junior gli faccio buttare giu' il codice e lo seguo per vedere se sta facendo giusto.
Per questi piccoli progetti non ti serve neanche Agile, mi sa, fallo velocemente e basta.
> In progetti veramente grandi ti assicuro che non conviene neanche provarci: o si ha le idee chiare su cosa si vuole fare, o la teoria dell'Emerging Design te la puoi scordare. Insomma, stando alla mia esperienza personale, quando si parla di Software Engineering, Darwin ha torto.
>
> O forse ho torto io. Boh.
Da quanto leggo sopra, almeno quelli di Google sembrano trarne giovamento. Boh. Devo anche dire che ci sono un sacco di programmatori che giurano su almeno alcuno dei princėpi dell' AP. Come altri che no. Io... Io uso quello che posso. -- Saludos
Adriano
Ma anche no. Non ho ancora usato mai Agile o XP (difficile fare pair programming essendo un solo programmatore). Ma tra quello che dicono, se uno legge attentamente, e le tue critiche, trovo un pò di differenza. In loro favore, mi pare si sia capito. Affiancare un esperto a un novellino forse toglie tempo all'esperto, vero, ma mi pare in teoria un eccellente metodo di addestrare qualcuno, di programmare facendo che tutti conoscano il codice del progetto, di avere una buona seconda opinione, o di disfarsi di una zavorra velocemente. Dipende dai caratteri dei programmatori affiancati, però.
> Nel processo di produzione di soluzioni software enterprise non esiste solo il codice del programma e il codice dei test. Esistono lo studio di fattibilita, l'analisi funzionale, l'analisi tecnica, la progettazione e solo alla fine lo sviluppo, i test funzionali, i test di carico e i test di accettazione (UAT).
D'accordissimo, ma mi sa che questi ci sono anche nell'Agile, o almeno, in quello che userei io. Come ho già detto prima, almeno. I test unitari, da quanto ho capito, sono:
- basati su uno studio di cosa si deve fare
- progettati per essere il più piccoli possibile ciascuno
- non un 'adesso faccio i test e poi è tutto pronto', che leggo solo dai detrattori.
> Agile promette di poter fare come i gamberi, partire dal risultato e, dando un colpo al cerchio e uno alla botte, far funzionare il tutto. Semplicemente come processo non mi soddisfa, in progetti piccoli può anche funzionare, se devo fare un sitarello di 10 pagine mica mi metto a disegnare i diagrammi di Gantt per coordinare le risorse. Prendo un junior gli faccio buttare giu' il codice e lo seguo per vedere se sta facendo giusto.
Per questi piccoli progetti non ti serve neanche Agile, mi sa, fallo velocemente e basta.
> In progetti veramente grandi ti assicuro che non conviene neanche provarci: o si ha le idee chiare su cosa si vuole fare, o la teoria dell'Emerging Design te la puoi scordare. Insomma, stando alla mia esperienza personale, quando si parla di Software Engineering, Darwin ha torto.
>
> O forse ho torto io. Boh.
Da quanto leggo sopra, almeno quelli di Google sembrano trarne giovamento. Boh. Devo anche dire che ci sono un sacco di programmatori che giurano su almeno alcuno dei princėpi dell' AP. Come altri che no. Io... Io uso quello che posso. -- Saludos
Adriano
@ Adriano Di Alex postato il 30/09/2009 18:34
> Da quanto leggo sopra, almeno quelli di Google sembrano trarne giovamento.
Beh, non e' perche' funziona in un caso (e che caso scusa...) che cambio idea.
O mi dimostrate che mi cambia radicalmente la vita in meglio o continuo a gestire i progetti come ho sempre fatto.
> Per questi piccoli progetti non ti serve neanche Agile, mi sa, fallo velocemente e basta.
Ed e' esattamente questo il punto. Per progetti grossi Agile non funziona, per quelli piccoli non vale la pena usare alcun processo particolare.
Anticipo gia' la prossima obiezione: e allora perche' li hanno inventati?
Ma mi sembra ovvio. Chi ci ha veramente guadagnato da tutta questa storia sono quelli che tengono le conferenze, che scrivono libri, che insegnano ai seminari e che ti vendono la certificazione facendoti credere che ora hai le palle di adamantio.
Quando la gente capira' che sotto-sotto Agile non serve si inventeranno qualcos'altro e te la spacceranno per il nuovo Santo Graal che risolvera' tutti i tuoi problemi, il libro comincera' cosi':
"Nello scorso decennio l'approccio allo sviluppo software ha seguito la filosofia Agile. Sebbene le premesse fossero incoraggianti, l'esperienza ha dimostrato come valore aggiunto di tale metodologia fosse poco se non addirittura nullo."
Seriamente: questo weekend lasciate perdere l'informatica, le classi, le interfacce e studiate un po' di marketing, ad esempio Il Bisogno Indotto.
-- Alex
Beh, non e' perche' funziona in un caso (e che caso scusa...) che cambio idea.
O mi dimostrate che mi cambia radicalmente la vita in meglio o continuo a gestire i progetti come ho sempre fatto.
> Per questi piccoli progetti non ti serve neanche Agile, mi sa, fallo velocemente e basta.
Ed e' esattamente questo il punto. Per progetti grossi Agile non funziona, per quelli piccoli non vale la pena usare alcun processo particolare.
Anticipo gia' la prossima obiezione: e allora perche' li hanno inventati?
Ma mi sembra ovvio. Chi ci ha veramente guadagnato da tutta questa storia sono quelli che tengono le conferenze, che scrivono libri, che insegnano ai seminari e che ti vendono la certificazione facendoti credere che ora hai le palle di adamantio.
Quando la gente capira' che sotto-sotto Agile non serve si inventeranno qualcos'altro e te la spacceranno per il nuovo Santo Graal che risolvera' tutti i tuoi problemi, il libro comincera' cosi':
"Nello scorso decennio l'approccio allo sviluppo software ha seguito la filosofia Agile. Sebbene le premesse fossero incoraggianti, l'esperienza ha dimostrato come valore aggiunto di tale metodologia fosse poco se non addirittura nullo."
Seriamente: questo weekend lasciate perdere l'informatica, le classi, le interfacce e studiate un po' di marketing, ad esempio Il Bisogno Indotto.
-- Alex
@ Alex Di Adriano postato il 01/10/2009 19:56
> O mi dimostrate che mi cambia radicalmente la vita in meglio o continuo a gestire i progetti come ho sempre fatto.
E perchè dovrei? Se ti va di informarti, e trarre giovamento dai punti validi dell'Agile Programming, dei test, ecc, buon per te, ma se no, non starò mica a rimbeccarti... Non sono un venditore del processo, mi pare solo che abbia qualche buona idea dentro.
> Ed e' esattamente questo il punto. Per progetti grossi Agile non funziona, per quelli piccoli non vale la pena usare alcun processo particolare.
>
> Anticipo gia' la prossima obiezione: e allora perche' li hanno inventati?
E sbagli. L'obiezione è 'lo dici tu che non funziona'. Mi piacerebbe più evidenza di questo. Come a te piacerebbe più evidenza del fatto che funzioni. La piccola differenza è che a me interessa sapere se le parti che mi interessano funzionano, e quando; e non ho bisogno di acquistare o buttare tutto il pacchetto.
-- Saludos
Adriano
E perchè dovrei? Se ti va di informarti, e trarre giovamento dai punti validi dell'Agile Programming, dei test, ecc, buon per te, ma se no, non starò mica a rimbeccarti... Non sono un venditore del processo, mi pare solo che abbia qualche buona idea dentro.
> Ed e' esattamente questo il punto. Per progetti grossi Agile non funziona, per quelli piccoli non vale la pena usare alcun processo particolare.
>
> Anticipo gia' la prossima obiezione: e allora perche' li hanno inventati?
E sbagli. L'obiezione è 'lo dici tu che non funziona'. Mi piacerebbe più evidenza di questo. Come a te piacerebbe più evidenza del fatto che funzioni. La piccola differenza è che a me interessa sapere se le parti che mi interessano funzionano, e quando; e non ho bisogno di acquistare o buttare tutto il pacchetto.
-- Saludos
Adriano
@ Adriano Di Alex postato il 01/10/2009 21:46
> E sbagli. L'obiezione è 'lo dici tu che non funziona'. Mi piacerebbe più evidenza di questo.
http://www.softwaremetrics.com/Agile/Agile%20Method%20and%20Other%20Fairy%20Tales.pdf
La cosa interessante e' che l'ho trovato oggi, e dice le stesse cose che dico io da 8 anni. Mi piace in particolare dove afferma che Agile "formalizza le cattive abitudini".
Quindi, visto che sono per l'OO e per il riutilizzo del codice, non riscrivero' cose gia' scritte da qualcun'altro meglio di come le scriverei io.
-- Alex
http://www.softwaremetrics.com/Agile/Agile%20Method%20and%20Other%20Fairy%20Tales.pdf
La cosa interessante e' che l'ho trovato oggi, e dice le stesse cose che dico io da 8 anni. Mi piace in particolare dove afferma che Agile "formalizza le cattive abitudini".
Quindi, visto che sono per l'OO e per il riutilizzo del codice, non riscrivero' cose gia' scritte da qualcun'altro meglio di come le scriverei io.
-- Alex
@ Alex Di Adriano postato il 02/10/2009 14:18
> > E sbagli. L'obiezione è 'lo dici tu che non funziona'. Mi piacerebbe più evidenza di questo.
>
> http://www.softwaremetrics.com/Agile/Agile%20Method%20and%20Other%20Fairy%20Tales.pdf
>
> La cosa interessante e' che l'ho trovato oggi, e dice le stesse cose che dico io da 8 anni. Mi piace in particolare dove afferma che Agile "formalizza le cattive abitudini".
> Quindi, visto che sono per l'OO e per il riutilizzo del codice, non riscrivero' cose gia' scritte da qualcun'altro meglio di come le scriverei io.
>
Ho trovato tanti aneddoti in quel whitepaper che ho chiuso alla decima pagina. Bellissimo come dice di essere uno statistico (e ci credo), ma non c'è uno straccio di studio nella prima metà del paper. Ti lascio questo link, tanto per ricambiare: http://stackoverflow.com/questions/301993/is-agile-development-dead
E chiudo qua, perchè ormai mi hai stufato. Se senti e leggi solo quello che vuoi sentire, buon pro ti faccia. -- Saludos
Adriano
>
> http://www.softwaremetrics.com/Agile/Agile%20Method%20and%20Other%20Fairy%20Tales.pdf
>
> La cosa interessante e' che l'ho trovato oggi, e dice le stesse cose che dico io da 8 anni. Mi piace in particolare dove afferma che Agile "formalizza le cattive abitudini".
> Quindi, visto che sono per l'OO e per il riutilizzo del codice, non riscrivero' cose gia' scritte da qualcun'altro meglio di come le scriverei io.
>
Ho trovato tanti aneddoti in quel whitepaper che ho chiuso alla decima pagina. Bellissimo come dice di essere uno statistico (e ci credo), ma non c'è uno straccio di studio nella prima metà del paper. Ti lascio questo link, tanto per ricambiare: http://stackoverflow.com/questions/301993/is-agile-development-dead
E chiudo qua, perchè ormai mi hai stufato. Se senti e leggi solo quello che vuoi sentire, buon pro ti faccia. -- Saludos
Adriano
@ Adriano Di Alex postato il 03/10/2009 13:54
> Ho trovato tanti aneddoti in quel whitepaper che ho chiuso alla decima pagina.
> Bellissimo come dice di essere uno statistico (e ci credo), ma non c'è uno straccio di studio nella prima metà del paper.
Venti pagine... madonna santa che fatica. Ti faccio un riassunto.
Dice che il problema dell'informatica sono gli informatici stessi. Vogliono arrivare troppo presto al sodo (schiacciare bottoni) perche' e' l'unica cosa che sanno fare e non necessariamente bene. Una specie di ejaculazione precoce in salsa informatica, zero preliminari e risultati miseri quando e' ora.
E' risaputo che gli informatici medi sono incapaci di relazionarsi con le persone, in questo caso: raccogliere requisiti ben fatti presso il cliente.
Agile fa presa sulle masse perche' formalizza la cattiva abitudine di ritenere l'informatica al centro dell'universo, mentre i clienti sono dei poveri ebeti che non sanno fornire correttamente le specifiche di un progetto. La verita' e' che sono gli informatici a non saperle raccogliere. Piuttosto che ammettere che l'informatica e' una scienza giovane che ha ancora molto da imparare, Agile preferisce dire che sono gli altri ad essere dei vecchi rimbambiti e quindi devono cambiare loro, le cattive abitudini dell'informatica e tutti i suoi capricci devono rimanere come sono.
Io personalmente vedo Agile come l'adolescenza dell'informatica, la fase di ribellione dove si pensa di avere sempre ragione. E' un passaggio obbligato. Dura ancora un po' e poi, speriamo, diventera' adulta e incomincera' ad assumersi le proprie responsabilita'.
P.S. Questo era solo un paper. L'autore ha scritto un libro descrivendo piu' ampiamente le sue idee, non ti giro il link perche' ora mi sono stufato io.
-- Alex
> Bellissimo come dice di essere uno statistico (e ci credo), ma non c'è uno straccio di studio nella prima metà del paper.
Venti pagine... madonna santa che fatica. Ti faccio un riassunto.
Dice che il problema dell'informatica sono gli informatici stessi. Vogliono arrivare troppo presto al sodo (schiacciare bottoni) perche' e' l'unica cosa che sanno fare e non necessariamente bene. Una specie di ejaculazione precoce in salsa informatica, zero preliminari e risultati miseri quando e' ora.
E' risaputo che gli informatici medi sono incapaci di relazionarsi con le persone, in questo caso: raccogliere requisiti ben fatti presso il cliente.
Agile fa presa sulle masse perche' formalizza la cattiva abitudine di ritenere l'informatica al centro dell'universo, mentre i clienti sono dei poveri ebeti che non sanno fornire correttamente le specifiche di un progetto. La verita' e' che sono gli informatici a non saperle raccogliere. Piuttosto che ammettere che l'informatica e' una scienza giovane che ha ancora molto da imparare, Agile preferisce dire che sono gli altri ad essere dei vecchi rimbambiti e quindi devono cambiare loro, le cattive abitudini dell'informatica e tutti i suoi capricci devono rimanere come sono.
Io personalmente vedo Agile come l'adolescenza dell'informatica, la fase di ribellione dove si pensa di avere sempre ragione. E' un passaggio obbligato. Dura ancora un po' e poi, speriamo, diventera' adulta e incomincera' ad assumersi le proprie responsabilita'.
P.S. Questo era solo un paper. L'autore ha scritto un libro descrivendo piu' ampiamente le sue idee, non ti giro il link perche' ora mi sono stufato io.
-- Alex
@ Alex Di Davide Bianchi postato il 04/10/2009 08:36
> Dice che il problema dell'informatica sono gli informatici stessi.
Sostituisci "informatica" ed "informatici" con "programmazione" e "programmatori"
-- Davide Bianchi
Sostituisci "informatica" ed "informatici" con "programmazione" e "programmatori"
-- Davide Bianchi
@ Davide Bianchi Di Anonymous cougar postato il 01/10/2009 10:37
> Ottimo. E che e' successo al buon-vecchio "misura il culo del cliente e fai il cuscino giusto la prima volta"?
e' successo che l'azienda ha assunto talmente tanti manager e bisniss anal-ists per produrre carta inutile e ritardi nel processo che il tuo cliente ha preso 20 chili tra la commessa e la consegna ed il suo culo non ci sta piu'. ah, il cliente nel frattempo si e' sposato e vuole un divano. no, non piu' nero, la moglie lo vuole a fiori. -- Anonymous cougar
e' successo che l'azienda ha assunto talmente tanti manager e bisniss anal-ists per produrre carta inutile e ritardi nel processo che il tuo cliente ha preso 20 chili tra la commessa e la consegna ed il suo culo non ci sta piu'. ah, il cliente nel frattempo si e' sposato e vuole un divano. no, non piu' nero, la moglie lo vuole a fiori. -- Anonymous cougar
@ Anonymous cobra Di Alex postato il 30/09/2009 12:33
> no. in teoria (ma non essendo nemmeno io un fan del TDP potrei sbagliarmi)
> 1. crea un modello di cuscino, schienale etc..
> 2. prepara un test per vedere se sono comodi
> 3. applica 2 ad 1 fino a che va bene
> 4. fai provare al cliente.
Questo non e' test-driven. Qui stai scrivendo il codice prima e i test poi e nel mio caso sfondi una porta aperta: non sono contrario ai test ci mancherebbe. Voglio solo evidenziare il paradosso temporale del disegnare prima i test e scrivere l'applicazione in seguito per non farli fallire.
TDD e' piuttosto:
1. farle fare il test di gravidanza (test)
2. ehm... ok ci siamo capiti (development)
3. chiedere alla ragazza se ci sta (analisi)
-- Alex
> 1. crea un modello di cuscino, schienale etc..
> 2. prepara un test per vedere se sono comodi
> 3. applica 2 ad 1 fino a che va bene
> 4. fai provare al cliente.
Questo non e' test-driven. Qui stai scrivendo il codice prima e i test poi e nel mio caso sfondi una porta aperta: non sono contrario ai test ci mancherebbe. Voglio solo evidenziare il paradosso temporale del disegnare prima i test e scrivere l'applicazione in seguito per non farli fallire.
TDD e' piuttosto:
1. farle fare il test di gravidanza (test)
2. ehm... ok ci siamo capiti (development)
3. chiedere alla ragazza se ci sta (analisi)
-- Alex
@ Davide Bianchi Di Sandra postato il 29/09/2009 21:23
> > A parte ciò sono programmatore di vecchia data, ho iniziato sul buon vecchio Clipper
> CLIPPER! Quanti ricordi! Versione '87 o 5.x?
Bè, ho iniziato con una roba che chissà se qualcuna se la ricorda; si chiamava KnowledgeMan, era un sistema integrato con dbms relazionale (l'alternativa era Focus, reticolare. Che casino!!!). Poi db3, poi clipper 87 e in parallelo Oracle e poi via cosė. Ai giorni nostri uso Visual Foxpro (e lo uso come fosse Clipper! fregandomene dell'object oriented per quanto possibile) e poi... lo so, mi vergogno e chiedo scusissima....... PHP e MySql per il web! Uah Uah Uah!!! -- Sandra
> CLIPPER! Quanti ricordi! Versione '87 o 5.x?
Bè, ho iniziato con una roba che chissà se qualcuna se la ricorda; si chiamava KnowledgeMan, era un sistema integrato con dbms relazionale (l'alternativa era Focus, reticolare. Che casino!!!). Poi db3, poi clipper 87 e in parallelo Oracle e poi via cosė. Ai giorni nostri uso Visual Foxpro (e lo uso come fosse Clipper! fregandomene dell'object oriented per quanto possibile) e poi... lo so, mi vergogno e chiedo scusissima....... PHP e MySql per il web! Uah Uah Uah!!! -- Sandra
@ Davide Bianchi Di IgorB postato il 29/09/2009 15:30
> > Ero convinto che il codice si scrivesse in una maniera sola...
>
> Si', si scrive con la testa, [...]
Questa è la Grande Verità, di cui sono adepto, pur scrivendo al massimo un po' di SQL! -- IgorB
>
> Si', si scrive con la testa, [...]
Questa è la Grande Verità, di cui sono adepto, pur scrivendo al massimo un po' di SQL! -- IgorB
@ Davide Bianchi Di Sabrina postato il 13/10/2009 19:16
> > Ero convinto che il codice si scrivesse in una maniera sola...
>
> Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.
Questa e' una frase bellissima, quando e se dovessi diventare programmatrice ci farei un quadretto da appendere in ufficio. -- Sabrina
>
> Si', si scrive con la testa, solo che c'e' gente che non ha la piu' pallida idea di come fare e si riempie la bocca di paroloni e sigle astruse.
Questa e' una frase bellissima, quando e se dovessi diventare programmatrice ci farei un quadretto da appendere in ufficio. -- Sabrina
Agile programming Di Andrea Occhi postato il 29/09/2009 08:47
Purtroppo troppe volte Agile Programming viene visto solo come un modo di ritardare la consegna delle specifiche, senza dare il tempo di fare tutta la metodologia.
A questo punto tutto va a donnine di facili costumi.... -- Andrea Occhi
A questo punto tutto va a donnine di facili costumi.... -- Andrea Occhi
la differenza tra riparare e creare Di Anonymous coder postato il 29/09/2009 09:32
per quanto ci siano un sacco di persone che parlano a vuoto, spesso le tecniche di design piu' "moderne" sono valide. sta nell'intelligenza delle persone di scegiere l'approccio giusto a seconda del problema. uno come martin fowler, ad esempio, non e' un venditore di fumo. non nel caso della storia pero' siamo ancora in un'altra categoria: un conto e' un lavoro per fare un programma da zero, un conto e' fare del bugfix.
--
Anonymous coder
@ Anonymous coder Di Alex postato il 30/09/2009 11:57
> uno come martin fowler, ad esempio, non e' un venditore di fumo.
No, e' un venditore di libri. Lui il suo obiettivo l'ha raggiunto.
P.S. A scanso d'equivoci, non sono a priori contro tutto quello che Fowler afferma.
-- Alex
No, e' un venditore di libri. Lui il suo obiettivo l'ha raggiunto.
P.S. A scanso d'equivoci, non sono a priori contro tutto quello che Fowler afferma.
-- Alex
@ Alex Di Anonymous coward postato il 01/10/2009 10:50
> > uno come martin fowler, ad esempio, non e' un venditore di fumo.
>
> No, e' un venditore di libri.
LOL. ma sai che sta facendo ora? -- Anonymous coward
>
> No, e' un venditore di libri.
LOL. ma sai che sta facendo ora? -- Anonymous coward
Mi devo preoccupare? Di Estrandal postato il 29/09/2009 10:29
E' un pò OT lo sò ma...
Ultimamente la mia società vuole fare una "Intranet" e le persone che se ne occupano mi danno la fiducia di un venditore di paralumi...
Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
Leggendo una tua vecchia storia mi viene un dubbio.
Mi devo preoccupare? -- Estrandal
Ultimamente la mia società vuole fare una "Intranet" e le persone che se ne occupano mi danno la fiducia di un venditore di paralumi...
Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
Leggendo una tua vecchia storia mi viene un dubbio.
Mi devo preoccupare? -- Estrandal
@ Estrandal Di Adriano postato il 29/09/2009 14:22
> Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
> Leggendo una tua vecchia storia mi viene un dubbio.
> Mi devo preoccupare?
Non lo sei già? -- Saludos
Adriano
> Leggendo una tua vecchia storia mi viene un dubbio.
> Mi devo preoccupare?
Non lo sei già? -- Saludos
Adriano
@ Estrandal Di Anonymous coward postato il 30/09/2009 08:12
> Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
> Leggendo una tua vecchia storia mi viene un dubbio.
> Mi devo preoccupare?
Ma nooo. E' sufficiente che migriate tutto quello che fate a qualcosa che gestisca LDAP in modo nativo e trasparente, cosi' che non ci sia bisogno di capire come cappero funziona.
Hai presente, no: "avanti, avanti, ok, avanti, seleziona, avanti, ok, fine".
Ehm... Cosi', giusto per curiosita'... Che differenza passa tra "posta elettronica" ed "email", li' da voi?
CYA -- Anonymous coward
@ Anonymous coward Di Anonymous coward postato il 30/09/2009 12:04
>
> > Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
> > Leggendo una tua vecchia storia mi viene un dubbio.
> > Mi devo preoccupare?
>
> Ma nooo. E' sufficiente che migriate tutto quello che fate a qualcosa che gestisca LDAP in modo nativo e trasparente, cosi' che non ci sia bisogno di capire come cappero funziona.
> Hai presente, no: "avanti, avanti, ok, avanti, seleziona, avanti, ok, fine".
>
> Ehm... Cosi', giusto per curiosita'... Che differenza passa tra "posta elettronica" ed "email", li' da voi?
>
> CYA
>
Volevo dire tra account di dominio e posta elettronica...
E ho scritto anche elettrionica (horrore...)
Vista le mie gaffes penso di essere già preoccupato a livello inconscio ^^
-- Anonymous coward
> > Vogliono sincronizzare ldap per gestire un unica password tra posta elettrionica e email (e noi non utilizziamo $posta_redmond) non sanno come effettuare le query su ldap e ci chiedono a noi come fare etc...
> > Leggendo una tua vecchia storia mi viene un dubbio.
> > Mi devo preoccupare?
>
> Ma nooo. E' sufficiente che migriate tutto quello che fate a qualcosa che gestisca LDAP in modo nativo e trasparente, cosi' che non ci sia bisogno di capire come cappero funziona.
> Hai presente, no: "avanti, avanti, ok, avanti, seleziona, avanti, ok, fine".
>
> Ehm... Cosi', giusto per curiosita'... Che differenza passa tra "posta elettronica" ed "email", li' da voi?
>
> CYA
>
Volevo dire tra account di dominio e posta elettronica...
E ho scritto anche elettrionica (horrore...)
Vista le mie gaffes penso di essere già preoccupato a livello inconscio ^^
-- Anonymous coward
Chi č che mi gufa contro? Di Verzasoft postato il 30/09/2009 11:00
Solo due giorni fa ho scritto "non so di cosa state parlando".
Ieri cos'è successo! Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.
In pratica, ora credo di poter riassumere in cosa consiste questo agile programming:
1) fare le stesse cose di prima, con un metodo comune (comune a chi? per ogni divisione sw siamo in due!), imposto, difficile da applicare e in ogni caso temporalmente dispendioso.
2) Loggare ogni azione che viene eseguita durante la giornata di modo da poter avere una piena conoscenza di cosa si ha fatto. Poco importa che metà del tempo sia stato usato per creare il log. (Ah! Il falso mito che avere un log delle azioni di un programmatore equivalga ad avere il controllo della situazione)
3) Usare il forum anzichè chiedere lumi direttamente al collega a fianco che ha fatto lui il programma, perchè cosi' tutti gli altri potranno vedere la risposta (l'ho già detto che i settori sono di DUE persone?). Poi voglio vedere quanto ci metto a risolvere un problema via forum (costiturà la nostra knowledge-base!) e quanto parlando col collega di fianco...
4) Il "repository comune". Cos'ha la nostra directory condivisa sul server che non va?
Ho indovinato? -- Verzasoft
Ieri cos'è successo! Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.
In pratica, ora credo di poter riassumere in cosa consiste questo agile programming:
1) fare le stesse cose di prima, con un metodo comune (comune a chi? per ogni divisione sw siamo in due!), imposto, difficile da applicare e in ogni caso temporalmente dispendioso.
2) Loggare ogni azione che viene eseguita durante la giornata di modo da poter avere una piena conoscenza di cosa si ha fatto. Poco importa che metà del tempo sia stato usato per creare il log. (Ah! Il falso mito che avere un log delle azioni di un programmatore equivalga ad avere il controllo della situazione)
3) Usare il forum anzichè chiedere lumi direttamente al collega a fianco che ha fatto lui il programma, perchè cosi' tutti gli altri potranno vedere la risposta (l'ho già detto che i settori sono di DUE persone?). Poi voglio vedere quanto ci metto a risolvere un problema via forum (costiturà la nostra knowledge-base!) e quanto parlando col collega di fianco...
4) Il "repository comune". Cos'ha la nostra directory condivisa sul server che non va?
Ho indovinato? -- Verzasoft
@ Verzasoft Di Davide Bianchi postato il 30/09/2009 11:08
> Ieri cos'è successo! Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.
...
> Ho indovinato?
Povero te... tu non hai idea... Aspetto le storie eh...
-- Davide Bianchi
...
> Ho indovinato?
Povero te... tu non hai idea... Aspetto le storie eh...
-- Davide Bianchi
@ Verzasoft Di maxxfi postato il 30/09/2009 13:49
> Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.
E gia' cosi' sono partiti col piede sbagliato. Se lo imponi dall'alto senza
farlo capire a tutti prima, qualunque metodo fallira'.
Io ho lavorato per un paio di anni con progetti agile, e non mi pare che i punti 2 e 3 facevano parte del programma, anzi. P.es. gli sviluppatori venivano riorganizzati in modo da essere fisicamente vicini tra di loro, in modo da aiutarsi a vicenda, senza loggare nulla o perdere tempo a scrivere su forum o email.
Poi certo c'erano forum, sistemi di IM e wiki varie, ma era per lasciare traccia a chi veniva dopo (uno dei criteri era scrivere MENO documentazione inutile e perder MENO tempo con meeting lunghi)
-- maxxfi
@ maxxfi Di Davide Bianchi postato il 30/09/2009 14:00
> Poi certo c'erano forum, sistemi di IM e wiki varie, ma era per lasciare traccia a chi veniva dopo (uno dei criteri era scrivere MENO documentazione inutile e perder MENO tempo con meeting lunghi)
Peccato che, di solito, il punto uno (meno documentazione) viene raggiunto perfettamente: non si scrive piu' documentazione alcuna, il punto due invece...
-- Davide Bianchi
Peccato che, di solito, il punto uno (meno documentazione) viene raggiunto perfettamente: non si scrive piu' documentazione alcuna, il punto due invece...
-- Davide Bianchi
@ Davide Bianchi Di Alex postato il 30/09/2009 14:36
> Peccato che, di solito, il punto uno (meno documentazione) viene raggiunto perfettamente: non si scrive piu' documentazione alcuna, il punto due invece...
Ah, gia'... un'altra perla e': non si scrivono commenti, il codice e' autoesplicante.
-- Alex
Ah, gia'... un'altra perla e': non si scrivono commenti, il codice e' autoesplicante.
-- Alex
@ Verzasoft Di Earwig postato il 30/09/2009 20:58
> Ieri cos'è successo! Riunione col responsabile-software, che esordisce con: "Da oggi introduciamo la nuova frontiera dell'Agiàil programming!". Mi sono venuti i peli dritti.
MWAHAHAHAHAH, povero te...hai tutta la mia solidarieta'.
Comunque non si tratta ne' di gufata, ne di Murphy: semplicemente e' la nuova moda, inizia a spuntare come i funghi dappertutto.
Soprattutto perche' consente agli UL strapagati(e completamente incapaci) di fingere molto meglio di far parte del progetto, e che il lavoro non lo fanno SOLO i programmatori: ma soprattutto, gli permette di stare tutta la giornata appolaiati come gufi dietro la tua schiena, dicendoti cosa fare ogni minuto senza "sprecare tempo" nelle vecchie, lunghe, inutili analisi funzionali che la vecchia metodologia imponeva(e che toccava fare a loro...e che di solito costituiva prova fisica della loro incapacita').
Oh, leggete qui sopra tenendo a mente che sono tremendamente sarcastico eh !!!!
> 1) fare le stesse cose di prima, con un metodo comune ...
in 2 persone fate anche gli Scram ?
> 2) Loggare ogni azione che viene eseguita durante la giornata....
a me avevano imposto un foglio Excel per "loggare"...uno nuovo ogni 2 settimane.
Non ti dico quando bisognava creare il nuovo "Backlog"...2 giorni persi: tutti e 6 gli sviluppatori fermi a discutere su cosa inserirci e scrutando nella sfera di cristallo la risposta a "quanti giorni ci si mette a fare questo pezzettino ?" (giuro che sembrava di essere ad un'asta, ma con il numero di ORE che scendeva, non saliva ).
> 3) Usare il forum anzichè chiedere lumi direttamente al collega a fianco....
questo veramente dovrebbe essere l'opposto delle metodologie agili eh....dato il fatto che ogni task deve essere spezzettato in subtask della dimensione di un atomo, in teoria si dovrebbe PARLARE ogni 2 secondi per coordinarsi.
> 4) Il "repository comune". Cos'ha la nostra directory condivisa sul server che non va?
vabbeh dai...questa non te la passo. un SCM e' cento volte piu comodo di una "directory comune", e' supportato dagli IDE, se fai caxxate puoi tornare indietro, puoi creare le TAG per stabilire punti stabili del codice, ecc...
-- Earwig
MWAHAHAHAHAH, povero te...hai tutta la mia solidarieta'.
Comunque non si tratta ne' di gufata, ne di Murphy: semplicemente e' la nuova moda, inizia a spuntare come i funghi dappertutto.
Soprattutto perche' consente agli UL strapagati(e completamente incapaci) di fingere molto meglio di far parte del progetto, e che il lavoro non lo fanno SOLO i programmatori: ma soprattutto, gli permette di stare tutta la giornata appolaiati come gufi dietro la tua schiena, dicendoti cosa fare ogni minuto senza "sprecare tempo" nelle vecchie, lunghe, inutili analisi funzionali che la vecchia metodologia imponeva(e che toccava fare a loro...e che di solito costituiva prova fisica della loro incapacita').
Oh, leggete qui sopra tenendo a mente che sono tremendamente sarcastico eh !!!!
> 1) fare le stesse cose di prima, con un metodo comune ...
in 2 persone fate anche gli Scram ?
> 2) Loggare ogni azione che viene eseguita durante la giornata....
a me avevano imposto un foglio Excel per "loggare"...uno nuovo ogni 2 settimane.
Non ti dico quando bisognava creare il nuovo "Backlog"...2 giorni persi: tutti e 6 gli sviluppatori fermi a discutere su cosa inserirci e scrutando nella sfera di cristallo la risposta a "quanti giorni ci si mette a fare questo pezzettino ?" (giuro che sembrava di essere ad un'asta, ma con il numero di ORE che scendeva, non saliva ).
> 3) Usare il forum anzichè chiedere lumi direttamente al collega a fianco....
questo veramente dovrebbe essere l'opposto delle metodologie agili eh....dato il fatto che ogni task deve essere spezzettato in subtask della dimensione di un atomo, in teoria si dovrebbe PARLARE ogni 2 secondi per coordinarsi.
> 4) Il "repository comune". Cos'ha la nostra directory condivisa sul server che non va?
vabbeh dai...questa non te la passo. un SCM e' cento volte piu comodo di una "directory comune", e' supportato dagli IDE, se fai caxxate puoi tornare indietro, puoi creare le TAG per stabilire punti stabili del codice, ecc...
-- Earwig
@ Earwig Di Verzasoft postato il 01/10/2009 09:07
> in 2 persone fate anche gli Scram ?
ESATTO!! Vedo che tu SAI!
Il bello è che l'UL in questione è una persona giovane e competente, mica un pizzettaro, per quello mi sono stra-stupito quando se n'è uscito con questa storia. -- Verzasoft
ESATTO!!
Vedo che tu SAI!
Il bello è che l'UL in questione è una persona giovane e competente, mica un pizzettaro, per quello mi sono stra-stupito quando se n'è uscito con questa storia. -- Verzasoft
@ Verzasoft Di Anonymous coward postato il 01/10/2009 16:14
> > in 2 persone fate anche gli Scram ?
> ESATTO!! Vedo che tu SAI!
>
> Il bello è che l'UL in questione è una persona giovane e competente, mica un pizzettaro, per quello mi sono stra-stupito quando se n'è uscito con questa storia.
>
>
Anche chi lo aveva imposto a me e' competentissimo e intelligente...e' solo che:
1) vendersi come "Agile Programmer" e' la novita' del momento: se non "lavori in casa" (aka fai il consulente), e' utilissimo per dimostrare di avere una marcia in piu.
2) e' troppo ottimista riguardo gli UL...gli e' andata bene la prima volta perche' gli UL non avevano mai visto un progetto gestito in quel modo, ma la seconda hanno imparato come approfittarsene ed e' successo il disastro.
-- Anonymous coward
> ESATTO!!
Vedo che tu SAI!
>
> Il bello è che l'UL in questione è una persona giovane e competente, mica un pizzettaro, per quello mi sono stra-stupito quando se n'è uscito con questa storia.
>
>
Anche chi lo aveva imposto a me e' competentissimo e intelligente...e' solo che:
1) vendersi come "Agile Programmer" e' la novita' del momento: se non "lavori in casa" (aka fai il consulente), e' utilissimo per dimostrare di avere una marcia in piu.
2) e' troppo ottimista riguardo gli UL...gli e' andata bene la prima volta perche' gli UL non avevano mai visto un progetto gestito in quel modo, ma la seconda hanno imparato come approfittarsene ed e' successo il disastro.
-- Anonymous coward
@ Earwig Di Adriano postato il 01/10/2009 15:24
> > 4) Il "repository comune". Cos'ha la nostra directory condivisa sul server che non va?
>
> vabbeh dai...questa non te la passo. un SCM e' cento volte piu comodo di una "directory comune", e' supportato dagli IDE, se fai caxxate puoi tornare indietro, puoi creare le TAG per stabilire punti stabili del codice, ecc...
Anch'io sono favorevolissimo ai VCS. Installare e usare subversion (con tortoisesvn su Windows, pure) è facilissimo, e la quantità di problemi che risolve è enorme. A cominciare da 'Mi hai sovrascritto il file con i cambiamenti, ARGH!' -- Saludos
Adriano
>
> vabbeh dai...questa non te la passo. un SCM e' cento volte piu comodo di una "directory comune", e' supportato dagli IDE, se fai caxxate puoi tornare indietro, puoi creare le TAG per stabilire punti stabili del codice, ecc...
Anch'io sono favorevolissimo ai VCS. Installare e usare subversion (con tortoisesvn su Windows, pure) è facilissimo, e la quantità di problemi che risolve è enorme. A cominciare da 'Mi hai sovrascritto il file con i cambiamenti, ARGH!' -- Saludos
Adriano
come andra' a finire. Di R.P. postato il 01/10/2009 08:22
A. il Canadese non risolvera' una cippa di niente, anzi peggiorera' le cose.
B. verrannno presi successivamete un turco, un albanese e un libanese, ognuno dei quali peggiorerà a sua volta la situazione
C. alla fine il padulo finirà, come al solito, tra le chiappe di BigD.
D. BigD cambierà lavoro.
insomma, un film già visto
--
R.P.
B. verrannno presi successivamete un turco, un albanese e un libanese, ognuno dei quali peggiorerà a sua volta la situazione
C. alla fine il padulo finirà, come al solito, tra le chiappe di BigD.
D. BigD cambierà lavoro.
insomma, un film già visto
--
R.P.
@ R.P. Di Mauro Pietrobelli postato il 01/10/2009 11:11
> C. alla fine il padulo finirà, come al solito, tra le chiappe di BigD.
Ma perchè vuoi cosė male a DigD? -- Mamo
Ma perchè vuoi cosė male a DigD? -- Mamo
@ Mauro Pietrobelli Di Davide Bianchi postato il 01/10/2009 11:25
> Ma perchè vuoi cosė male a DigD?
Secondo me gode delle mie sofferenze... -- Davide Bianchi
Secondo me gode delle mie sofferenze... -- Davide Bianchi
Humm... Di Anonymous coward postato il 04/10/2009 11:47
Visto che si discute di metodologie & filosofie di programmazione, my 2c: la maggior parte delle metodologie nasce dall'esperienza di un dato sviluppatore/team su di un dato ambito di progetti, da cui gli autori CERCANO di astrarre un metodo che possa avere una applicabilità più ampia cambiando gli sviluppatori e la tipologia dei progetti.
La chiave è proprio in quel "cercano": per quanto in ogni metodologia ci siano parecchi spunti utili che bene conoscere e soprattutto provare (in prima persona e nella propria realtà), non bisogna pensare che i benefici del metodo si trasmettano automagicamente a qualsiasi altro sviluppatore/team che sta lavorando su progetti magari di tutt'altra natura.
Un metodo che vada bene per scrivere grandioso software aziendale non è in toto applicabile allo sviluppo del software di massa o ai giochi (non li distribuisci a gente che puoi contattare di persona, nè sai che hw/sw hanno installato), e a sua volta metodi ottimali per questi mondi non serviranno a molto per sviluppare il software di controllo per la rom del frigorifero.
Poi, un metodo che vada bene per grandi team di sviluppo non andrà bene per singoli sviluppatori, uno che miri a rendere in fretta produttivi nuovi sviluppatori in un progetto non sarà proprio ideale per un team già affiatato, uno che sia eccellente per incastrare migliaia di attività per una release a lunga schedulazione servirà a poco se magari hai una webapp e devi testare poche update per volta ma in tempo reale, e cosė via...
Però ogni metodo può insegnarci qualcosa, quindi non ha senso corregli troppo dietro a prescindere dall'applicabilità reale, come non ha senso spararci sopra perchè a noi in questo dato contesto serve a poco o addirittura ci fa solo perdere tempo. -- Anonymous coward
La chiave è proprio in quel "cercano": per quanto in ogni metodologia ci siano parecchi spunti utili che bene conoscere e soprattutto provare (in prima persona e nella propria realtà), non bisogna pensare che i benefici del metodo si trasmettano automagicamente a qualsiasi altro sviluppatore/team che sta lavorando su progetti magari di tutt'altra natura.
Un metodo che vada bene per scrivere grandioso software aziendale non è in toto applicabile allo sviluppo del software di massa o ai giochi (non li distribuisci a gente che puoi contattare di persona, nè sai che hw/sw hanno installato), e a sua volta metodi ottimali per questi mondi non serviranno a molto per sviluppare il software di controllo per la rom del frigorifero.
Poi, un metodo che vada bene per grandi team di sviluppo non andrà bene per singoli sviluppatori, uno che miri a rendere in fretta produttivi nuovi sviluppatori in un progetto non sarà proprio ideale per un team già affiatato, uno che sia eccellente per incastrare migliaia di attività per una release a lunga schedulazione servirà a poco se magari hai una webapp e devi testare poche update per volta ma in tempo reale, e cosė via...
Però ogni metodo può insegnarci qualcosa, quindi non ha senso corregli troppo dietro a prescindere dall'applicabilità reale, come non ha senso spararci sopra perchè a noi in questo dato contesto serve a poco o addirittura ci fa solo perdere tempo. -- Anonymous coward
