PROGRAMMATORI E CRISI ECONOMICA

[beppegrillo]

Originariamente inviato da jappilas

basta che non si sappia in giro e sei tranquillo...

Guarda che non è una cosa dell'altro mondo guadagnare 40k sterline.
In italia vabbeh và di moda il 1000 euro politico , ma siamo tutt'altro che una società evoluta sotto questi aspetti.

[fek]

Originariamente inviato da gokan

Ok, adesso faccio un pò di domande da vero ignorante, quindi perdonatemi in anticipo

Da quanto ho capito, entrambi vi occupate della parte di vera e propria scrittura del codice sorgente. Voi scrivete il vostro codice e poi come fate a controllare che vada bene o no? avete una sorta di demo in cui provate, cioè, vi capita di vedere il vero e proprio gioco girare oppure il vostro codice lo passate a qualcuno che mette tutto assieme e poi si prova? Spero di essermi fatto capire, non è facile da spiegare

Come vedete il frutto del vostro lavoro?

Io lavoro (avo) prevalentemente sui testbed, piccoli programmi che usano il motore 3d sui quali scrivo e testo manualmente (sigh) il codice. Ora che siamo piu' in bug fixing lavoro sul gioco e vero e proprio e correggo i bug che mi vengono assegnati dal dipartimento di testing.

Il codice non viene "passato" ad altri, ma viene inserito in un repository centrale dov'e' continuamente integrata una ultima versione del gioco e di tutte le librerie. Quando un game programmer ha bisogno di un qualche servizio del motore 3d (ad esempio per disegnare un qualche modello su schermo), prende l'ultima versione di tutto il codice del gioco e usa i servizi che ho inserito io precedentemente.

Il dipartimento di testing che ho citato prima si occupa di prendere continuamente l'ultima versione del codice e di cercare i bug e assicurarsi che quelli fissati lo siano per davvero.

[fek]

Originariamente inviato da jappilas

se non erro, la metodica prevede che siccome in un progetto SW la scrittura di codice è la fase implementiva che segue quella di design, si abbia già un progetto d' assieme e relative specifiche su cui lavorare, quindi a rigore sarebbe possibile scrivere in parallelo delle routine di test per verificare che il codice che si sta scrivendo , sia corretto, il dominio dei parametri sia ben fondato ecc

Non esiste fare design e scrivere il codice in fasi separate!

[MSciglio]

Originariamente inviato da fek

Non esiste fare design e scrivere il codice in fasi separate!

Qui pure per andare in bagno devi scrivere documenti di requirements, specification e design

[fek]

Originariamente inviato da MSciglio

Qui pure per andare in bagno devi scrivere documenti di requirements, specification e design

Che immagino dopo pochissimo tempo diventeranno obsoleti e mai aggiornati...

Ci avevano provato anche da noi per un certo periodo, ma quando la produttivita' e' colata a picco hanno cambiato idea. Una cosa e' stendere in maniera precisa i requisiti (e ci sta anche documento se non si fa automated testing), ma scrivere per intero il design del codice prima di scrivere il codice stesso e' follia pura, soprattutto in campo come il nostro dove la maggior parte del tempo si passa a fare R&D.

Racconto qualcosina di piu'. Da noi sono arrivati al paradosso di volere discussi e accettatti i documenti di requisiti, specifiche e design prima di scrivere qualunque codice. Alla fine la gente pur di lavorare, scriveva i documenti, li sottoponeva al processo di accettazione e poi iniziava a scrivere il codice pur di non passare ore di fronte al monitor a far nulla. Magicamente facevo il check in del codice sempre due minuti dopo l'accettazione del mio documento ed il codice era sempre e comunque diverso da quello descritto nel documento e approvato (spesso anche i requisiti erano differenti), per l'ovvio motivo che mentre scrivevo il codice rifacevo il design in maniera piu' semplice visto che avevo piu' informazioni sul dominio della soluzione. E come me tutti gli altri. Alla fine hanno notato che forse costringerci a scrivere inutili documenti era una fesseria

[D3stroyer]

ma sei l'eccezione italiana o è tutto un misto li?

[MSciglio]

Originariamente inviato da fek

