fek
05-02-2008, 13:40
Di Eric Gunnerson. Discuss :)
View Full Version : [DESIGN] "Any design effort that takes more than 30 minutes is a waste of time."
NeoNum6
05-02-2008, 13:41
design effort in che senso?
fek
05-02-2008, 13:45
design effort in che senso?
Traduco in italiano: "Ogni sessione di design che dura piu' di 30 minuti e' una perdita di tempo".
E' una frase molto profonda nella sua sintesi.
Traduco in italiano: "Ogni sessione di design che dura piu' di 30 minuti e' una perdita di tempo".
E' una frase molto profonda nella sua sintesi.
NeoNum6
05-02-2008, 13:47
Traduco in italiano: "Ogni sessione di design che dura piu' di 30 minuti e' una perdita di tempo".
E' una frase molto profonda nella sua sintesi.
no la traduzione l'avevo capita :D
design grafico o design come progettazione software?
E' una frase molto profonda nella sua sintesi.
no la traduzione l'avevo capita :D
design grafico o design come progettazione software?
^TiGeRShArK^
05-02-2008, 13:49
design effort in che senso?
"sforzo progettuale" letteralmente...
Traducendo lì'intera frase sarebbe qualcosa del genere:
"Qualsiasi lavoro di progettazione che impieghi + di 30 minuti è uno spreco di tempo."
Sostanzialmente sono d'accordo con il senso generale dell'affermazione...
Forse 30 minuti però è un pò troppo estremizzato :asd:
NON considerando ovviamente i cambiamenti di design necessari in corso d'opera.
Comunque ovviamente non puù essere considerato in termini assoluti.
Per progetti realmente grandi in 30 minuti non si fa neanche in tempo ad iniziare a capire il problema :mbe:
"sforzo progettuale" letteralmente...
Traducendo lì'intera frase sarebbe qualcosa del genere:
"Qualsiasi lavoro di progettazione che impieghi + di 30 minuti è uno spreco di tempo."
Sostanzialmente sono d'accordo con il senso generale dell'affermazione...
Forse 30 minuti però è un pò troppo estremizzato :asd:
NON considerando ovviamente i cambiamenti di design necessari in corso d'opera.
Comunque ovviamente non puù essere considerato in termini assoluti.
Per progetti realmente grandi in 30 minuti non si fa neanche in tempo ad iniziare a capire il problema :mbe:
^TiGeRShArK^
05-02-2008, 13:50
Traduco in italiano: "Ogni sessione di design che dura piu' di 30 minuti e' una perdita di tempo".
E' una frase molto profonda nella sua sintesi.
:asd:
e bella traduzione che gli hai fatto :asd:
aveva il dubbio su design.. e tu glielo traduci.... DESIGN :D
E' una frase molto profonda nella sua sintesi.
:asd:
e bella traduzione che gli hai fatto :asd:
aveva il dubbio su design.. e tu glielo traduci.... DESIGN :D
NeoNum6
05-02-2008, 13:52
io non sono d'accordo...la progettazione è importante...sopratutto per progetti grandi...inoltre la progettazione non deve finire mai, con questo si risolvono i problemi di cambiamento di progetto repentini...vedi extreme programming
NeoNum6
05-02-2008, 13:53
:asd:
e bella traduzione che gli hai fatto :asd:
aveva il dubbio su design.. e tu glielo traduci.... DESIGN :D
vero :D:D
e bella traduzione che gli hai fatto :asd:
aveva il dubbio su design.. e tu glielo traduci.... DESIGN :D
vero :D:D
variabilepippo
05-02-2008, 13:55
design grafico o design come progettazione software?
__________________
In quel contesto "design" sta per progettazione, non per "design grafico"... :)
__________________
In quel contesto "design" sta per progettazione, non per "design grafico"... :)
banryu79
05-02-2008, 13:56
La progettazione è una fase importante e delicata; imho non bisogna mai estremizzare ne generalizzare la questione in entrambi i sensi: il tempo effettivo corrisponde a quello necessario per capire e definire il dominio del problema in questione.
Sono d'accordo che esagerare è controproducente, ma neanche dedicarci troppo poco tempo è salutare :D
Sono d'accordo che esagerare è controproducente, ma neanche dedicarci troppo poco tempo è salutare :D
NeoNum6
05-02-2008, 14:03
bhè la via di mezzo è spesso la migliore...però provate a pensare a progetti da milioni di righe di codice...senza progettazione è finita!
fek
05-02-2008, 14:09
Sostanzialmente sono d'accordo con il senso generale dell'affermazione...
Forse 30 minuti però è un pò troppo estremizzato :asd:
Vero, 30 minuti sono troppi, abbasserei a 10.
:asd:
e bella traduzione che gli hai fatto :asd:
aveva il dubbio su design.. e tu glielo traduci.... DESIGN :D
Sto dimenticando l'italiano :(
Forse 30 minuti però è un pò troppo estremizzato :asd:
Vero, 30 minuti sono troppi, abbasserei a 10.
:asd:
e bella traduzione che gli hai fatto :asd:
aveva il dubbio su design.. e tu glielo traduci.... DESIGN :D
Sto dimenticando l'italiano :(
fek
05-02-2008, 14:12
io non sono d'accordo...la progettazione è importante...sopratutto per progetti grandi...inoltre la progettazione non deve finire mai, con questo si risolvono i problemi di cambiamento di progetto repentini...vedi extreme programming
Vedi, quella frase e' estremamente sintetica e ben congeniata. Infatti non afferma che la progettazione e' inutile, ma afferma che un lungo sforzo continuativo e' inutile. Senza scrivere codice.
Gunnerson non ti sta dicendo di non progettare il software, ti sta dicendo di non smettere mai di progettarlo, progetta il codice mentre lo scrivi.
Vedi, quella frase e' estremamente sintetica e ben congeniata. Infatti non afferma che la progettazione e' inutile, ma afferma che un lungo sforzo continuativo e' inutile. Senza scrivere codice.
Gunnerson non ti sta dicendo di non progettare il software, ti sta dicendo di non smettere mai di progettarlo, progetta il codice mentre lo scrivi.
NeoNum6
05-02-2008, 14:30
Vedi, quella frase e' estremamente sintetica e ben congeniata. Infatti non afferma che la progettazione e' inutile, ma afferma che un lungo sforzo continuativo e' inutile. Senza scrivere codice.
Gunnerson non ti sta dicendo di non progettare il software, ti sta dicendo di non smettere mai di progettarlo, progetta il codice mentre lo scrivi.
ottimo questa interpretazione mi piace....hai ragione...ed in effetti è geniale...non ci avevo pensato!
Gunnerson non ti sta dicendo di non progettare il software, ti sta dicendo di non smettere mai di progettarlo, progetta il codice mentre lo scrivi.
ottimo questa interpretazione mi piace....hai ragione...ed in effetti è geniale...non ci avevo pensato!
fek
05-02-2008, 17:51
ottimo questa interpretazione mi piace....hai ragione...ed in effetti è geniale...non ci avevo pensato!
Ed il prossimo passo e' questo:
http://martinfowler.com/articles/designDead.html
Ed il prossimo passo e' questo:
http://martinfowler.com/articles/designDead.html
NeoNum6
05-02-2008, 18:59
Ed il prossimo passo e' questo:
http://martinfowler.com/articles/designDead.html
bhè Xp potrebbe portarci a una nuova crisi del software se si va di questo passo...ne risentono documentazione,riuso...e gli sviluppatori!
http://martinfowler.com/articles/designDead.html
bhè Xp potrebbe portarci a una nuova crisi del software se si va di questo passo...ne risentono documentazione,riuso...e gli sviluppatori!
fek
05-02-2008, 19:49
bhè Xp potrebbe portarci a una nuova crisi del software se si va di questo passo...ne risentono documentazione,riuso...e gli sviluppatori!
Oppure si riesce finalmente a consegnare in tempo software che funziona, senza dover passare serate in ufficio :)
Oppure si riesce finalmente a consegnare in tempo software che funziona, senza dover passare serate in ufficio :)
NeoNum6
05-02-2008, 21:21
Oppure si riesce finalmente a consegnare in tempo software che funziona, senza dover passare serate in ufficio :)
ma perchè le software house non usano Xp?e come progettano?
ma perchè le software house non usano Xp?e come progettano?
cionci
05-02-2008, 22:24
Probabilmente è vero che con XP ne risente il riuso...ma anche no...mi viene in mente una feature che avevo già fatto simile in un altro progetto ? La prendo con la sua test base e poi la adatto ai miei scopi. Tutto bello, perché sposta il riuso da un livello più alto (prendo un package, lo uso inalterato in un altro progetto) ad uno più basso (prendo un package, lo modifico per adattarlo ai miei scopi).
Ora però la fase di adattamento non si può chiamare refactoring...perché in teoria il refactoring dovrebbe mantenere inalterato il comportamento del sistema ai fini esterni.
Come lo si potrebbe chiamare ? Come posso strutturare questa fase di transizione a livello di TDD e di XP ?
Ora però la fase di adattamento non si può chiamare refactoring...perché in teoria il refactoring dovrebbe mantenere inalterato il comportamento del sistema ai fini esterni.
Come lo si potrebbe chiamare ? Come posso strutturare questa fase di transizione a livello di TDD e di XP ?
D3stroyer
05-02-2008, 23:04
ora non so bene, ma non mi pare molto "economico" progettare mentre si scrive, se si parla di cose piu' grandi dell'hello world.
marco.r
05-02-2008, 23:05
Vero, 30 minuti sono troppi, abbasserei a 10.
Uhm, dipende quanto intensi sono... noi le sessioni cosi' le facciamo molto rilassate e ogni tanto spunta il barattolone da 5kg di nutella (deve averlo portato Eta Beta, non finisce mai) o, come in questo periodo, qualche frittella, per cui bisogna tenere conto dei tempi morti :D.
Io comunque sarei di quelli che si butterebbero abbastanza presto sul codice, per capire come le cose vanno a parare, per cui alla fin fine son d'accordo. I miei colleghi un po' meno, ed e' una lotta :p.
Del link che hai riportato, mi piace molto la seguente:
if you listen to your code a good design will appear.
come non essere d'accordo ?
Uhm, dipende quanto intensi sono... noi le sessioni cosi' le facciamo molto rilassate e ogni tanto spunta il barattolone da 5kg di nutella (deve averlo portato Eta Beta, non finisce mai) o, come in questo periodo, qualche frittella, per cui bisogna tenere conto dei tempi morti :D.
Io comunque sarei di quelli che si butterebbero abbastanza presto sul codice, per capire come le cose vanno a parare, per cui alla fin fine son d'accordo. I miei colleghi un po' meno, ed e' una lotta :p.
Del link che hai riportato, mi piace molto la seguente:
if you listen to your code a good design will appear.
come non essere d'accordo ?
fek
05-02-2008, 23:49
ora non so bene, ma non mi pare molto "economico" progettare mentre si scrive, se si parla di cose piu' grandi dell'hello world.
E' vero l'esatto contrario :)
Se c'e' da scrivere qualcosa di piu' di un Hello World, pensare di fare un design economico up front e' paragonabile all'utopia.
E' vero l'esatto contrario :)
Se c'e' da scrivere qualcosa di piu' di un Hello World, pensare di fare un design economico up front e' paragonabile all'utopia.
banryu79
06-02-2008, 00:09
Vedi, quella frase e' estremamente sintetica e ben congeniata. Infatti non afferma che la progettazione e' inutile, ma afferma che un lungo sforzo continuativo e' inutile. Senza scrivere codice.
Gunnerson non ti sta dicendo di non progettare il software, ti sta dicendo di non smettere mai di progettarlo, progetta il codice mentre lo scrivi.
Ora ho capito il senso, ho dato un'occhiata anche al link postato, domani in pausa pranzo me lo leggo ben bene...
Non ho mai lavorato su progetti di grandi dimensioni (quelli di milioni di righe di codice), e mi viene spontaneo chiedervi, a chi ha esperienze in merito, ma l'XP funge bene anche su questi colossi?
Immagino che comunque rimangano qua e là sprazzi di design "più tradizionale"...
Però l'idea dell'XP mi piace, la vedo come una cosa molto naturale il fatto che il codice muti man mano che lo si scrive, e muti così profondamente tanto da dare forma in itinere anche a quello che il design rappresenta (o tenta di rappresentare).
Non parlo per esperienza, ma solo perchè il concetto mi affascina: è una vecchia storia infatti che i tentativi di rappresentare o catturare la realtà/verità mediante sistemi che codifichino, stabiliscano a priori (e con l'inerzia e il passare del tempo diventino poi considerati "tradizionali") delle regole siano destinati a non arrivarci mai a pieno, perchè la realtà (o la verità) è sempre in movimento, o meglio non si può pretendere di prenderla tutta catturandone solo una parte, in un dato momento.
l'XP programmimg si "accosta meglio", per così dire, alla natura del codice in fase di scrittura: il cambiamento.
Lo fa con quella cosa che chiamiamo refactoring (oltre al resto)
P.S.: tranquilli non ho fumato pesante, sarà l'ora tarda :D
Gunnerson non ti sta dicendo di non progettare il software, ti sta dicendo di non smettere mai di progettarlo, progetta il codice mentre lo scrivi.
Ora ho capito il senso, ho dato un'occhiata anche al link postato, domani in pausa pranzo me lo leggo ben bene...
Non ho mai lavorato su progetti di grandi dimensioni (quelli di milioni di righe di codice), e mi viene spontaneo chiedervi, a chi ha esperienze in merito, ma l'XP funge bene anche su questi colossi?
Immagino che comunque rimangano qua e là sprazzi di design "più tradizionale"...
Però l'idea dell'XP mi piace, la vedo come una cosa molto naturale il fatto che il codice muti man mano che lo si scrive, e muti così profondamente tanto da dare forma in itinere anche a quello che il design rappresenta (o tenta di rappresentare).
Non parlo per esperienza, ma solo perchè il concetto mi affascina: è una vecchia storia infatti che i tentativi di rappresentare o catturare la realtà/verità mediante sistemi che codifichino, stabiliscano a priori (e con l'inerzia e il passare del tempo diventino poi considerati "tradizionali") delle regole siano destinati a non arrivarci mai a pieno, perchè la realtà (o la verità) è sempre in movimento, o meglio non si può pretendere di prenderla tutta catturandone solo una parte, in un dato momento.
l'XP programmimg si "accosta meglio", per così dire, alla natura del codice in fase di scrittura: il cambiamento.
Lo fa con quella cosa che chiamiamo refactoring (oltre al resto)
P.S.: tranquilli non ho fumato pesante, sarà l'ora tarda :D
cionci
06-02-2008, 07:56
ora non so bene, ma non mi pare molto "economico" progettare mentre si scrive, se si parla di cose piu' grandi dell'hello world.
Dipende da tante cose. Se tutto è organizzato bene è più economico.
Progettare prima tutto il software rende il risultato solitamente pachidermico perché in fase di progettazione si tende sempre ad esagerare, si tende a prevedere usi futuri, si tende a pensare non a ciò che deve fare, ma a ciò che potrebbe fare il nostro software.
Imho se il progetto è grande qualche use case e sequence diagram serve sempre, visto che è sempre utile per far capire a tutti cosa si vuole realizzare, anche senza che siano vincolanti.
Se invece si va nel dettagli (vedi Class Diagram) si tenderà sempre a non tenere conto delle reali esigenze del nostro programma e si arriverà ad ottenere quasi sempre un design overingegnerizzato.
Qualsiasi cambiamento alla struttura del progetto dovrà passare dall'approvazione del progettista e visto che in fase di progettazione non si può tenere conto di problemi realizzativi che vengono fuori solo in fase di implementazione, vuol dire andare avanti e indietro tra fase di implementazione e di progettazione decine se non centinaia di volte, magari con stravolgimenti del progetto che portano via moooooltisssimo tempo.
Quindi alla fine il design viene comunque evoluto, ma ogni evoluzione porta via un tempo superiore di decine di volte a quello che porterebbe via in un design evolutivo. Senza contare le difficoltà di comunicazione che spesso ci sono fra chi progetta e chi implementa, visto che i primi spesso non sono a contatto diretto con il problema.
Dipende da tante cose. Se tutto è organizzato bene è più economico.
Progettare prima tutto il software rende il risultato solitamente pachidermico perché in fase di progettazione si tende sempre ad esagerare, si tende a prevedere usi futuri, si tende a pensare non a ciò che deve fare, ma a ciò che potrebbe fare il nostro software.
Imho se il progetto è grande qualche use case e sequence diagram serve sempre, visto che è sempre utile per far capire a tutti cosa si vuole realizzare, anche senza che siano vincolanti.
Se invece si va nel dettagli (vedi Class Diagram) si tenderà sempre a non tenere conto delle reali esigenze del nostro programma e si arriverà ad ottenere quasi sempre un design overingegnerizzato.
Qualsiasi cambiamento alla struttura del progetto dovrà passare dall'approvazione del progettista e visto che in fase di progettazione non si può tenere conto di problemi realizzativi che vengono fuori solo in fase di implementazione, vuol dire andare avanti e indietro tra fase di implementazione e di progettazione decine se non centinaia di volte, magari con stravolgimenti del progetto che portano via moooooltisssimo tempo.
Quindi alla fine il design viene comunque evoluto, ma ogni evoluzione porta via un tempo superiore di decine di volte a quello che porterebbe via in un design evolutivo. Senza contare le difficoltà di comunicazione che spesso ci sono fra chi progetta e chi implementa, visto che i primi spesso non sono a contatto diretto con il problema.
NeoNum6
06-02-2008, 08:55
in genere la via migliore sia (nel caso di milioni di righe) scomporre il progetto in sottoprogetti e dare a ognuno il tipo di design che più gli si addice...Xp ha i suoi difetti...così come le programmazioni evolute...
^TiGeRShArK^
06-02-2008, 09:12
Ora ho capito il senso, ho dato un'occhiata anche al link postato, domani in pausa pranzo me lo leggo ben bene...
Non ho mai lavorato su progetti di grandi dimensioni (quelli di milioni di righe di codice), e mi viene spontaneo chiedervi, a chi ha esperienze in merito, ma l'XP funge bene anche su questi colossi?
Immagino che comunque rimangano qua e là sprazzi di design "più tradizionale"...
Però l'idea dell'XP mi piace, la vedo come una cosa molto naturale il fatto che il codice muti man mano che lo si scrive, e muti così profondamente tanto da dare forma in itinere anche a quello che il design rappresenta (o tenta di rappresentare).
Non parlo per esperienza, ma solo perchè il concetto mi affascina: è una vecchia storia infatti che i tentativi di rappresentare o catturare la realtà/verità mediante sistemi che codifichino, stabiliscano a priori (e con l'inerzia e il passare del tempo diventino poi considerati "tradizionali") delle regole siano destinati a non arrivarci mai a pieno, perchè la realtà (o la verità) è sempre in movimento, o meglio non si può pretendere di prenderla tutta catturandone solo una parte, in un dato momento.
l'XP programmimg si "accosta meglio", per così dire, alla natura del codice in fase di scrittura: il cambiamento.
Lo fa con quella cosa che chiamiamo refactoring (oltre al resto)
P.S.: tranquilli non ho fumato pesante, sarà l'ora tarda :D
...io ho lavorato su due progetti che erano intorno al milione di LOC...
Ma lì non veniva usato ASSOLUTAMENTE l'XP..
anzi.. a dirla tutta veniva anche applicata (soprattutto nel progetto + piccolo) una versione MOLTO discutibile dell'OO (praticamente programmazione procedurale con le classi e una spruzzata di ereditarietà proprio quando non serve a nulla). :muro:
IMHO l'XP avrebbe aiutato moltissimo...
Nel progetto + grande, quantomeno avevamo gli unit test... altrimenti sarebbe stato tutto da buttare e riscrivere dato che appena si cambiava una riga di codice iniziavano a fallire un centinaio di test :muro:
..Quindi per la mia limitata esperienza, dopo aver visto i risultati del non utilizzo della XP, credo che, se applicato correttamente, le techinche di extreme programming possano aiutare molto, *soprattutto* in progetti di grandi dimensioni.
..dimenticavo..
C'erano alcune classi generate che dovevano essere sdoppiate in 5 o 6 file a causa del limite di java di 65536 byte per la signature dei metodi per classe :cry:
Non ho mai lavorato su progetti di grandi dimensioni (quelli di milioni di righe di codice), e mi viene spontaneo chiedervi, a chi ha esperienze in merito, ma l'XP funge bene anche su questi colossi?
Immagino che comunque rimangano qua e là sprazzi di design "più tradizionale"...
Però l'idea dell'XP mi piace, la vedo come una cosa molto naturale il fatto che il codice muti man mano che lo si scrive, e muti così profondamente tanto da dare forma in itinere anche a quello che il design rappresenta (o tenta di rappresentare).
Non parlo per esperienza, ma solo perchè il concetto mi affascina: è una vecchia storia infatti che i tentativi di rappresentare o catturare la realtà/verità mediante sistemi che codifichino, stabiliscano a priori (e con l'inerzia e il passare del tempo diventino poi considerati "tradizionali") delle regole siano destinati a non arrivarci mai a pieno, perchè la realtà (o la verità) è sempre in movimento, o meglio non si può pretendere di prenderla tutta catturandone solo una parte, in un dato momento.
l'XP programmimg si "accosta meglio", per così dire, alla natura del codice in fase di scrittura: il cambiamento.
Lo fa con quella cosa che chiamiamo refactoring (oltre al resto)
P.S.: tranquilli non ho fumato pesante, sarà l'ora tarda :D
...io ho lavorato su due progetti che erano intorno al milione di LOC...
Ma lì non veniva usato ASSOLUTAMENTE l'XP..
anzi.. a dirla tutta veniva anche applicata (soprattutto nel progetto + piccolo) una versione MOLTO discutibile dell'OO (praticamente programmazione procedurale con le classi e una spruzzata di ereditarietà proprio quando non serve a nulla). :muro:
IMHO l'XP avrebbe aiutato moltissimo...
Nel progetto + grande, quantomeno avevamo gli unit test... altrimenti sarebbe stato tutto da buttare e riscrivere dato che appena si cambiava una riga di codice iniziavano a fallire un centinaio di test :muro:
..Quindi per la mia limitata esperienza, dopo aver visto i risultati del non utilizzo della XP, credo che, se applicato correttamente, le techinche di extreme programming possano aiutare molto, *soprattutto* in progetti di grandi dimensioni.
..dimenticavo..
C'erano alcune classi generate che dovevano essere sdoppiate in 5 o 6 file a causa del limite di java di 65536 byte per la signature dei metodi per classe :cry:
thebol
06-02-2008, 09:20
ora non so bene, ma non mi pare molto "economico" progettare mentre si scrive, se si parla di cose piu' grandi dell'hello world.
non è economico per gli analisti che fanno word programming(e per questo prendono x €), e poi passano il tomo ai poveri sviluppatori che si devono leggere tonnellate di righe, scelte funzionali fatte alla lavagna, scelte tecniche e di design fatte alla lavagna, e in generale predizioni sul futuro. Che si rilevano quando va bene inutili. Quando va meno bene inesatte. E quando va male completamente sbagliate. E lo sviluppatore prende x/3€ e viene infamato perchè arriva in ritardo con le consegne, nonostante (!) l'analisi.
non è economico per gli analisti che fanno word programming(e per questo prendono x €), e poi passano il tomo ai poveri sviluppatori che si devono leggere tonnellate di righe, scelte funzionali fatte alla lavagna, scelte tecniche e di design fatte alla lavagna, e in generale predizioni sul futuro. Che si rilevano quando va bene inutili. Quando va meno bene inesatte. E quando va male completamente sbagliate. E lo sviluppatore prende x/3€ e viene infamato perchè arriva in ritardo con le consegne, nonostante (!) l'analisi.
^TiGeRShArK^
06-02-2008, 09:53
E lo sviluppatore prende x/3€ e viene infamato perchè arriva in ritardo con le consegne, nonostante (!) l'analisi.
:asd:
:asd:
AnonimoVeneziano
06-02-2008, 10:11
C'erano alcune classi generate che dovevano essere sdoppiate in 5 o 6 file a causa del limite di java di 65536 byte per la signature dei metodi per classe :cry:
:eek:
E pensare che se io faccio un metodo di più di 50 righe mi sento in colpa .... :nono:
:eek:
E pensare che se io faccio un metodo di più di 50 righe mi sento in colpa .... :nono:
RaouL_BennetH
06-02-2008, 12:27
Mi intrometto in questa interessante discussione.
Solo per citare la mia piccola esperienza personale, quello che dice fek io mi ritrovo a farlo naturalmente. Mi spiego:
Quando devo fare uno dei miei piccoli programmini, non penso mai al risultato finale, ma mi limito a cercare di risolvere il piccolo problema del momento.
La cosa buffa è che attribuivo questo mio modo di fare, alla mia ignoranza in materia. Spesso infatti mi vergogno letteralmente di aprire anche alcuni post per cercare di spiegare i problemi che incontro :(
Leggere invece che come modo di fare, può essere anche corretto, mi ha allietato la giornata :)
RaouL.
Solo per citare la mia piccola esperienza personale, quello che dice fek io mi ritrovo a farlo naturalmente. Mi spiego:
Quando devo fare uno dei miei piccoli programmini, non penso mai al risultato finale, ma mi limito a cercare di risolvere il piccolo problema del momento.
La cosa buffa è che attribuivo questo mio modo di fare, alla mia ignoranza in materia. Spesso infatti mi vergogno letteralmente di aprire anche alcuni post per cercare di spiegare i problemi che incontro :(
Leggere invece che come modo di fare, può essere anche corretto, mi ha allietato la giornata :)
RaouL.
fek
06-02-2008, 12:54
Non ho mai lavorato su progetti di grandi dimensioni (quelli di milioni di righe di codice), e mi viene spontaneo chiedervi, a chi ha esperienze in merito, ma l'XP funge bene anche su questi colossi?
Immagino che comunque rimangano qua e là sprazzi di design "più tradizionale"...
Purtroppo la game industry e' molto reazionaria e non ho mai lavorato su un progetto da milioni di righe di codice scritto in maniera agile.
Pero' ho lavorato a diversi progetti da milioni di righe di codice senza un solo test, dove spesso e volentieri richiedevano oppure imponevano i Technical Design Documento, ovvero documenti di design con diagrammi delle classi per documentare la soluzione a un problema non ancora ... risolto. Ancora piu' spesso quel problema non era stato ancora risolto da nessuno al mondo, oppure da molto pochi ci avevano provato.
Posso definire questa esperienza come qualcosa di vicino ad un incubo :)
Rifattorizzare o mettere mano a codice che puo' avere (anzi ha sempre) knock-on su decine di altri sistemi, spesso in maniera oscura, non e' una passeggiata.
Ancora meno era mantenere, debuggare e testare sistemi che dovevo scrivere per cercare di prevedere qualunque cosa andasse storto: c'era sempre qualcosa che andava storto comunque ed avevo scritto mediamente dieci volte il codice che mi sarebbe servito.
E poi c'e' sempre Peter o chi per lui che arriva e chiede di cambiare qualcosa :)
Ho smesso. In Fable 2 ho sempre e solo scritto quello che mi serviva per risolvere il problema che avevo di fronte e non una riga. Ancora senza test, purtroppo, ma la mia produttivita' si e' alzata di molto, il numero di bug si e' abbassato di molto, ho scritto molto meno codice e molte piu' funzionalita'. Non ho perso a scrivere uno straccio di documento, ma il mio codice e' fortunatemente riconosciuto come fra i piu' leggibili, semplici e ben progettati.
Mi sono attirato qualche antipatia predicando semplicita', ma YAGNI mi ha accompagnato per tutto lo sviluppo.
Immagino che comunque rimangano qua e là sprazzi di design "più tradizionale"...
Purtroppo la game industry e' molto reazionaria e non ho mai lavorato su un progetto da milioni di righe di codice scritto in maniera agile.
Pero' ho lavorato a diversi progetti da milioni di righe di codice senza un solo test, dove spesso e volentieri richiedevano oppure imponevano i Technical Design Documento, ovvero documenti di design con diagrammi delle classi per documentare la soluzione a un problema non ancora ... risolto. Ancora piu' spesso quel problema non era stato ancora risolto da nessuno al mondo, oppure da molto pochi ci avevano provato.
Posso definire questa esperienza come qualcosa di vicino ad un incubo :)
Rifattorizzare o mettere mano a codice che puo' avere (anzi ha sempre) knock-on su decine di altri sistemi, spesso in maniera oscura, non e' una passeggiata.
Ancora meno era mantenere, debuggare e testare sistemi che dovevo scrivere per cercare di prevedere qualunque cosa andasse storto: c'era sempre qualcosa che andava storto comunque ed avevo scritto mediamente dieci volte il codice che mi sarebbe servito.
E poi c'e' sempre Peter o chi per lui che arriva e chiede di cambiare qualcosa :)
Ho smesso. In Fable 2 ho sempre e solo scritto quello che mi serviva per risolvere il problema che avevo di fronte e non una riga. Ancora senza test, purtroppo, ma la mia produttivita' si e' alzata di molto, il numero di bug si e' abbassato di molto, ho scritto molto meno codice e molte piu' funzionalita'. Non ho perso a scrivere uno straccio di documento, ma il mio codice e' fortunatemente riconosciuto come fra i piu' leggibili, semplici e ben progettati.
Mi sono attirato qualche antipatia predicando semplicita', ma YAGNI mi ha accompagnato per tutto lo sviluppo.
fek
06-02-2008, 12:58
non è economico per gli analisti che fanno word programming(e per questo prendono x €), e poi passano il tomo ai poveri sviluppatori che si devono leggere tonnellate di righe, scelte funzionali fatte alla lavagna, scelte tecniche e di design fatte alla lavagna, e in generale predizioni sul futuro. Che si rilevano quando va bene inutili. Quando va meno bene inesatte. E quando va male completamente sbagliate. E lo sviluppatore prende x/3€ e viene infamato perchè arriva in ritardo con le consegne, nonostante (!) l'analisi.
Le soluzioni possibili sono due:
1- Andare a lavorare in un'azienda che sa scrivere software
2- Ignorare il design, e scriversi la prossima soluzione in maniera evolutiva :)
Le soluzioni possibili sono due:
1- Andare a lavorare in un'azienda che sa scrivere software
2- Ignorare il design, e scriversi la prossima soluzione in maniera evolutiva :)
tomminno
06-02-2008, 13:13
Vedi, quella frase e' estremamente sintetica e ben congeniata. Infatti non afferma che la progettazione e' inutile, ma afferma che un lungo sforzo continuativo e' inutile. Senza scrivere codice.
Gunnerson non ti sta dicendo di non progettare il software, ti sta dicendo di non smettere mai di progettarlo, progetta il codice mentre lo scrivi.
Boh a me sembra che uno che afferma cose simili non abbia mai dovuto ristrutturare o fare modifiche a sistemi complessi (che non significa necessariamente un software da milioni di righe, ma un qualcosa che magari coinvolge decine e decine di software pure di piccola entità, tra cui script e webservice, database).
Che codice scrivi?
Quale vbs, query, stored procedure, vista, software vai a modificare?
Dove trovi (nei repository aziendali) quel software?
Quale metodo di quel software devi andare a modificare?
Che effetti hanno le modifiche sul funzionamento attuale del singolo software e del sistema più in generale?
Vale la pena fare le modifiche oppure ti costano di più dei benefici che apportano?
Assurdo pensare di poter mettere mano ad un sistema complesso e considerare tutti i danni/vantaggi che una modifica può apportare in meno di 30 minuti
Gunnerson non ti sta dicendo di non progettare il software, ti sta dicendo di non smettere mai di progettarlo, progetta il codice mentre lo scrivi.
Boh a me sembra che uno che afferma cose simili non abbia mai dovuto ristrutturare o fare modifiche a sistemi complessi (che non significa necessariamente un software da milioni di righe, ma un qualcosa che magari coinvolge decine e decine di software pure di piccola entità, tra cui script e webservice, database).
Che codice scrivi?
Quale vbs, query, stored procedure, vista, software vai a modificare?
Dove trovi (nei repository aziendali) quel software?
Quale metodo di quel software devi andare a modificare?
Che effetti hanno le modifiche sul funzionamento attuale del singolo software e del sistema più in generale?
Vale la pena fare le modifiche oppure ti costano di più dei benefici che apportano?
Assurdo pensare di poter mettere mano ad un sistema complesso e considerare tutti i danni/vantaggi che una modifica può apportare in meno di 30 minuti
fek
06-02-2008, 13:24
Boh a me sembra che uno che afferma cose simili non abbia mai dovuto ristrutturare o fare modifiche a sistemi complessi (che non significa necessariamente un software da milioni di righe, ma un qualcosa che magari coinvolge decine e decine di software pure di piccola entità, tra cui script e webservice, database).
Ho fatto io quelll'affermazione.
Fable 2 al momento annovera 150 programmatori, 5mln di LOC per la sola code base del gioco escludendo i tool. Si appoggia a cinque librerie third-party, usa circa 30 tool che si appoggiano ad un databse relazionale scritto in house. Usa l'infrastruttura di rete di Xbox Live. Gestisce circa 50gb di dati grezzi. L'engine deve girare a 30hz sempre, in qualunque condizione.
Ti sembra abbastanza complesso? :)
Ho fatto io quelll'affermazione.
Fable 2 al momento annovera 150 programmatori, 5mln di LOC per la sola code base del gioco escludendo i tool. Si appoggia a cinque librerie third-party, usa circa 30 tool che si appoggiano ad un databse relazionale scritto in house. Usa l'infrastruttura di rete di Xbox Live. Gestisce circa 50gb di dati grezzi. L'engine deve girare a 30hz sempre, in qualunque condizione.
Ti sembra abbastanza complesso? :)
thebol
06-02-2008, 13:28
Ho fatto io quelll'affermazione.
Fable 2 al momento annovera 150 programmatori, 5mln di LOC per la sola code base del gioco escludendo i tool. Si appoggia a cinque librerie third-party, usa circa 30 tool che si appoggiano ad un databse relazionale scritto in house. Usa l'infrastruttura di rete di Xbox Live. Gestisce circa 50gb di dati grezzi. L'engine deve girare a 30hz sempre, in qualunque condizione.
Ti sembra abbastanza complesso? :)
un database relazionale scritto in house? Il primo db per XBox360 :asd: ?
Fable 2 al momento annovera 150 programmatori, 5mln di LOC per la sola code base del gioco escludendo i tool. Si appoggia a cinque librerie third-party, usa circa 30 tool che si appoggiano ad un databse relazionale scritto in house. Usa l'infrastruttura di rete di Xbox Live. Gestisce circa 50gb di dati grezzi. L'engine deve girare a 30hz sempre, in qualunque condizione.
Ti sembra abbastanza complesso? :)
un database relazionale scritto in house? Il primo db per XBox360 :asd: ?
^TiGeRShArK^
06-02-2008, 13:29
Ho fatto io quelll'affermazione.
Fable 2 al momento annovera 150 programmatori, 5mln di LOC per la sola code base del gioco escludendo i tool. Si appoggia a cinque librerie third-party, usa circa 30 tool che si appoggiano ad un databse relazionale scritto in house. Usa l'infrastruttura di rete di Xbox Live. Gestisce circa 50gb di dati grezzi. L'engine deve girare a 30hz sempre, in qualunque condizione.
Ti sembra abbastanza complesso? :)
infatti anche nei miei due "progettini" c'erano interfacce verso la qualunque (sistemi gestionali legacy, database ad oggetti, Oracle, sistema di controllo del nastro nel magazzino, interfacce verso SAP, verso il reporting e almeno una media di una decina di altre interfacce varie per cliente), e ribadisco e confermo quanto espresso prima.
Utilizzare un approccio di tipo XP avrebbe risolto MOLTI problemi.
Fable 2 al momento annovera 150 programmatori, 5mln di LOC per la sola code base del gioco escludendo i tool. Si appoggia a cinque librerie third-party, usa circa 30 tool che si appoggiano ad un databse relazionale scritto in house. Usa l'infrastruttura di rete di Xbox Live. Gestisce circa 50gb di dati grezzi. L'engine deve girare a 30hz sempre, in qualunque condizione.
Ti sembra abbastanza complesso? :)
infatti anche nei miei due "progettini" c'erano interfacce verso la qualunque (sistemi gestionali legacy, database ad oggetti, Oracle, sistema di controllo del nastro nel magazzino, interfacce verso SAP, verso il reporting e almeno una media di una decina di altre interfacce varie per cliente), e ribadisco e confermo quanto espresso prima.
Utilizzare un approccio di tipo XP avrebbe risolto MOLTI problemi.
^TiGeRShArK^
06-02-2008, 13:30
un database relazionale scritto in house? Il primo db per XBox360 :asd: ?
sempre meglio del database ad oggetti che usavamo che quando superava i 100GB iniziava a crashare in maniera random in produzione :asd:
sempre meglio del database ad oggetti che usavamo che quando superava i 100GB iniziava a crashare in maniera random in produzione :asd:
fek
06-02-2008, 13:36
un database relazionale scritto in house? Il primo db per XBox360 :asd: ?
No, serve per il build degli asset :)
Ormai la maggior parte del codice non si scrive piu' nel gioco, ma in tutti i tool di supporto.
No, serve per il build degli asset :)
Ormai la maggior parte del codice non si scrive piu' nel gioco, ma in tutti i tool di supporto.
thebol
06-02-2008, 13:41
No, serve per il build degli asset :)
Ormai la maggior parte del codice non si scrive piu' nel gioco, ma in tutti i tool di supporto.
questa storia degli asset, te lo gia sentita nominare...puoi spiegare meglio cosa intendi?
è tipo un sistema in cui si suddividono i compiti, ad esempio chi gestisce il motore fisico scrive il software da una parte, quello che scrive l'ai di un personaggio da un altra parte etc etc etc e poi la notte parte la build che mette assieme tutto?
Ormai la maggior parte del codice non si scrive piu' nel gioco, ma in tutti i tool di supporto.
questa storia degli asset, te lo gia sentita nominare...puoi spiegare meglio cosa intendi?
è tipo un sistema in cui si suddividono i compiti, ad esempio chi gestisce il motore fisico scrive il software da una parte, quello che scrive l'ai di un personaggio da un altra parte etc etc etc e poi la notte parte la build che mette assieme tutto?
fek
06-02-2008, 13:50
questa storia degli asset, te lo gia sentita nominare...puoi spiegare meglio cosa intendi?
è tipo un sistema in cui si suddividono i compiti, ad esempio chi gestisce il motore fisico scrive il software da una parte, quello che scrive l'ai di un personaggio da un altra parte etc etc etc e poi la notte parte la build che mette assieme tutto?
No no. Gli asset di un gioco sono i dati: modelli, texture, animazioni, suoni, livelli, etc etc. Ogni asset dipende da altri, ad esempio un modello dipende dalle sue texture, un livello dai modelli contenuti. Serve tutto un sistema (per altro estremamente complesso), che capisca che cosa e' stato modificando in dipendenza da che cos'altro e trasformi solo gli asset modificati dalla versione RAW prodotta dall'artista ad una versione compilata usabile dall'engine 3d. E deve essere anche tremendamente veloce perche' e' il singolo sistema che fa la differenza fra un buon gioco e uno brutto, perche' impatta enormemente il work flow e i tempi di sviluppo.
è tipo un sistema in cui si suddividono i compiti, ad esempio chi gestisce il motore fisico scrive il software da una parte, quello che scrive l'ai di un personaggio da un altra parte etc etc etc e poi la notte parte la build che mette assieme tutto?
No no. Gli asset di un gioco sono i dati: modelli, texture, animazioni, suoni, livelli, etc etc. Ogni asset dipende da altri, ad esempio un modello dipende dalle sue texture, un livello dai modelli contenuti. Serve tutto un sistema (per altro estremamente complesso), che capisca che cosa e' stato modificando in dipendenza da che cos'altro e trasformi solo gli asset modificati dalla versione RAW prodotta dall'artista ad una versione compilata usabile dall'engine 3d. E deve essere anche tremendamente veloce perche' e' il singolo sistema che fa la differenza fra un buon gioco e uno brutto, perche' impatta enormemente il work flow e i tempi di sviluppo.
tomminno
06-02-2008, 15:07
Ho fatto io quelll'affermazione.
Fable 2 al momento annovera 150 programmatori, 5mln di LOC per la sola code base del gioco escludendo i tool. Si appoggia a cinque librerie third-party, usa circa 30 tool che si appoggiano ad un databse relazionale scritto in house. Usa l'infrastruttura di rete di Xbox Live. Gestisce circa 50gb di dati grezzi. L'engine deve girare a 30hz sempre, in qualunque condizione.
Ti sembra abbastanza complesso? :)
Beh sei fortunato che non hai tutto in casa, quindi non saresti comunque in grado di mettere mano all'intero sistema.
Sapresti in meno di mezz'ora capire dove e come modificare il sistema se fosse richiesto il supporto ad un nuovo e diverso formato raw, o a cambiare le interdipendenze tra i vari asset del gioco se questo fosse richiesto?
Sapresti in meno di mezz'ora individuare tutte le librerie coinvolte, trovare tutti i metodi coinvolti capire cosa e come modificare?
Sapresti valutare in meno di mezz'ora se merita (economicamente e funzionalmente) attuare la modifica o meno?
Fable 2 al momento annovera 150 programmatori, 5mln di LOC per la sola code base del gioco escludendo i tool. Si appoggia a cinque librerie third-party, usa circa 30 tool che si appoggiano ad un databse relazionale scritto in house. Usa l'infrastruttura di rete di Xbox Live. Gestisce circa 50gb di dati grezzi. L'engine deve girare a 30hz sempre, in qualunque condizione.
Ti sembra abbastanza complesso? :)
Beh sei fortunato che non hai tutto in casa, quindi non saresti comunque in grado di mettere mano all'intero sistema.
Sapresti in meno di mezz'ora capire dove e come modificare il sistema se fosse richiesto il supporto ad un nuovo e diverso formato raw, o a cambiare le interdipendenze tra i vari asset del gioco se questo fosse richiesto?
Sapresti in meno di mezz'ora individuare tutte le librerie coinvolte, trovare tutti i metodi coinvolti capire cosa e come modificare?
Sapresti valutare in meno di mezz'ora se merita (economicamente e funzionalmente) attuare la modifica o meno?
fek
06-02-2008, 15:13
Beh sei fortunato che non hai tutto in casa, quindi non saresti comunque in grado di mettere mano all'intero sistema.
Che intendi?
Sapresti in meno di mezz'ora capire dove e come modificare il sistema se fosse richiesto il supporto ad un nuovo e diverso formato raw, o a cambiare le interdipendenze tra i vari asset del gioco se questo fosse richiesto?
Sapresti in meno di mezz'ora individuare tutte le librerie coinvolte, trovare tutti i metodi coinvolti capire cosa e come modificare?
Sapresti valutare in meno di mezz'ora se merita (economicamente e funzionalmente) attuare la modifica o meno?
No, e non sarei in grado neppure in due giorni senza mettere mano al codice. L'unico modo e' provare, perche' non c'e' modo di scrivere (e mantenere) documentazione per un sistema di tale complessita' e che, soprattutto, vede i requisiti cambiare a base giornaliera.
Semplicemente, per tale complessita', fare un design up front e' impossibile, puoi solo approcciare il problema in maniera evolutiva :)
Se provi a sederti ad un tavolo cercando di scrivere il design architetturale per un gioco di queste dimensioni, dopo due anni non hai ancora scritto una riga di codice...
Che intendi?
Sapresti in meno di mezz'ora capire dove e come modificare il sistema se fosse richiesto il supporto ad un nuovo e diverso formato raw, o a cambiare le interdipendenze tra i vari asset del gioco se questo fosse richiesto?
Sapresti in meno di mezz'ora individuare tutte le librerie coinvolte, trovare tutti i metodi coinvolti capire cosa e come modificare?
Sapresti valutare in meno di mezz'ora se merita (economicamente e funzionalmente) attuare la modifica o meno?
No, e non sarei in grado neppure in due giorni senza mettere mano al codice. L'unico modo e' provare, perche' non c'e' modo di scrivere (e mantenere) documentazione per un sistema di tale complessita' e che, soprattutto, vede i requisiti cambiare a base giornaliera.
Semplicemente, per tale complessita', fare un design up front e' impossibile, puoi solo approcciare il problema in maniera evolutiva :)
Se provi a sederti ad un tavolo cercando di scrivere il design architetturale per un gioco di queste dimensioni, dopo due anni non hai ancora scritto una riga di codice...
shinya
06-02-2008, 16:01
No, serve per il build degli asset :)
Ormai la maggior parte del codice non si scrive piu' nel gioco, ma in tutti i tool di supporto.
Non ho capito...ma avete scritto un motore db relazionale al vostro interno?
Ma perchè??!
Ormai la maggior parte del codice non si scrive piu' nel gioco, ma in tutti i tool di supporto.
Non ho capito...ma avete scritto un motore db relazionale al vostro interno?
Ma perchè??!
fek
06-02-2008, 16:03
Non ho capito...ma avete scritto un motore db relazionale al vostro interno?
Ma perchè??!
Per risolvere le dipendenze degli asset.
Ma perchè??!
Per risolvere le dipendenze degli asset.
tomminno
06-02-2008, 17:42
Che intendi?
Se devi modificare qualcosa che sta nei progetti di terze parti devi chiedere a chi ha prodotto la libreria se te la modifica, non puoi pianificare/analizzare modifiche su quelle.
No, e non sarei in grado neppure in due giorni senza mettere mano al codice. L'unico modo e' provare, perche' non c'e' modo di scrivere (e mantenere) documentazione per un sistema di tale complessita' e che, soprattutto, vede i requisiti cambiare a base giornaliera.
Semplicemente, per tale complessita', fare un design up front e' impossibile, puoi solo approcciare il problema in maniera evolutiva :)
Se provi a sederti ad un tavolo cercando di scrivere il design architetturale per un gioco di queste dimensioni, dopo due anni non hai ancora scritto una riga di codice...
Ma andresti alla cieca, dovresti scorrere tutto il codice guardare cosa fa per vedere se è da modificare.
Ho recentemente lavorato all'aggiunta di uno stato nel sistema di gestione dei domini per gestire la pubblicità di google, ho dovuto modificare almeno 10 tra console e webservice,
altrettanti vbs, così come ho dovuto mettere mano ad un sacco di Viste e Stored Procedure su diversi database posti su macchine differenti.
Tutto per la gestione di un misero numero.
Senza un documento di analisi quanti secoli mi ci sarebbero voluti a trovare tutti gli oggetti da modificare?
Avevo un documento sotto mano che diceva in questo progetto nel metodo X aggiungere la clausola Y, creare la stored Z che usi le viste H,K da modificare per la gestione del nuovo stato ecc...
Se devi modificare qualcosa che sta nei progetti di terze parti devi chiedere a chi ha prodotto la libreria se te la modifica, non puoi pianificare/analizzare modifiche su quelle.
No, e non sarei in grado neppure in due giorni senza mettere mano al codice. L'unico modo e' provare, perche' non c'e' modo di scrivere (e mantenere) documentazione per un sistema di tale complessita' e che, soprattutto, vede i requisiti cambiare a base giornaliera.
Semplicemente, per tale complessita', fare un design up front e' impossibile, puoi solo approcciare il problema in maniera evolutiva :)
Se provi a sederti ad un tavolo cercando di scrivere il design architetturale per un gioco di queste dimensioni, dopo due anni non hai ancora scritto una riga di codice...
Ma andresti alla cieca, dovresti scorrere tutto il codice guardare cosa fa per vedere se è da modificare.
Ho recentemente lavorato all'aggiunta di uno stato nel sistema di gestione dei domini per gestire la pubblicità di google, ho dovuto modificare almeno 10 tra console e webservice,
altrettanti vbs, così come ho dovuto mettere mano ad un sacco di Viste e Stored Procedure su diversi database posti su macchine differenti.
Tutto per la gestione di un misero numero.
Senza un documento di analisi quanti secoli mi ci sarebbero voluti a trovare tutti gli oggetti da modificare?
Avevo un documento sotto mano che diceva in questo progetto nel metodo X aggiungere la clausola Y, creare la stored Z che usi le viste H,K da modificare per la gestione del nuovo stato ecc...
fek
06-02-2008, 17:50
Se devi modificare qualcosa che sta nei progetti di terze parti devi chiedere a chi ha prodotto la libreria se te la modifica, non puoi pianificare/analizzare modifiche su quelle.
Sei fuori strada. L'XDK e' un prodotto di un team esterno.
Ma andresti alla cieca, dovresti scorrere tutto il codice guardare cosa fa per vedere se è da modificare.
E' vero l'esatto contrario, non mi avventuro alla cieca nel design di una soluzione che non conosco e non ho mai tentato, ma lavoro mettendo le mani nel codice e quandi facendo emergere la soluzione.
Cosa che non puoi fare con un design rigido che da una parte non ammette modifiche, dall'altra e' sbagliato perche' per ovvi motivi non puo' prevedere tutte le problematiche durante tre anni di sviluppo.
Senza un documento di analisi quanti secoli mi ci sarebbero voluti a trovare tutti gli oggetti da modificare?
Avevo un documento sotto mano che diceva in questo progetto nel metodo X aggiungere la clausola Y, creare la stored Z che usi le viste H,K da modificare per la gestione del nuovo stato ecc...
Senza spendere il tempo per scrivere quell'inutile documento e doverlo mantenere, molto probabilmente non avresti neppure dovuto fare quella modifica.
Ma comunque, hai gia' una volta creato esempi falsi per darti ragione quindi e' inutile proseguire questo discorso :)
Il punto e': pensare di creare un documento di design prima di scrivere cinque milioni di righe di codice e' follia.
Sei fuori strada. L'XDK e' un prodotto di un team esterno.
Ma andresti alla cieca, dovresti scorrere tutto il codice guardare cosa fa per vedere se è da modificare.
E' vero l'esatto contrario, non mi avventuro alla cieca nel design di una soluzione che non conosco e non ho mai tentato, ma lavoro mettendo le mani nel codice e quandi facendo emergere la soluzione.
Cosa che non puoi fare con un design rigido che da una parte non ammette modifiche, dall'altra e' sbagliato perche' per ovvi motivi non puo' prevedere tutte le problematiche durante tre anni di sviluppo.
Senza un documento di analisi quanti secoli mi ci sarebbero voluti a trovare tutti gli oggetti da modificare?
Avevo un documento sotto mano che diceva in questo progetto nel metodo X aggiungere la clausola Y, creare la stored Z che usi le viste H,K da modificare per la gestione del nuovo stato ecc...
Senza spendere il tempo per scrivere quell'inutile documento e doverlo mantenere, molto probabilmente non avresti neppure dovuto fare quella modifica.
Ma comunque, hai gia' una volta creato esempi falsi per darti ragione quindi e' inutile proseguire questo discorso :)
Il punto e': pensare di creare un documento di design prima di scrivere cinque milioni di righe di codice e' follia.
franksisca
06-02-2008, 18:18
io credo che debbano andare di pari passo....ovvero, progetto una cosa e la realizzo, se la realizzazione non va bene, allora ho sbagliato la progettazione, riprogetto e rirealizzo.......ovviamente se step piccoli corrispondono tempi piccoli......quindi mi trova d'accordo con l'affermazione principale....
banryu79
06-02-2008, 19:04
Leggetevi l'articolo il cui link (http://martinfowler.com/articles/designDead.html)è stato postato nella prima pagina del thread. [qui riportato per comodità]
L'autore non è un pincopallino qualsiasi, le sue parole hanno dietro anni di esperienza sul problema "software design", e quelle riportate sono osservazioni derivanti da una vita spesa sulla questione.
E' stato un articolo molto iluminante, almeno per me, privo di esperienza diretta di lavoro su progetti complessi e/o corposi.
P.S.:
@fek: beh, immagino almeno che il codice sia scritto in maniera pulitissima e ordinatissima e commentato con i controcoglioni (il che non significa che bisogna scrivere una bibbia di roba, se non serve, ma che ci si attiene in maniera scrupolosissima a certe regole) e che tale aspetto sia un must irrinunciabile (sono un po' fanatico in materia :D )
L'autore non è un pincopallino qualsiasi, le sue parole hanno dietro anni di esperienza sul problema "software design", e quelle riportate sono osservazioni derivanti da una vita spesa sulla questione.
E' stato un articolo molto iluminante, almeno per me, privo di esperienza diretta di lavoro su progetti complessi e/o corposi.
P.S.:
@fek: beh, immagino almeno che il codice sia scritto in maniera pulitissima e ordinatissima e commentato con i controcoglioni (il che non significa che bisogna scrivere una bibbia di roba, se non serve, ma che ci si attiene in maniera scrupolosissima a certe regole) e che tale aspetto sia un must irrinunciabile (sono un po' fanatico in materia :D )
fek
06-02-2008, 19:06
P.S.:
@fek: beh, immagino almeno che il codice sia scritto in maniera pulitissima e ordinatissima e commentato con i controcoglioni (il che non significa che bisogna scrivere una bibbia di roba, se non serve, ma che ci si attiene in maniera scrupolosissima a certe regole) e che tale aspetto sia un must irrinunciabile (sono un po' fanatico in materia :D )
Non ricordo l'ultima volta che ho scritto un commento. Forse due o tre anni fa :)
@fek: beh, immagino almeno che il codice sia scritto in maniera pulitissima e ordinatissima e commentato con i controcoglioni (il che non significa che bisogna scrivere una bibbia di roba, se non serve, ma che ci si attiene in maniera scrupolosissima a certe regole) e che tale aspetto sia un must irrinunciabile (sono un po' fanatico in materia :D )
Non ricordo l'ultima volta che ho scritto un commento. Forse due o tre anni fa :)
banryu79
06-02-2008, 19:11
Non ricordo l'ultima volta che ho scritto un commento. Forse due o tre anni fa :)
:eekk:...
:ops:
P.S: Ehm, allora (proviamo questa, dai) siete rigoroserrimi circa i nomi delle classi/metodi/attributi? :D
:eekk:...
:ops:
P.S: Ehm, allora (proviamo questa, dai) siete rigoroserrimi circa i nomi delle classi/metodi/attributi? :D
fek
06-02-2008, 19:19
:eekk:...
:ops:
P.S: Ehm, allora (proviamo questa, dai) siete rigoroserrimi circa i nomi delle classi/metodi/attributi? :D
Beh questo si'. Ma comunque F2 non e' un esempio di metodologia efficientissima. Da questo punto di vista Diamonds e' molto avanti (a mio avviso :)).
:ops:
P.S: Ehm, allora (proviamo questa, dai) siete rigoroserrimi circa i nomi delle classi/metodi/attributi? :D
Beh questo si'. Ma comunque F2 non e' un esempio di metodologia efficientissima. Da questo punto di vista Diamonds e' molto avanti (a mio avviso :)).
^TiGeRShArK^
06-02-2008, 22:09
Leggetevi l'articolo il cui link (http://martinfowler.com/articles/designDead.html)è stato postato nella prima pagina del thread. [qui riportato per comodità]
...lo stavo leggendo ieri sera..
fino alla parte sui pattern...
poi ho iniziato a girare su wikipedia per i vari pattern possibili e imaginabili per rinfrescari un pò la memoria dato che non me ne ricordo mai molti oltre quelli "classici"...
e poi non so come sono finito nel giro delle analisi prestazionali comparate tra ruby, ruby 1.9, jruby 1.1, rubinius e python :stordita:
...lo stavo leggendo ieri sera..
fino alla parte sui pattern...
poi ho iniziato a girare su wikipedia per i vari pattern possibili e imaginabili per rinfrescari un pò la memoria dato che non me ne ricordo mai molti oltre quelli "classici"...
e poi non so come sono finito nel giro delle analisi prestazionali comparate tra ruby, ruby 1.9, jruby 1.1, rubinius e python :stordita:
sottovento
07-02-2008, 01:33
"Any design effort that takes more than 30 minutes is a waste of time."
Si riferisce a tutti i tipi di progetto di software?
30 minuti per persona?
fek ipotizzava "per sessione", ma non vedo questa informazione. Da questa frase potrebbe essere 30 minuti e basta per tutta la vita del software.
Come fa il signore in questione a sapere quanto mi costa un bug? E dove se ne vanno principalmente i soldi?
Si riferisce a tutti i tipi di progetto di software?
30 minuti per persona?
fek ipotizzava "per sessione", ma non vedo questa informazione. Da questa frase potrebbe essere 30 minuti e basta per tutta la vita del software.
Come fa il signore in questione a sapere quanto mi costa un bug? E dove se ne vanno principalmente i soldi?
tomminno
07-02-2008, 07:35
Il punto e': pensare di creare un documento di design prima di scrivere cinque milioni di righe di codice e' follia.
E pensare di mettere mano ad un sistema che sta in piedi da anni e che gestisce una quantità smisurata di dati, senza un documento di analisi è altrettanto folle.
Sono 2 situazioni differenti.
Tra 5 anni non starai ancora lavorando al progetto attuale.
Il sistema su cui lavoro io sarà in piedi sicuramente anche tra 10 anni.
E pensare di mettere mano ad un sistema che sta in piedi da anni e che gestisce una quantità smisurata di dati, senza un documento di analisi è altrettanto folle.
Sono 2 situazioni differenti.
Tra 5 anni non starai ancora lavorando al progetto attuale.
Il sistema su cui lavoro io sarà in piedi sicuramente anche tra 10 anni.
cionci
07-02-2008, 07:42
E pensare di mettere mano ad un sistema che sta in piedi da anni e che gestisce una quantità smisurata di dati, senza un documento di analisi è altrettanto folle.
La documentazione può essere anche creata dopo la fase di implementazione (anche con strumenti automatici), non necessariamente deve essere creata come risultato della progettazione.
La documentazione può essere anche creata dopo la fase di implementazione (anche con strumenti automatici), non necessariamente deve essere creata come risultato della progettazione.
cdimauro
07-02-2008, 08:12
Quale migliore documentazione del codice stesso, e dei relativi test che ne mostrano il funzionamento? :p
banryu79
07-02-2008, 08:12
La documentazione può essere anche creata dopo la fase di implementazione (anche con strumenti automatici), non necessariamente deve essere creata come risultato della progettazione.
Concordo in pieno.
I concetti allora sono diversi: un conto è documentare un sistema stabile, un conto è produrre documenti di progettazione per creare un sistema stabile.
Nel primo caso la documentazione è figlia del codice prodotto, nel secondo mi pare vero il contrario, o almeno quella sarebbe l'intenzione (ed è più time-consuming dato che abbiamo capito come il codice, in fase di scrittura di un sistema, sia soggetto a continui cambiamenti, perchè cresce e matura man mano che il sistema viene implementato).
E, sempre nel secondo caso, la progettazione tende (generalmente) a essere meno agile, cioè a rispondere meno prontamente con i cambiamenti e le scoperte che si verificano durante la fase di implementazione, introducendo un'inerzia nei documenti di progetto, che rimangono "indietro" rispetto il codice di cui vorrebbero parlare in modo adeguato e aumentando i "costi" nel caso si voglia farla stare al passo.
Molto meglio documentare dopo l'implementazione.
La progettazione/design di un sistema procede di pari passi con l'evoluzione di quest'ultimo in fase implementativa, sono quindi la stesura del codice, le sue modifiche, il refactoring e quant'altro avviene a livello sorgente a dare il giusto e naturale ritmo allo sviluppo.
Queste considerazioni sono quelle che hanno determinato come nuova risposta al "problema del design" la nascita dei metodi di progettazione agile, come evulozione rispetto ai paradigmi precedenti.
Almeno questo è quello che ho capito :stordita:
Concordo in pieno.
I concetti allora sono diversi: un conto è documentare un sistema stabile, un conto è produrre documenti di progettazione per creare un sistema stabile.
Nel primo caso la documentazione è figlia del codice prodotto, nel secondo mi pare vero il contrario, o almeno quella sarebbe l'intenzione (ed è più time-consuming dato che abbiamo capito come il codice, in fase di scrittura di un sistema, sia soggetto a continui cambiamenti, perchè cresce e matura man mano che il sistema viene implementato).
E, sempre nel secondo caso, la progettazione tende (generalmente) a essere meno agile, cioè a rispondere meno prontamente con i cambiamenti e le scoperte che si verificano durante la fase di implementazione, introducendo un'inerzia nei documenti di progetto, che rimangono "indietro" rispetto il codice di cui vorrebbero parlare in modo adeguato e aumentando i "costi" nel caso si voglia farla stare al passo.
Molto meglio documentare dopo l'implementazione.
La progettazione/design di un sistema procede di pari passi con l'evoluzione di quest'ultimo in fase implementativa, sono quindi la stesura del codice, le sue modifiche, il refactoring e quant'altro avviene a livello sorgente a dare il giusto e naturale ritmo allo sviluppo.
Queste considerazioni sono quelle che hanno determinato come nuova risposta al "problema del design" la nascita dei metodi di progettazione agile, come evulozione rispetto ai paradigmi precedenti.
Almeno questo è quello che ho capito :stordita:
thebol
07-02-2008, 08:23
Se devi modificare qualcosa che sta nei progetti di terze parti devi chiedere a chi ha prodotto la libreria se te la modifica, non puoi pianificare/analizzare modifiche su quelle.
Ma andresti alla cieca, dovresti scorrere tutto il codice guardare cosa fa per vedere se è da modificare.
Ho recentemente lavorato all'aggiunta di uno stato nel sistema di gestione dei domini per gestire la pubblicità di google, ho dovuto modificare almeno 10 tra console e webservice,
altrettanti vbs, così come ho dovuto mettere mano ad un sacco di Viste e Stored Procedure su diversi database posti su macchine differenti.
Tutto per la gestione di un misero numero.
Senza un documento di analisi quanti secoli mi ci sarebbero voluti a trovare tutti gli oggetti da modificare?
Avevo un documento sotto mano che diceva in questo progetto nel metodo X aggiungere la clausola Y, creare la stored Z che usi le viste H,K da modificare per la gestione del nuovo stato ecc...
quello che fek contesta non è tanto la documentazione, ma la documentazione su cui basare una nuova feature.
Poi ovvio che sei ha un sistema formato da 10 parti, devi fare una modifica, dovrai sapere o leggere come è fatto il sistema(un po come da fek ci saranno 2 righe sul sistema di build degli asset, o altre cose).
fek sbaglio?
Ma andresti alla cieca, dovresti scorrere tutto il codice guardare cosa fa per vedere se è da modificare.
Ho recentemente lavorato all'aggiunta di uno stato nel sistema di gestione dei domini per gestire la pubblicità di google, ho dovuto modificare almeno 10 tra console e webservice,
altrettanti vbs, così come ho dovuto mettere mano ad un sacco di Viste e Stored Procedure su diversi database posti su macchine differenti.
Tutto per la gestione di un misero numero.
Senza un documento di analisi quanti secoli mi ci sarebbero voluti a trovare tutti gli oggetti da modificare?
Avevo un documento sotto mano che diceva in questo progetto nel metodo X aggiungere la clausola Y, creare la stored Z che usi le viste H,K da modificare per la gestione del nuovo stato ecc...
quello che fek contesta non è tanto la documentazione, ma la documentazione su cui basare una nuova feature.
Poi ovvio che sei ha un sistema formato da 10 parti, devi fare una modifica, dovrai sapere o leggere come è fatto il sistema(un po come da fek ci saranno 2 righe sul sistema di build degli asset, o altre cose).
fek sbaglio?
fek
07-02-2008, 09:38
La documentazione può essere anche creata dopo la fase di implementazione (anche con strumenti automatici), non necessariamente deve essere creata come risultato della progettazione.
Esatto :)
Nessuno dice che non deve esserci documentazione in una qualche forma (test, diagrammi autogenerati, javadoc, elenco delle classi). E' deleterio scrivere una documentazione estesa prima di aver scritto il codice, doverla matenere aggiornata manualmente e cercare di usarla per scrivere il codice meccanicamente.
E' chiaro anche da questa discussione, infatti tommino e' passato da "Chi non fa design prima non ha mai scritto un sistema complesso" a "Serve documentazione per modificare un sistema complesso". C'e' una differenza abissale fra i due concetti e nessuno ha mai negato il secondo.
Esatto :)
Nessuno dice che non deve esserci documentazione in una qualche forma (test, diagrammi autogenerati, javadoc, elenco delle classi). E' deleterio scrivere una documentazione estesa prima di aver scritto il codice, doverla matenere aggiornata manualmente e cercare di usarla per scrivere il codice meccanicamente.
E' chiaro anche da questa discussione, infatti tommino e' passato da "Chi non fa design prima non ha mai scritto un sistema complesso" a "Serve documentazione per modificare un sistema complesso". C'e' una differenza abissale fra i due concetti e nessuno ha mai negato il secondo.
tomminno
07-02-2008, 12:41
Esatto :)
Nessuno dice che non deve esserci documentazione in una qualche forma (test, diagrammi autogenerati, javadoc, elenco delle classi). E' deleterio scrivere una documentazione estesa prima di aver scritto il codice, doverla matenere aggiornata manualmente e cercare di usarla per scrivere il codice meccanicamente.
E' chiaro anche da questa discussione, infatti tommino e' passato da "Chi non fa design prima non ha mai scritto un sistema complesso" a "Serve documentazione per modificare un sistema complesso". C'e' una differenza abissale fra i due concetti e nessuno ha mai negato il secondo.
Tra documentazione estesa e analisi che dura meno di mezz'ora ce ne passa.
Che poi l'analisi mica si riduce alla sola documentazione del codice.
Ci sono anche da considerare i fattori economici. Quante ore uomo mi servono per implemetare questa nuova funzionalità? Quanto può rendere l'implementazione?
Il thread era partito con l'assuzione che se impieghi più di 30 minuti nell'analisi stai sprecando tempo.
Credo che dipenda molto dal sistema in esame.
E dubito seriamente che chi ha pensato di far partire il progetto di Fable 2 lo abbia fatto in meno di mezz'ora.
Si parlava di "design effort" ovvero progettazione di un sistema. La progettazione include anche parti non strettamente informatiche.
Nessuno dice che non deve esserci documentazione in una qualche forma (test, diagrammi autogenerati, javadoc, elenco delle classi). E' deleterio scrivere una documentazione estesa prima di aver scritto il codice, doverla matenere aggiornata manualmente e cercare di usarla per scrivere il codice meccanicamente.
E' chiaro anche da questa discussione, infatti tommino e' passato da "Chi non fa design prima non ha mai scritto un sistema complesso" a "Serve documentazione per modificare un sistema complesso". C'e' una differenza abissale fra i due concetti e nessuno ha mai negato il secondo.
Tra documentazione estesa e analisi che dura meno di mezz'ora ce ne passa.
Che poi l'analisi mica si riduce alla sola documentazione del codice.
Ci sono anche da considerare i fattori economici. Quante ore uomo mi servono per implemetare questa nuova funzionalità? Quanto può rendere l'implementazione?
Il thread era partito con l'assuzione che se impieghi più di 30 minuti nell'analisi stai sprecando tempo.
Credo che dipenda molto dal sistema in esame.
E dubito seriamente che chi ha pensato di far partire il progetto di Fable 2 lo abbia fatto in meno di mezz'ora.
Si parlava di "design effort" ovvero progettazione di un sistema. La progettazione include anche parti non strettamente informatiche.
shinya
08-02-2008, 13:21
Per risolvere le dipendenze degli asset.
Tende ancora sfuggirmi cosa faccia il vostro db che un...chennesò...mysql o postgresql non riesca a fare.
Sempre db relazionale è, no?
Tende ancora sfuggirmi cosa faccia il vostro db che un...chennesò...mysql o postgresql non riesca a fare.
Sempre db relazionale è, no?
thebol
08-02-2008, 13:30
Tende ancora sfuggirmi cosa faccia il vostro db che un...chennesò...mysql o postgresql non riesca a fare.
Sempre db relazionale è, no?
probabilmente si, ma si vede che la soluzione in house era piu comoda da fare/più efficiente
Sempre db relazionale è, no?
probabilmente si, ma si vede che la soluzione in house era piu comoda da fare/più efficiente
fek
08-02-2008, 15:03
Tende ancora sfuggirmi cosa faccia il vostro db che un...chennesò...mysql o postgresql non riesca a fare.
Sempre db relazionale è, no?
Era un problema puramente prestazionale in questo caso: il motore relazionale gira localmente ed e' ottimizzato solo per lo scopo di creare alberi di dipendenze degli asset, per questo non era possibile usare qualcosa di piu' generico.
Sempre db relazionale è, no?
Era un problema puramente prestazionale in questo caso: il motore relazionale gira localmente ed e' ottimizzato solo per lo scopo di creare alberi di dipendenze degli asset, per questo non era possibile usare qualcosa di piu' generico.
fek
08-02-2008, 15:05
Tra documentazione estesa e analisi che dura meno di mezz'ora ce ne passa.
Che poi l'analisi mica si riduce alla sola documentazione del codice.
Confondi l'analisi con il design. Sono due cose totalmente diverse, e l'analisi economica del software non e' compito dello sviluppatore, ma del customer.
Il thread era partito con l'assuzione che se impieghi più di 30 minuti nell'analisi stai sprecando tempo.
Ti cito il titolo del thread:
[DESIGN] "Any design effort that takes more than 30 minutes is a waste of time."
Si parlava di "design effort" ovvero progettazione di un sistema. La progettazione include anche parti non strettamente informatiche.
No, design e' solo la progettazione dell'architettura del codice. Non puoi cambiare il significato dei termini per darti ragione. E' la terza volta che cambi versione :)
Che poi l'analisi mica si riduce alla sola documentazione del codice.
Confondi l'analisi con il design. Sono due cose totalmente diverse, e l'analisi economica del software non e' compito dello sviluppatore, ma del customer.
Il thread era partito con l'assuzione che se impieghi più di 30 minuti nell'analisi stai sprecando tempo.
Ti cito il titolo del thread:
[DESIGN] "Any design effort that takes more than 30 minutes is a waste of time."
Si parlava di "design effort" ovvero progettazione di un sistema. La progettazione include anche parti non strettamente informatiche.
No, design e' solo la progettazione dell'architettura del codice. Non puoi cambiare il significato dei termini per darti ragione. E' la terza volta che cambi versione :)
jappilas
08-02-2008, 16:02
E dubito seriamente che chi ha pensato di far partire il progetto di Fable 2 lo abbia fatto in meno di mezz'ora.parti dal presupposto che il "tempo di ragionamento" debba essere dedicato al progetto della soluzione finale nella sua totalità e al massimo livello di dettaglio ( studio dell' implementazione PER OGNI funzione prevista )
ma una cosa di cui mi sono reso conto con Diamonds e che credo che sia ciò a cui si riferiva fek è che quel tempo viene dedicato al problema contingente, al task da svolgere in un dato momento, finalizzato all' implementazione di una singola funzione del gioco, parte minimale ma fondamentale del risultato complessivo - come è fondamentale che la sua soluzione sia rapida perchè lo sviluppo proceda a ritmo regolare
Si parlava di "design effort" ovvero progettazione di un sistema. La progettazione include anche parti non strettamente informatiche.può darsi l' oggetto che sto progettando è abbastanza complesso da richiedere la coesistenza di realizzazioni informatiche, accanto a altre la cui realizzazione non prevede studio di algoritmi e scrittura di codice (ad esempio un' autovettura con i suoi organi meccanici controllati da centralline a loro volta basate su logica programmabile)
ma se ci si limita allo sviluppo di soluzioni informatiche il "design" mi risulta conincida con la modellazione della soluzione SW sui requisiti funzionali al livello e nel modo in cui questi vengono presi in considerazione ( a seconda del metodo adottato, Waterfall, Agile... ), e lo studio dei costi qualcosa che prescinde ...
ma una cosa di cui mi sono reso conto con Diamonds e che credo che sia ciò a cui si riferiva fek è che quel tempo viene dedicato al problema contingente, al task da svolgere in un dato momento, finalizzato all' implementazione di una singola funzione del gioco, parte minimale ma fondamentale del risultato complessivo - come è fondamentale che la sua soluzione sia rapida perchè lo sviluppo proceda a ritmo regolare
Si parlava di "design effort" ovvero progettazione di un sistema. La progettazione include anche parti non strettamente informatiche.può darsi l' oggetto che sto progettando è abbastanza complesso da richiedere la coesistenza di realizzazioni informatiche, accanto a altre la cui realizzazione non prevede studio di algoritmi e scrittura di codice (ad esempio un' autovettura con i suoi organi meccanici controllati da centralline a loro volta basate su logica programmabile)
ma se ci si limita allo sviluppo di soluzioni informatiche il "design" mi risulta conincida con la modellazione della soluzione SW sui requisiti funzionali al livello e nel modo in cui questi vengono presi in considerazione ( a seconda del metodo adottato, Waterfall, Agile... ), e lo studio dei costi qualcosa che prescinde ...
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.