Che immagino dopo pochissimo tempo diventeranno obsoleti e mai aggiornati...

Ci avevano provato anche da noi per un certo periodo, ma quando la produttivita' e' colata a picco hanno cambiato idea. Una cosa e' stendere in maniera precisa i requisiti (e ci sta anche documento se non si fa automated testing), ma scrivere per intero il design del codice prima di scrivere il codice stesso e' follia pura, soprattutto in campo come il nostro dove la maggior parte del tempo si passa a fare R&D.

Racconto qualcosina di piu'. Da noi sono arrivati al paradosso di volere discussi e accettatti i documenti di requisiti, specifiche e design prima di scrivere qualunque codice. Alla fine la gente pur di lavorare, scriveva i documenti, li sottoponeva al processo di accettazione e poi iniziava a scrivere il codice pur di non passare ore di fronte al monitor a far nulla. Magicamente facevo il check in del codice sempre due minuti dopo l'accettazione del mio documento ed il codice era sempre e comunque diverso da quello descritto nel documento e approvato (spesso anche i requisiti erano differenti), per l'ovvio motivo che mentre scrivevo il codice rifacevo il design in maniera piu' semplice visto che avevo piu' informazioni sul dominio della soluzione. E come me tutti gli altri. Alla fine hanno notato che forse costringerci a scrivere inutili documenti era una fesseria

Una cosa e' certa, trovare il giusto equilibro tra formalismo e produttivita' e' estremamente complesso.
La bonta' del processo design->implementazione dipende poi dal dettaglio con il quale progetti il design. E' normale che l'implementazione tendera' a discostarsi dal documento di design quanto piu' dettagli tendi ad enfatizzare nel documento, ma questo e' inevitabile.

Il fatto pero' di essere costretto a scrivere un documento chiaro ed esaustivo ti porta a ragionare a fondo sul progetto in questione ed anche il doverlo sottoporre al giudizio di altri colleghi che dovranno approvarlo sicuramente aiuta ad individuare errori prima che questi diventino troppo "costosi" per essere corretti.

In sostanza noi ci troviamo molto bene con l'attuale processo produttivo. Per quanto riguarda la sincronizzazione del documento di design con l'implementazione abbiamo deciso di non aggiornare il documento (a meno di cambiamenti drastici). Gli eventuali dettagli implementativi si possono comunque evincere dalla documentazione inglobata nel codice.

[MSciglio]

Originariamente inviato da D3stroyer

ma sei l'eccezione italiana o è tutto un misto li?

Qui da me siamo 3 italiani (2 programmatori ed 1 grafico). Poi c'e' gente letteralmente da tutte le parti del mondo.

[fek]

Originariamente inviato da MSciglio

Una cosa e' certa, trovare il giusto equilibro tra formalismo e produttivita' e' estremamente complesso.
La bonta' del processo design->implementazione dipende poi dal dettaglio con il quale progetti il design. E' normale che l'implementazione tendera' a discostarsi dal documento di design quanto piu' dettagli tendi ad enfatizzare nel documento, ma questo e' inevitabile.

E' proprio il fatto che i cambiamenti sono inevitabili che segna l'inutilita' di "scrivere" e mantenere documenti di design, perche' piu' sono dettagliati, piu' e' sicuro che non saranno una documentazione attendibile del codice, quindi perdono la funzione per la quale sono nati.

Per essere piu' preciso non sono contrario a scrivere un documento propositivo per chiarirsi le idee sul problema e per discuterlo con il resto del team, questa anche secondo me e' un attivita' che puo' essere utile; si tratta in fondo di analisi dei requisiti che io comunque preferisco fare di persona in un meeting e non attraverso documenti spediti via mail. Ma questa e' una questione piu' di metodo e preferenze.

Secondo me, pero', quei documenti una volta scritti vanno messi via, la documentazione e' il codice stesso, l'unica documentazione che e' costantemente aggiornata con se' stessa.

Il fatto pero' di essere costretto a scrivere un documento chiaro ed esaustivo ti porta a ragionare a fondo sul progetto in questione ed anche il doverlo sottoporre al giudizio di altri colleghi che dovranno approvarlo sicuramente aiuta ad individuare errori prima che questi diventino troppo "costosi" per essere corretti.

La curva di costo dei cambiamenti

E se esistessero metodologie di sviluppo per appiattire la curva di costo dei cambiamenti tali che risulta economicamente piu' vantaggioso scrivere direttamente il codice e provare la soluzione "sul campo" piuttosto che spendere tempo nello scrivere un documento che per forza di cose sara' sempre e comunque non in linea con il codice?

Secondo queste metodologie, un cambiamento al design del codice avrebbe un costo sempre uguale a qualunque stadio dello sviluppo sia effettuato, anche dopo aver scritto magari tutta l'applicazione. Questa e' la base di partenza delle metodologie agili.

A mio avviso scrivere documenti e' la soluzione sbagliata al problema di scrivere velocemente codice pulito, con pochi difetti e facile da mantenere. E' come porre la classica la benda bagnata in testa ad un malato per curare i sintomi della malattia ma non la malattia stessa. Se non si cura la malattia il malato muore, se non si cura il problema alla base del processo di sviluppo il progetto muore, non c'e' documentazione che tenga.

In sostanza noi ci troviamo molto bene con l'attuale processo produttivo. Per quanto riguarda la sincronizzazione del documento di design con l'implementazione abbiamo deciso di non aggiornare il documento (a meno di cambiamenti drastici). Gli eventuali dettagli implementativi si possono comunque evincere dalla documentazione inglobata nel codice.

Su queste cose sono pragmatico: alla fine la metodologia piu' giusta e' quella con la quale un team di sviluppo si trova meglio. Cio' non toglie che ogni metodologia puo' essere affinata e migliorata per aumentare la produttivita' del gruppo.

Per fortuna credo che noi nel prossimo progetto ingloberemo molto delle metodologie di sviluppo agili nel nostro processo produttivo. Addio a quegli inutili documenti, benvenuti test automatici

[fek]

Originariamente inviato da D3stroyer

ma sei l'eccezione italiana o è tutto un misto li?

Nel mio team sono il solo italiano. In Lionhead ci sono altri due italiani.

[VICIUS]

Originariamente inviato da fek

[...] Il codice non viene "passato" ad altri, ma viene inserito in un repository centrale dov'e' continuamente integrata una ultima versione del gioco e di tutte le librerie. Quando un game programmer ha bisogno di un qualche servizio del motore 3d (ad esempio per disegnare un qualche modello su schermo), prende l'ultima versione di tutto il codice del gioco e usa i servizi che ho inserito io precedentemente.[...]

Domanda OT: Che SCM usate? Quanto è diventato "grande" il vostro repository dopo anni di commit, branch e merge ? Fate mai delle statistiche/classifiche tipo "i 10 programmatori che chiudono piu bug" o "i 10 file piu buggati del programma"...

ciao

[fek]

Originariamente inviato da VICIUS

Domanda OT: Che SCM usate? Quanto è diventato "grande" il vostro repository dopo anni di commit, branch e merge ? Fate mai delle statistiche/classifiche tipo "i 10 programmatori che chiudono piu bug" o "i 10 file piu buggati del programma"...

ciao

Sai che non lo so... Credo alcune decine di giga.

Stiamo facendo ora a gara a chi chiude piu' bug!
Arrivo a riportare i bug dopo averli chiusi per drogare le statistiche.. ci divertiamo con poco

[MSciglio]

Originariamente inviato da VICIUS

Domanda OT: Che SCM usate? Quanto è diventato "grande" il vostro repository dopo anni di commit, branch e merge ? Fate mai delle statistiche/classifiche tipo "i 10 programmatori che chiudono piu bug" o "i 10 file piu buggati del programma"...

ciao

Noi utilizziamo Perforce dopo aver provato SourceSafe e Alienbrain. Il repository e' immenso sopratutto a causa dei dati degli artisti.

[fek]

Originariamente inviato da MSciglio

Noi utilizziamo Perforce dopo aver provato SourceSafe e Alienbrain. Il repository e' immenso sopratutto a causa dei dati degli artisti.

Anche noi usiamo Perforce.
Dimmi quante volte ti sei dimenticato di fare il check in di file dentro la changelist "DONT CHECK IN" rompendo la build?

Usate Perforce anche per l'art asset? Qui usano Alienbrain per l'art asset e Perforce per il codice.

[MSciglio]

Originariamente inviato da fek

Per essere piu' preciso non sono contrario a scrivere un documento propositivo per chiarirsi le idee sul problema e per discuterlo con il resto del team, questa anche secondo me e' un attivita' che puo' essere utile; si tratta in fondo di analisi dei requisiti che io comunque preferisco fare di persona in un meeting e non attraverso documenti spediti via mail. Ma questa e' una questione piu' di metodo e preferenze.

E' quello che penso anche io. Come dicevo per me un documento di design non ha l'obiettivo di essere necessariamente in linea con l'attuale implementazione. E' una scusa per forzarti a pensare al problema guardandolo da tutti i lati. Anche io preferisco in genere organizzare meeting e discutere del design. Tuttavia il meeting per me deve venire dopo che gli altri interlocutori hanno letto e analizzato il mio documento di design in modo da muovere delle giuste obiezioni durante il meeting.

Originariamente inviato da fek

Secondo me, pero', quei documenti una volta scritti vanno messi via, la documentazione e' il codice stesso, l'unica documentazione che e' costantemente aggiornata con se' stessa.

Esattamente. Una volta scritto il documento l'unica documentazione valida e' quella del codice. Il documento di design rappresenta comunque un buon punto di partenza per un nuovo sviluppatore che si avvicina a quel determinato modulo software. Questo a patto che il design non differisca radicalmente dall'implementazione. Ma se cosi' fosse ci sarebbe gia' un errore di fondo durante la fase di design.

Originariamente inviato da fek

E se esistessero metodologie di sviluppo per appiattire la curva di costo dei cambiamenti tali che risulta economicamente piu' vantaggioso scrivere direttamente il codice e provare la soluzione "sul campo" piuttosto che spendere tempo nello scrivere un documento che per forza di cose sara' sempre e comunque non in linea con il codice?

Sicuramente sarebbe un processo piu' rapido. Ci sarebbe tuttavia meno possibilita' di ragionare sul problema e confrontarsi con gli altri.
Il design sarebbe certamente meno "visibile" per gli altri.

[MSciglio]

Originariamente inviato da fek

Anche noi usiamo Perforce.
Dimmi quante volte ti sei dimenticato di fare il check in di file dentro la changelist "DONT CHECK IN" rompendo la build?

Usate Perforce anche per l'art asset? Qui usano Alienbrain per l'art asset e Perforce per il codice.

Qui da noi chi rompe la build paga 1 pound (soldi che useremo per ubriacarci ovviamente...)
Fino ad ora mi e' successo una sola volta... sono tirchio e prima di fare check-in ci penso 100000 volte

Usiamo Perforce anche per tutti gli asset per APB. Abbiamo avuto un casino di problemi con Alienbrain in passato.

[fek]

Originariamente inviato da MSciglio

E' quello che penso anche io. Come dicevo per me un documento di design non ha l'obiettivo di essere necessariamente in linea con l'attuale implementazione. E' una scusa per forzarti a pensare al problema guardandolo da tutti i lati. Anche io preferisco in genere organizzare meeting e discutere del design. Tuttavia il meeting per me deve venire dopo che gli altri interlocutori hanno letto e analizzato il mio documento di design in modo da muovere delle giuste obiezioni durante il meeting.

Si', sono d'accordo su questo, ma non lo chiamerei documento di design.
Io preferisco comunque un meeting per discutere il problema, un brainstorming, ma questa e' una questione di abitudine.

Esattamente. Una volta scritto il documento l'unica documentazione valida e' quella del codice. Il documento di design rappresenta comunque un buon punto di partenza per un nuovo sviluppatore che si avvicina a quel determinato modulo software. Questo a patto che il design non differisca radicalmente dall'implementazione. Ma se cosi' fosse ci sarebbe gia' un errore di fondo durante la fase di design.

E' questo il punto, e' un errore inevitabile proprio perche' la fase di design avviene senza conoscere il problema totalmente il problema ed evidentemente senza conoscere totalmente la soluzione, che spesso e volentieri ho imparato solo dopo aver affrontato il problema.

Esempio banale: scrivo una pipeline deferred o no per il prossimo motore 3d? Immaginiamo che non ne ho mai scritta una, situazione tipica nel nostro campo. Risposta: Boh. Qui non c'e' brainstorming e design che tenga, se alla fine mi accorgo che la pipeline deferred non mi conviene perche' magari non si integra con la tool pipeline o metti qualunque altro problema che puo' avvenire, butto via tutto il tempo speso a fare il design, la discussione, il meeting, tutto il tempo speso per prendere una decisione per la quale non avevo elementi a sufficienza.

Soluzione alternativa, scrivo il codice in modo tale che il costo per cambiare dalla pipeline deferred a non deferred sia minimo, svolgo il design durante lo sviluppo non in anticipo, adatto il design al problema mano a mano che scrivo la soluzione, mantengo il mio codice alla complessita' minima indispensabile ed il design il piu' chiaro possibile evitando duplicazioni. Quando ho finito, avro' la soluzione deferred o meno che meglio si adatto al problema, e questa soluzione sara' uscita naturalmente dal codice e non poteva in alcun modo essere prevista totalmente in anticipo.

Per esperienza, fare il design in anticipo mi ha sempre portato a cercare di includere piu' casi possibili nel mio design, a overingegnerizzarlo e complicarlo per prevedere tutti i casi che vengono in mente a me e ai miei colleghi (e sai che succede quando quello dice che si potrebbe anche fare cosi' e l'altro ti dice che devi prevedere questo ).
Risultato: un design piu' complesso di quello che mi serviva.

Ora attuo una strategia diversa: scrivo il codice, lo mantengo semplice e lo complico solo quando strettamente necessario. Ho un po' di statistiche sul mio rendimento "prima e dopo la cura" da parte del team di Production ed ora ho produttivita' circa doppia e mi accorgo che quello che scrivo e' decisamente meno overingegnerizzato.

Con me ha funzionato

Sicuramente sarebbe un processo piu' rapido. Ci sarebbe tuttavia meno possibilita' di ragionare sul problema e confrontarsi con gli altri.
Il design sarebbe certamente meno "visibile" per gli altri.

Non sono d'accordo su entrambe le affermazioni. Non fare il design in anticipo non e' una scusa per non farlo proprio, ma vuol dire farlo continuamente, per me vuol dire ragionare continuamente sul problema e raffinare continuamente il design, solo con piu' informazioni.
Sul confronto con gl'altri, secondo me il confronto migliore e' sempre orale, quello scritto dipende troppo dalle interpretazioni, non c'e' un veloce scambio di opinioni; ho avuto molti problemi di interpretazioni sbagliate di mail e documenti che hanno portato me ed altri a perdere molto tempo.

Nel secondo caso, eravamo gia' d'accordo nel dire che il documento di design e' per forza di cose sempre disallineato con il codice ed e' meglio non avere alcuna documentazione che avere una documentazione "fuorviante" che non descrive il codice ma qualcos'altro.

[fek]

Originariamente inviato da MSciglio

Qui da noi chi rompe la build paga 1 pound (soldi che useremo per ubriacarci ovviamente...)
Fino ad ora mi e' successo una sola volta... sono tirchio e prima di fare check-in ci penso 100000 volte

Sono diventato povero infatti
Facevo i check in alla bersagliera, ho una collezione di Duck Of Shame, ho preso tanti di quegl'insulti che mi hanno insegnato a non rompere la build con le cattive. Ahio.

Usiamo Perforce anche per tutti gli asset per APB. Abbiamo avuto un casino di problemi con Alienbrain in passato.

Fate benissimo, anche secondo me e' inefficiente avere due sistemi separati.

[fek]

Maurizio, e' interessantissimo sapere come lavora ed e' organizzato un altro team di sviluppo

[VICIUS]

Originariamente inviato da fek

Sai che non lo so... Credo alcune decine di giga.

Ah pero. non vorrei di certo essere nei panni di chi deve gestirlo.

Originariamente inviato da fek

Stiamo facendo ora a gara a chi chiude piu' bug!
Arrivo a riportare i bug dopo averli chiusi per drogare le statistiche.. ci divertiamo con poco

Ci avrei scommesso.

ciao