View Full Version : riflessioni personali: organizzazione e metodi di lavoro
io dovrei ringraziare fek per varie cose che ho imparato da lui, sia insegnatemi esplicitamente che implicitamente.
ricordo che in una vecchia discussione si parlava dei metodi di lavoro che insegnano in genere alle università, in particolare di UML e di come questo linguaggio sia utile a formalizzare il funzionamento del software che si vuole creare, fase progettuale secondo molti assolutamente essenziale e da risolversi prima della stesura di qualsiasi riga codice; io sono appena all'inizio secondo anno, ma già vedo benissimo il tipo di metodo che ci vogliono inculcare nella testa all'università.
fek in quella discussione intervenne in un modo che mi piacque molto (adoro quando si scopre che i prof dicono cavolate :D :D :D): se ben ricordo disse più o meno che UML e metodi simili sono roba da... "perbenisti" (mia interpretazione della sua risposta :p) e che in realtà nel lavoro sono richiesti metodi molto più... "agili" e soprattutto produttivi, come ad esempio il metodo che stiamo usando nello sviluppo di Diamonds: refactoring continuo della codebase in base a obiettivi sempre nuovi (gli obiettivi posti dai vari task). apparentemente un metodo molto più lento di quello che insegnano all'università, il quale invece ci dice all'incirca "prima formalizzare e progettare il tutto e poi scrivere codice", ma di fatto non è così: i miei giudizi empirici dicono che è l'esatto opposto; perché? be', innanzitutto il metodo che ci insegna fek ricalca precisamente quella della mente umana, che orientativamente è molto buono: quando un programmatore free-lance fa un programma per conto suo in genere non progetta un bel nulla all'inizio, semplicemente si mette giù a buttar codice e ad aggiungere funzionalità strafiche al suo software; il fatto che poi non arrivi quasi mai molto lontano dipende da due cose:
1) una semplice proporzione: Microsoft Word sta al numero di persone che l'hanno creato (che saranno svariate decine, probabilmente centinaia) come x sta a una sola persona: quanto è grande x? :)
2) la pigrizia: a volte capita che una sola persona si scoccia di fare il programma che aveva inizialmente pensato, perciò semplicemente lo interrompe senza finirlo e non arriva a nulla di concreto; al contrario nelle aziende il lavoro è lavoro, e sei obbligato a farlo.
secondariamente una ragione percui il metodo che ci insegna fek è migliore è che evidentemente ha ragione lui (fek) quando dice che nessuno conosce la soluzione finale fin dall'inizio, ne' il programmatore ne' il "customer" (questo fa parte della terminologia che usiamo nel team del progetto Diamonds :p), e quindi semplicemente una progettazione decente all'inizio non è possibile; al diavolo UML.
ora una parentesi: una cosa che mi chiedo è come si fa in una grande azienda a dimostrare tutto questo? per quali motivi una grande azienda può arrivare a decidere di procedere by refactoring e di abbandonare il suo caro UML? dove stanno i numeri? il giudizio empirico di 71104 e le prediche di fek non bastano: le aziende ragionano a soldi e a numeri. sicchè mi piacerebbe anzitutto sapere questa cosa, chiusa parentesi.
ora, qualcuno ha mai visto il film "Scoprendo Forrester"? be', per citarlo, il mio concetto di programmare non è pensare, è programmare; questa è la mia filosofia, la quale sembra sposarsi perfettamente col metodo di lavoro che ci insegna fek. :p
a quanto pare secondo la libera interpretazione di un regista era anche il metodo di un famoso scrittore inglese :p :p :p
MA (c'è un ma)
è possibile che in alcuni casi in realtà il metodo di iniziare a scrivere codice solo *dopo* aver progettato *tutto* si riveli più efficiente dell'altro? è possibile che in alcuni casi si abbia fin dall'inizio un'idea estremamente precisa della soluzione finale (possibile in effetti), e che aspetti ancora ignoti si possano chiarire in futuro senza il minimo ritardo nello sviluppo del lavoro?
mi pongo questa domanda perché lavorando nel Night Sun Network oggi io e un membro dello staff abbiamo capito che dobbiamo darci una metodologia di lavoro più precisa e razionalmente scandita, e che dobbiamo stabilire delle timelines, anche approssimative (o almeno, quest'ultima cosa era quello che ho pensato io, ma l'altro tizio non so se ci è arrivato ancora :D).
dunque abbiamo iniziato a scrivere un txt in questo modo: lui ha scritto un primo abbozzo di quella che poteva essere una scaletta di lavoro; non aveva restrizioni di alcun tipo, ha semplicemente scritto qualsiasi cosa che poteva essere utilizzata come scansione del proprio lavoro; siccome il lavoro a cui mi riferisco è un software che bisogna realizzare per il network, si da il caso che il tizio abbia scritto una scaletta tipo gerarchica delle varie funzionalità di questo software; bene.
il passo successivo era che io avrei dovuto perfezionare il txt e ripassarglielo; poi lui avrebbe dovuto riperfezionarlo e ripassarmelo, e così via.
ebbene siamo giunti a qualcosa; anzi per l'esattezza siamo giunti a due cose ESTREMAMENTE diverse: per farla breve posso dirvi che io ho usato un metodo un po' alla fek, ed ero sul punto di definire delle timelines, mentre lui è partito in quarta andandoci giù non proprio di UML ma di schemi concettuali su come funzionerà il software (in altre parole ha usato un metodo che assomiglia molto a quello delle università e dell'UML).
ora ho osservato la seguente cosa: lui ha avuto una ispirazione, e le ispirazioni sono sempre utilissime perché estremamente produttive (dico sul serio); è estremamente probabile che il suo metodo funzioni, mentre se lui avesse usato il mio probabilmente la cosa sarebbe stata controproducente perché lui non ci si capacitava: non gli era congeniale e non gli ha suggerito nessuna ispirazione.
molto probabilmente riuscirà ad essere più produttivo procedendo come insegnano i miei prof (doh -.-' odio quando si scopre che i prof dicono cose giuste) anziché come insegna fek; come è possibile tutto ciò?
ho pensato che tutto questo potesse costituire uno spunto per una discussione interessante (e nessuno risponde :D)
PS: scusate la lunghezza del post e scusate se sono stato prolisso :p
aggiungo una possibile spiegazione che sono riuscito a darmi all'ultimo quesito del precedente post: io penso che in effetti qualsiasi metodologia vada bene, purché sia basata su un criterio razionale.
quando si progetta un metodo di lavoro l'obiettivo primario dovrebbe essere la velocità e la produttività: bisogna agire il meno possibile producendo il più possibile, e questo vale sia per il pensare sia per lo scrivere righe di codice (soprattutto per la seconda però).
se il metodo di lavoro che si è progettato si basa su un criterio razionale e corretto a mio parere il metodo può essere molto produttivo. perché allora nelle aziende UML non si usa (o comunque non si usa all'inizio del lavoro)? premesso che non so se veramente nessuno lo usa, magari non lo usano solo alla LionHead e solo per certi lavori :p, il progettare prima e programmare dopo è un metodo rischioso: potrebbe portare molto facilmente a un vicolo cieco a causa del fatto che non si sa a cosa si va incontro; per applicarlo con certezza bisogna aver avuto un'ottima ispirazione (sapete, tipo quando il cervello aumenta la sua velocità e diventa in grado di controllare 8 cose contemporaneamente :D) e bisogna avere le idee molto molto chiare su cosa si vuole fare (e tutto questo non è impossibile); ma un'azienda impegnata in un progetto di enormi dimensioni (quale può essere un videogioco tridimensionale molto complesso o un programma di videoscrittura degno di questo nome, o addirittura un sistema operativo come Microsoft Windows) l'ultima cosa che vuole fare è rischiare di cadere in costosi vicoli ciechi, anche perché sicuramente le centinaia di persone che lavorano nel team avranno ispirazioni molto diverse :D
more likely un'azienda di grosse dimensioni impegnata in un grande progetto preferirà fare centinaia degli spikes di fek per vedere che possibilità ha, poi inizierà a porsi i primi rudimentali obiettivi, inizierà a scrivere tonnellate di codice, e man mano gli obiettivi si perfezioneranno e raffineranno fino a raggiungere la soluzione finale con un rischio quasi nullo (perché purtroppo quello c'è sempre) di finire nel costoso vicolo cieco; dico che quello c'è sempre perché gli spikes per quanti siano purtroppo non possono prevedere ogni tipo di imprevisto: noi ad esempio in Diamonds abbiamo appena scoperto che le librerie che usiamo per interfacciare Java con OpenGL non accettano textures le cui dimensioni non siano potenze di due; in caso contrario parte una simpaticissima eccezione. tutto questo mi suggerisce una situazione un po' diversa: che avremmo fatto se non fossimo riusciti a scoprire il motivo di quella eccezione, o se addirittura il motivo fosse stato un vero e proprio bug di qualche libreria??? fortunatamente avevamo già pronti gli spikes (fatti da me :D) per JNI, coi quali avremmo potuto interfacciarci con una nostra DLL fatta in C++ e successivamente con OpenGL, dunque avevamo uno o più spikes che ci avrebbero salvati, ma l'imprevisto avrebbe potuto essere ancora peggiore e avremmo potuto non avere spikes del caso.
c'è da dire che più grosso fosse stato il problema incontrato, più sarebbe stato improbabile incontrarlo (caso estremo: hardware failure che si verifica in tutti i modelli di schede grafiche ATI e che impedisce solo a noi di realizzare il videogioco perché nessun altro se n'è mai accorto; dire che è impossibile è dir poco :D); comunque questo discorso rende bene l'idea di cosa significa "non conoscere la soluzione finale".
io sono appena all'inizio secondo anno, ma già vedo benissimo il tipo di metodo che ci vogliono inculcare nella testa all'università.
Ah. Il waterfall. Che ricordi :D
secondariamente una ragione percui il metodo che ci insegna fek è migliore è che evidentemente ha ragione lui (fek) quando dice che nessuno conosce la soluzione finale fin dall'inizio, ne' il programmatore ne' il "customer" (questo fa parte della terminologia che usiamo nel team del progetto Diamonds ), e quindi semplicemente una progettazione decente all'inizio non è possibile; al diavolo UML.
È ovvio che il committente non conosca la soluzione. Altrimenti non sarebbe venuto da te "programmatore" ad ingaggiarti. Il vero problema è che non sanno quello che vogliono. Peggio ancora, se ti capitera di lavorare per grandi società, le persone con cui parlerai saranno diverse da un giorno all'altro. per farti un esempio Vodafone cambia ogni 6 mesi. Un vero inferno insomma perchè con la gente cambiano anche i requisiti.
ora una parentesi: una cosa che mi chiedo è come si fa in una grande azienda a dimostrare tutto questo? per quali motivi una grande azienda può arrivare a decidere di procedere by refactoring e di abbandonare il suo caro UML? dove stanno i numeri? il giudizio empirico di 71104 e le prediche di fek non bastano: le aziende ragionano a soldi e a numeri. sicchè mi piacerebbe anzitutto sapere questa cosa, chiusa parentesi.
Basta semplicemente tenere uno storico di alcuni indici prestazionali del team. Se durante l'ultimo meeting salta fuori che la nuova metodologia BuGLeZs provata ha dimezzato il numero di codice scritto e raddoppiato il numero di difetti si torna indietro. Tutte le società con un minimo di cervello misurano le prestazioni del processo di sviluppo e cercano di migliorarlo. Cosa che dovrebbero fare anche i programmatori che pero viene considerata peggio della scrittura di documentazione :P
è possibile che in alcuni casi in realtà il metodo di iniziare a scrivere codice solo *dopo* aver progettato *tutto* si riveli più efficiente dell'altro? è possibile che in alcuni casi si abbia fin dall'inizio un'idea estremamente precisa della soluzione finale (possibile in effetti), e che aspetti ancora ignoti si possano chiarire in futuro senza il minimo ritardo nello sviluppo del lavoro?
In genere anche usando metodologie agili un minimo di fase di preparazione ci vuole sempre. Non puoi alzarti alla mattina e dire oggi scrivo Doom 4 altrimenti rischi di comemttere errori gravi con ritardi paurosi. Quando si è familiari con il dominio del problema e si intravede gia la soluzione si lavora incredibilmente meglio con metodologie agili. Si puo evere un prototipo pronto in 1/ 2 giorni da far vedere al cliente che avra gli occhi luccicanti dalla commozione per aver assunto dei Mega-Hackers :D. Se invece anche dopo 2 giorni di colloqui e meeting non si è ancora capito che cavolo dovra fare il prodotto è meglio fermarsi. Oppure anche quando il progetto è piuttosto consistente un progetto con UML con una anlisi della fattibilità è molto meglio farla. Se porti ad una riunione piena di quarantenni inbrillantinati dei fogli con i sorgenti e qualche scansione del K&R ti guarderanno storto e riprenderanno a parlare delle macchinette per il caffè. Se invece gli porti qualche slides con un usecase o un diagramma potrebbero, bada bene, potrebbero capire qualcosa :asd:
ps: ma quante volte hai scritto "fek" in questo messaggio ? :D
ciao ;)
CUTTONE
Secondo me nel tuo pensiero si stanno un pò mischiando i molteplici aspetti della produzione del software: dalla raccolta e analisi dei requisiti fino al testing e deploy.
Innanzitutto è meglio ribadire che UML != progettazione.
Detto questo, la giusta via è anche in questo caso nel mezzo: se il dominio del problema riesce a stare nella testa di una singola persona, questa riuscirà con qualsiasi metodo a lui più congeniale a venirne a capo, ma non appena si aggiunge un'altra persona al team le cose cambiano.
Oltre al problema del 'mi metto a pensarci ad occhi chiusi, butto giù qualcosa su carta o scrivo direttamente il codice', sorge il problema della comunicazione fra gli elementi del team. Personalmente è il problema più costoso e difficile da risolvere.
Senza poi dimenticare l'aspetto manutenibilità: una buona documentazione a tutti i livelli è essenziale in questi casi, altrimenti si finisce per metterci meno a riscrivere il codice tutto da capo piuttosto che cercare di capire il perchè e il percome del suo (non) funzionamento...
Qualche domanda :rolleyes: :confused:
UML è il fatto di mettersi prima su carta e buttare giu tutto il progetto (funzionamento, grafici, diagrammi, etc) per poi passare al codice vero e proprio?
A quanto ho capito in diamonds lavorate a task, ognuno si occupa di una piccola parte basata su dei test, quando è finita (e funzionante) si cerca di sistemare un pò le cose (proprie o altrui) e poi si continua, ho capito bene?
I task come si fanno a definire dall'inizio? Cioè, sotto un progetto di game 2d ok, devo partire dal fatto di creare una finestra, caricare le basi, etc etc, ma per esempio per un'applicazione come si potrebbe iniziare?
E ancora, questo stile dei test è applicabile anche per programmi e quindi non giochi? Come ci si basa per iniziare da un test? Il problema è scriverlo, poi il codice si implementa in modo che non fallisca (penso). Ci sono delle regole da seguire per scriverli?
Cos'è uno spike? :confused: :(
Molto interessante questo metodo, e spero di capirci qualcosa... :rolleyes:
Per ora è tutto (non uccidetemi :cry: )
In genere anche usando metodologie agili un minimo di fase di preparazione ci vuole sempre. Non puoi alzarti alla mattina e dire oggi scrivo Doom 4 altrimenti rischi di comemttere errori gravi con ritardi paurosi. lo so, infatti una certa fase di preparazione era comunque prevista nel mio metodo; sarò più preciso: quello su cui io e il tizio non eravamo d'accordo erano il tipo di considerazioni da fare all'attuale fase progettuale (che è l'inizio): lui è partito in 4 a fare considerazioni di tipo concettuale preso dalla sua ispirazione, mentre io dico che, visto e considerato anche che comunque una certa familiarità con la soluzione già ce l'avevamo entrambi grazie ad alcune prove e ad una versione provvisoria del programma già esistente (che però fa molto poco), si sarebbero dovute selezionare le considerazioni da farsi al momento attuale in base ad un criterio funzionale, e non concettuale. la mia scaletta era questa:
1) versione iniziale
a) progettazione di primo livello (livello di dettaglio basso; abbozzo di idee insomma :))
b) strutturazione e definizione delle priorità (secondo il criterio make it look good, make it
work)
c) implementazione delle varie funzionalità
I) progettazione di secondo livello relativamente alla funzionalità scelta (alto livello di
dettaglio, ma solo relativamente alla funzionalità prioritaria corrente)
II) implementazione della funzionalità
2) aggiunta di una nuova funzionalità
a) progettazione di una strategia di refactoring (spesso questa fase è considerata implicita,
cioè la si fa semplicemente "a mente")
b) preparazione del codice alla nuova aggiunta: refactoring e adattamento
c) implementazione della caratteristica
3) aggiunta di un'altra funzionalità
a) ecc. ...
NB: i punti 2a e 2b vanno minimizzati il più possibile.
nel punto 1a bisognava fare una progettazione a livello puramente funzionale, evitando considerazioni di altro tipo (cioè evitando tutte quelle che invece ha fatto lui). ora si da il caso che questa progettazione funzionale fosse già stata fatta da lui all'inizio del txt che ci siamo passati a turno; io quindi sarei passato dritto dritto al punto 1b: avrei scritto dei numeri accanto ai vari elementi della sua scaletta indicanti la priorità della funzionalità da implementare; successivamente avrei implementato le diverse funzionalità in ordine prioritario.
come puoi leggere nella scaletta, le priorità andavano stabilite in base ad un criterio "first make it look good, then make it work" :)
nel senso che nello stabilire le priorità, ovunque possibile avremmo dovuto dare la precedenza ad aspetti esteriori appetibili dalla nostra utenza.
Quando si è familiari con il dominio del problema e si intravede gia la soluzione si lavora incredibilmente meglio con metodologie agili. verissimo; le ispirazioni vengono più facilmente.
Si puo evere un prototipo pronto in 1/ 2 giorni da far vedere al cliente che avra gli occhi luccicanti dalla commozione per aver assunto dei Mega-Hackers :D. Se invece anche dopo 2 giorni di colloqui e meeting non si è ancora capito che cavolo dovra fare il prodotto è meglio fermarsi. Oppure anche quando il progetto è piuttosto consistente un progetto con UML con una anlisi della fattibilità è molto meglio farla. Se porti ad una riunione piena di quarantenni inbrillantinati dei fogli con i sorgenti e qualche scansione del K&R ti guarderanno storto e riprenderanno a parlare delle macchinette per il caffè. Se invece gli porti qualche slides con un usecase o un diagramma potrebbero, bada bene, potrebbero capire qualcosa :asd: ma LOL, mi mancava questo stereoptipo :rotfl:
ps: ma quante volte hai scritto "fek" in questo messaggio ? :D non sapevo come altro chiamare il "metodo che insegna fek" :D
UML è il fatto di mettersi prima su carta e buttare giu tutto il progetto (funzionamento, grafici, diagrammi, etc) per poi passare al codice vero e proprio? no, UML è un vero e proprio linguaggio usato (da quel pochissimo che ne so per ora) per la formalizzazione del comportamento del programma (la sua progettazione insomma).
A quanto ho capito in diamonds lavorate a task, ognuno si occupa di una piccola parte basata su dei test, quando è finita (e funzionante) si cerca di sistemare un pò le cose (proprie o altrui) e poi si continua, ho capito bene? si: ognuno si prenota per un task, lo svolge cercando di soddisfare i test prescritti da VICIUS o da fek (o almeno in teoria dovrebbe essere così -.-') e al termine tutti fanno un po' di refactoring per migliorare la qualità del codice e uniformarlo un po'.
I task come si fanno a definire dall'inizio? Cioè, sotto un progetto di game 2d ok, devo partire dal fatto di creare una finestra, caricare le basi, etc etc, ma per esempio per un'applicazione come si potrebbe iniziare? in maniera del tutto analoga: prendiamo ad esempio un programma di videoscrittura; i primi task essere più o meno aprire una finestra, metterci la toolbar e i menu, disegnare il foglio nella client area, implementare un caret, e così via...
E ancora, questo stile dei test è applicabile anche per programmi e quindi non giochi? i videogiochi sempre programmi sono...
Come ci si basa per iniziare da un test? Il problema è scriverlo, poi il codice si implementa in modo che non fallisca (penso). infatti è così: uno scrive il test e *dopo* un altro implementa la feature relativa cercando di soddisfarlo e se necessario aggiungendo altri test...
Ci sono delle regole da seguire per scriverli? giusto quelle di JUnit... il test altro non è che codice eseguibile...
Cos'è uno spike? :confused: :( un semplice esperimento di programmazione :)
IMHO anche "il metodo fek" necessita di progettazione... Prima una progettazione d'insieme: vengono individuate le parti topiche del progetto, scelte gli strumenti e le metodologie di programmazione...
Poi la progettazione viene svolta ogni qual volta si scrive una storia e un task... Di fatto è una progettazione continua...e che tiene conto dei problemi che ogni volta si presentano... Ma sono problemi concreti, che la maggior parte delle volte potrebbero non presentarsi durante la progettazione preventiva dei canoni classici dell'ingegneria del software...e di fatto, appena si presentano (perchè bene o male in UML non si potrà mai generare TUTTO il codice) si dovrà ritornare a progettare, magari a sconvolgere l'intero progetto buttando via decine di mesi uomo di programmazione... Stessa cosa per i bug...nella progettazione classica un bug prevede un ritorno alla fase di progettazione e di testing... Con il test driven development un bug corrispondente a trovare un test che fallisce se il bug è presente...dopo si scrive il codice che non fa fallire quel test... Ecco...siamo pronti... Il nostro programma non ha bisogno di ulteriori test (sempre che vengano passati tutti i test)...visto che ci sono sempre gli altri test a garantirmi che la mia correzione non ha introdotto ulteriori bug già testati...
L'unico difetto che si può inputare al "metodo fek" è che il capo del progetto deve essere una persona veramente competente...se questo si verifica il metodo è perfetto... In una progettazione di team (ognuno progetta interamente un componente rispettando delle specifiche) se non sono tutti competenti allo stesso modo si avrà uno sbilanciamento che porterà a perdere moooolto tempo...
71104 : hai ancora visto la progettazione con UML all'uni ? Guarda che arrivi quasi a schematizzare il codice che scrivi...ad un dettaglio che forse non ti immagini... In pratica programmi prima in UML e poi il programma ti genera il codice :)
Uhm, forse è che sono abituato a fare direttamente in maniera visuale per inserire qualcosa (lo sò, è un metodo sbagliato, infatti pian piano sto studiando anche per fare tutto solo da codice)
Però mi sfugge una cosa, qual'è proprio il modo per creare dei test? Cioè, devo pensare e vedere nella palla di cristallo che quel determinato metodo avrà determinati problemi che devo prevedere oppure esiste un modo per creare/pensare in maniera più semplice un test? Se ora ne dovessi scrivere uno non saprei nemmeno da che parte iniziare :stordita: :mbe:
Tornando all'esempio del programma di videoscrittura, quali potrebbero essere dei test iniziali?
fek/vicius mostrateci i vostri arcani poteri... :D
theClimber
14-10-2005, 23:18
... io penso che in effetti qualsiasi metodologia vada bene, purché sia basata su un criterio razionale.......
Quasi ....... ;)
Qualsiasi metedologia va bene se le persone sono sufficientemente capaci di portare a termine il progetto (e quindi soddisfare il cliente, e portare a casa la pagnotta) 'nonostante' questa.
La scopo dei metodi e' di permettere alle persone di dare il meglio, e a seconda dei contesti, ma se chi deve fare il lavoro non e' capace c'e' poco da fare....
Per una analisi relativa all'impatto delle persone vs metodi, puoi dare un occhio a questo articolo:
http://alistair.cockburn.us/crystal/articles/cpanfocisd/characterizingpeopleasnonlinear.html
E' stato scritto dell'autore del libro "Agile Software Development" (http://www.amazon.com/exec/obidos/tg/detail/-/0201699699/qid=1129323548/sr=8-5/ref=pd_bbs_5/104-3273893-9112763?v=glance&s=books&n=507846), che tratta proprio del problema di come "costruire" una metodologia, in un modo magari un po teorico ed accademico, ma sicuramente ricco di spunti interessanti.
L'unico difetto che si può inputare al "metodo fek" è che il capo del progetto deve essere una persona veramente competente...se questo si verifica il metodo è perfetto... In una progettazione di team (ognuno progetta interamente un componente rispettando delle specifiche) se non sono tutti competenti allo stesso modo si avrà uno sbilanciamento che porterà a perdere moooolto tempo...
La situazione riguardo alle skills di livelli diversi non e' cosi' drammatica: tramite pair programming e la condivisione del design e' possibile colmare spesso divari di competenze. Generalmente i problemi peggiori nascono in presenza di personalita' che non sono disposte a dialogare e mettersi in discussione; questo puo' succedere sia in caso di persone "de coccio" sia in caso di "primedonne".
L'uso di metodi agili demolisce il mito del programmatore introverso e non comunicativo e richiede un affinamento delle skills di comunicazione, presentazione, mediazione e interazione personale.
Proprio per quest' ultimo motivo penso che il progetto che state affrontando sia un esperienza utile ed interessante.
Ciao e Buon lavoro :)
io dovrei ringraziare fek per varie cose che ho imparato da lui, sia insegnatemi esplicitamente che implicitamente.
ricordo che in una vecchia discussione si parlava dei metodi di lavoro che insegnano in genere alle università, in particolare di UML e di come questo linguaggio sia utile a formalizzare il funzionamento del software che si vuole creare, fase progettuale secondo molti assolutamente essenziale e da risolversi prima della stesura di qualsiasi riga codice; io sono appena all'inizio secondo anno, ma già vedo benissimo il tipo di metodo che ci vogliono inculcare nella testa all'università.
fek in quella discussione intervenne in un modo che mi piacque molto (adoro quando si scopre che i prof dicono cavolate :D :D :D): se ben ricordo disse più o meno che UML e metodi simili sono roba da... "perbenisti" (mia interpretazione della sua risposta :p) e che in realtà nel lavoro sono richiesti metodi molto più... "agili" e soprattutto produttivi, come ad esempio il metodo che stiamo usando nello sviluppo di Diamonds: refactoring continuo della codebase in base a obiettivi sempre nuovi (gli obiettivi posti dai vari task). apparentemente un metodo molto più lento di quello che insegnano all'università, il quale invece ci dice all'incirca "prima formalizzare e progettare il tutto e poi scrivere codice", ma di fatto non è così: i miei giudizi empirici dicono che è l'esatto opposto; perché? be', innanzitutto il metodo che ci insegna fek ricalca precisamente quella della mente umana, che orientativamente è molto buono: quando un programmatore free-lance fa un programma per conto suo in genere non progetta un bel nulla all'inizio, semplicemente si mette giù a buttar codice e ad aggiungere funzionalità strafiche al suo software; il fatto che poi non arrivi quasi mai molto lontano dipende da due cose:
1) una semplice proporzione: Microsoft Word sta al numero di persone che l'hanno creato (che saranno svariate decine, probabilmente centinaia) come x sta a una sola persona: quanto è grande x? :)
2) la pigrizia: a volte capita che una sola persona si scoccia di fare il programma che aveva inizialmente pensato, perciò semplicemente lo interrompe senza finirlo e non arriva a nulla di concreto; al contrario nelle aziende il lavoro è lavoro, e sei obbligato a farlo.
secondariamente una ragione percui il metodo che ci insegna fek è migliore è che evidentemente ha ragione lui (fek) quando dice che nessuno conosce la soluzione finale fin dall'inizio, ne' il programmatore ne' il "customer" (questo fa parte della terminologia che usiamo nel team del progetto Diamonds :p), e quindi semplicemente una progettazione decente all'inizio non è possibile; al diavolo UML.
ora una parentesi: una cosa che mi chiedo è come si fa in una grande azienda a dimostrare tutto questo? per quali motivi una grande azienda può arrivare a decidere di procedere by refactoring e di abbandonare il suo caro UML? dove stanno i numeri? il giudizio empirico di 71104 e le prediche di fek non bastano: le aziende ragionano a soldi e a numeri. sicchè mi piacerebbe anzitutto sapere questa cosa, chiusa parentesi.
Se ho capito bene,vorresti fare dei programmi software efficenti senza neanche utilizzare un minimo di documentazione UML?
Io invidio chi ci riesce,e stai pur certo che di "luminari" del settore che riescono ad utilizzare extreme programming ce ne sono,ma sono davvero mosche bianche.
Non penso ci si possa illudere di fare dei progetti utilizzando metodologie agili tranne se non si e' sotto determinate condizioni.
Forse meglio chiarirci sul "cosa" intendiamo per metodologie agili;
Un team coordinato da un esperto con la E maiuscola.
Un team che enfatizza il codice alle "scartoffie" di UML.
Un team che a fine giornata deve ottenere dei "build" eseguibili.
Un team che include il customer,in modo da proporgli ogni build realizzato per ottenere un feedback istantaneo.
Un team che fa uso di pair programming avvidendando programmatori ogni due ore in quanto si e' visto che facendo cosi aumenta la qualita' del codice anche se ne risente il tempo di realizzazione.
Ma questo tipo di team impone anche :
- Metafora condivisa,ossia descrivere a tutti il progetto
-Collettivizzazione del codice,ogni persona del team interviene sul codice scritto da altri
-Integrazioni di codice e test frequenti.
E qui ti sorge spontanea la domanda.Ma e' cosi facile creare un team di sviluppo che riesca ad intervenire sul codice scritto da altri e a sviluppare lo stesso progetto software senza fare uso di "scartoffie UML" che descrivano un percorso guida?
Non e' facile,sicuramente puo' esistere, ma trovare delle persone "affiatate" che riescano a realizzare un tipo di progettazione software di questo tipo e' abbastanza difficile da realizzare.
Sicuramente se fossi una azienda e avessi un team del genere,me lo terrei abbastanza stretto :)
P.s. Se ti interessa l'argomento c'e' questo libro Giancarlo Succi, Michele Marchesi, Extreme Programming Examined
Ozn ZzZ: guarda la sottosezione...stiamo proprio facendo un gioco tramite XP + TDD :)
la documentazione in generale è un discorso a parte, quella serve sempre; noi (io :D) abbiamo messo su un thread apposito (Diamonds Knowledge) dove man mano che procede lo sviluppo scriviamo le "cose da sapere", senza contare l'altro thread che già esisteva, sempre sulla documentazione, che contiene documentazione ad un livello un po' più alto.
Poi se non sbaglio anche fek è d'accordo ad utilizzare UML per generare la documentazione alla fine dello sviluppo...e meno male ci sono strumenti che generano tutto in maniera automatica...
*alla fine* però :D
dopo che si sa con precisione che cosa si è fatto ;)
*alla fine* però :D
dopo che si sa con precisione che cosa si è fatto ;)
In che senso "alla fine"?
Che utilita' avrebbe l'uso di UML a fine progetto?
Alla fine la potenzialita' di un linguaggio di modellazione come UML sta proprio nel rendere visibile lo schema concettuale che ogni progettista si fa in testa.Con il livello di dettaglio che riesce a raggiungere nei diagrammi di classi e di sequenza si raggiungono livelli di precisione notevoli.
La cosa che piu' mi ha sorpreso di uml e' la possibilita' di definire automi a stati finiti e le varie interazioni tra oggetti.Nulla e' lasciato al caso e questo tutto prima di scrivere una sola linea di codice
Io penso sia un must per realizzare prodotti solidi.Ma ovviamente e' una mia opinione :)
In che senso "alla fine"?
Che utilita' avrebbe l'uso di UML a fine progetto?
Documentazione dettagliata ;) Tra l'altro è una parte del senso che avrebbe facendolo all'inizio... Perde il significato progettuale, ma mantiene il significato di documentativo...
Documentazione dettagliata ;) Tra l'altro è una parte del senso che avrebbe facendolo all'inizio...
Farlo all'inizio penso sia un supporto che ti eviti "orrori" nella generazione del codice :p .
Come si fa a fare un software per la gestione di un magazzino dell'iperstanda o un virtual store senza fare a monte uno studio concettuale.Il rischio di perdersi per strada penso sia elevatissimo.Si rischia di accorgersi solo alla fine dell'inconsistenza del proprio prodotto
Io penso sia un must per realizzare prodotti solidi.Ma ovviamente e' una mia opinione :)
Ha un livello alto di dettaglio, ma non 1:1 con il codice e soprattutto con le scelte tecniche del codice...questo comporta la perdita di alcuni aspetti che magari verranno alla luce solo al momento della scrittura del codice...con la possibilità di dover obbligatoriamente ritornare alla fase di progettazione, magari dovendo buttare via mesi uomo di coding...
La stessa cosa può avvenire in fase di manutenzione del codice... Nota che progettando il codice con UML bisogna ritornare alla fase di progettazione ogni volta che c'è anche un piccolo bug (ancora di più se il livello di dettaglio è molto alto)...e dopo bisogna nuovamente fare tutta la trafila del testing...
Tutto tempo perso...anche perchè magari correggendo il bug abbiamo reinserito un bug che avevamo corretto tempo fa !!!
Con il TDD non è possibile reinserire bug già corretti precedentemente perchè per ogni bug trovato ci deve essere un test che fallisce se questo viene reintrodotto...
Come si fa a fare un software per la gestione di un magazzino dell'iperstanda o un virtual store senza fare a monte uno studio concettuale.Il rischio di perdersi per strada penso sia elevatissimo.Si rischia di accorgersi solo alla fine dell'inconsistenza del proprio prodotto
XP come dicevo sopra non significa assenza di progettazione, ma signiica farla un po' per volta... Sicuramente quella ad altissimo livello deve essere fatta prima dell'inzio dello sviluppo...
Uhm, forse è che sono abituato a fare direttamente in maniera visuale per inserire qualcosa (lo sò, è un metodo sbagliato, infatti pian piano sto studiando anche per fare tutto solo da codice)
Però mi sfugge una cosa, qual'è proprio il modo per creare dei test? Cioè, devo pensare e vedere nella palla di cristallo che quel determinato metodo avrà determinati problemi che devo prevedere oppure esiste un modo per creare/pensare in maniera più semplice un test? Se ora ne dovessi scrivere uno non saprei nemmeno da che parte iniziare :stordita: :mbe:
Tornando all'esempio del programma di videoscrittura, quali potrebbero essere dei test iniziali?
fek/vicius mostrateci i vostri arcani poteri... :D
Per spike = semplice esperimento di programmazione più nello specifico cosa s'intende?
:confused: :rolleyes:
Giakino: prima di tutto bisogna suddividere il lavoro in storie...
Ad esempio: un prima storia potrebbe essere aprire una finestra usando il framework scelto e visualizzare un dialog con scritto HelloWorld...
La storia va suddivisa in task...per ogni task bisogna studiare i rispettivi test...
Ad esempio, se un task è: creare un dialog con il framework scelto
Il test sarà:
void testDialogCreation()
{
Dialog dialog = new Dialog();
assertFalse(dialog.isCreated()); //questa assertion si può fare bene o male con tutti i framwork
dialog.create();
assertTrue(dialog.isCreated());
dialog.destroy():
assertFalse(dialog.isCreated());
}
Un altro task sarà: visualizzare il messaggio "Hello World!" nel Dialog
Il test sarà:
void testDialogTextDisplay()
{
Dialog dialog = new Dialog();
dialog.setText("Hello World!");
dialog.create();
assertEqual(dialog.getText(), "Hello World!");
dialog.destroy():
assertFalse(dialog.isCreated());
}
end.is.forever
15-10-2005, 23:58
Ho letto un po' di generalizzazioni a mio parere azzardate, dico la mia su quello che penso sia lo sviluppo del software.
Innanzitutto UML non ha niente a che vedere con il processo di sviluppo del software, è un linguaggio che permette di descrivere una grande varietà di sistemi.
La progettazione e il design non sono assolutamente legate ad un linguaggio come l'UML (in molti casi l'output di queste fasi può essere descritto in linguaggio naturale, o con un insieme di interfacce java o di classi o con diagrammi entity-relationship, o con uno schema XML, o anche con un file XML), mi sembra che qui si stia un po' perdendo di vista cosa siano queste fasi nel processo e perchè servano.
Il loro scopo (delle fasi, non dell'UML) è quello di fornire ad altri una descrizione del sistema, non certo quella di fare schemini per noi per non sbagliare dopo o per perdere del tempo.
Ed è anche un ottimo modo per suddividere il lavoro.
Il processo di sviluppo del software è diventato un procedimento industriale, che necessita di formalismi per definire le varie fasi e per suddividere e identificare le responsabilità.
Chi deve costruire un palazzo sicuramente prima di prendere in mano i suoi strumenti (o molto più spesso di dire a qualcun'altro di farlo), sicuramente farà un progetto, e avrà una sua metodologia per pensare cosa fare, ma soprattutto per descrivere a chi lo paga in che modo agirà e perchè ha deciso di optare per una scelta invece che un'altra.
Ovviamente se deve costruire una casetta per cani per i fatti suoi non gli verrà mai in mente di fare una cosa del genere.
Allo stesso modo se io un giorno voglio farmi un programmino per me che mi serve non mi metterò mai a scrivere documenti del genere, ma molto più probabilmente aprirò un qualche ambiente di sviluppo e inizierò a scrivere man mano quello che mi viene in mente.
Ma se un giorno mi commissionassero di realizzare un sistema operativo, un dbms, un software intelligente o quant'altro, di sicuro mi passerebbe per la testa di stabilire prima cosa fare, e di farlo in un modo che permetta a chi mi paga di verificare quello che sto facendo, e a lavoro finito quello che ho fatto.
Senza parlare del fatto che sicuramente cercherei qualcuno che mi aiutasse e farei in modo da potergli descrivere quello che voglio che faccia.
Poi che ci siano diverse metodologie per organizzare il lavoro tra più persone e in più fasi, su questo non c'è dubbio, ma non confondiamo extreme programming con "scrivo codice senza pensare" oppure il processo test-driven con una sorta di debugging anticipato.
Sono metodi ben più articolati, che richiedono altrettanta organizzazione, esperienza e capacità di quelli "vecchio stile".
ma non confondiamo extreme programming con "scrivo codice senza pensare" oppure il processo test-driven con una sorta di debugging anticipato.
Ma chi l'ha scritto questo ?
Come ho detto più volte la progettazione ci deve essere sia all'inizio che durante ogni fase dello sviluppo anche con il metodo che stiamo utilizzando per Diamonds...
Riguardo alle necessità che esprimi nel tuo post...sono tutte rispettate dalla metodologia che applichiamo...
end.is.forever
16-10-2005, 00:20
Ma chi l'ha scritto questo ?
Come ho detto più volte la progettazione ci deve essere sia all'inizio che durante ogni fase dello sviluppo anche con il metodo che stiamo utilizzando per Diamonds...
Riguardo alle necessità che esprimi nel tuo post...sono tutte rispettate dalla metodologia che applichiamo...
Non so nulla del vostro progetto, parlo di quello che mi sembrava essere il tema del topic.
Se poi anche tu sei d'accordo meglio.
Se poi anche tu sei d'accordo meglio.
Certo, l'avevo scritto anche prima :)
Non so nulla del vostro progetto
Dai un'occhiata e magari partecipa :D
@Giakino: quello che ti ha detto cionci è come stiamo facendo noi; il termine "storia" ad es. fa parte della terminologia che usiamo noi, non penso la si usi altrove... :confused: inoltre il codice che ti ha mostrato cionci è scritto in Java (il linguaggio che stiamo usando noi); aggiungo che noi stiamo usando JUnit, un framework che facilita lo sviluppo e l'esecuzione di test automatici.
quindi quello che diceva lui era per fare un esempio pratico, ma nulla toglie che il tutto si possa generalizzare ad altri linguaggi di programmazione e ad altre metodologie di sviluppo (non è mica necessario procedere col "metodo alla fek" per utilizzare il TDD).
se non hai ben capito cos'è uno spike cerco di spiegarmi meglio con un esempio pratico; tornando al programma di videoscrittura, mettiamo che un team vuole svilupparlo solo per Windows (diciamo che il team vuole fare qualcosa di molto simile a Ms Word): se nessuno del team ha mai lavorato con le Win32, sicuramente dovrà fare moltissimi spikes, cioè programmetti per sperimentare le funzionalitàdelle Win32; esempi: un programma Win32 che apra una semplice finestra Windows, un altro programma che sperimenti l'utilizzo di una toolbar con dei pulsanti i cui command id sono associati a quelli di un menu, ecc.
nota bene: le condizioni che ho ipotizzato qui erano solo per poterti fare degli esempio e sono estremamente improbabili: se nessuno del team ha mai lavorato in Win32 è molto difficile che il team possa realizzare qualcosa di grosso, e inoltre nessuno sano di mente userebbe mai Win32 direttamente per creare grossi softwares (Office ad es. è fatto in MFC).
Da quello che è emerso finora mi sembra di capire che per il vostro esperimento stiate proprio battendo la 'via di mezzo': di tutto un pò e solo quando è indispensabile.
Qualche estremista si è presentato e ha detto la sua, ma non ha portato a mio parere argomentazioni convincenti a favore dell'una o dell'altra posizione.
Personalmente faccio il tifo per voi: ho cominciato a fare spikes quattro anni fa e mi ricordate quando ho iniziato a lavorare.
Vorrei però ribadire che per produttività bisogna intendere non solo la risoluzione di obiettivi a breve termine, ma anche tutto il contorno di un progetto. Attualmente sto lavorando anche a progetti cominciati quasi tre anni fa e in tutto questo tempo accadono cose che, per inesperienza, non si sa gestire: nuovi elementi del team che arrivano, altri che lasciano, documentazione insufficiente, errori di progettazione funzionale, cambi in corsa di tecnologie ormai obsolete...
Insomma un pò tutto il discorso mi ricorda la battaglia tra Java e Python per dirne una.
Qualche domanda però devo farvela:
In che fase della vostra metodologia cercate di suddividere l'applicazione in moduli (quasi) indipendenti?
Che politiche/strumenti adottate contro lo spaghetti code e a favore del riutilizzo del codice?
Chi prende le decisioni? :sofico:
cdimauro
17-10-2005, 10:51
Una risposta per tutto: fek. :D
Capito... java lo sto studiando (poco alla volta perchè il tempo è sempre troppo poco :cry: ), poi mi metterò a fare qualche piccolo esperimento. Ora vado alla ricerca di informazioni sull'XP (ho già trovato un sito (http://www.jonathan.cristoforetti.name/programming/xp/xp.html) carino in italiano ) ;)
^TiGeRShArK^
17-10-2005, 20:19
CUT
una cosa ke ancora se non sbaglio è emersa è il massiccio uso di codice auto-commentante...
la finalità dei commenti infatti deve essere di spiegare perchè si fa una certa cosa in un metodo non COSA fa quel metodo.
Quindi è possibile spiegare il COSA fa quel metodo nel modo più semplice:
ovvero utilizzando dei metodi molto spcializzati che abbiano un nome autoesplicativo.
Un passo fondamentale del TDD è infatti il continuo refactoring.
Praticamente la orima cosa da fare è scrivere il test. Quindi si scrive il codice minimo ke fa passare il test e infine si implementa il metodo.
Una volta implementato il metodo però c'è ancora la fase del refactoring.
Infatti il metodo ks ottenuto sarà molto probabilmente MOLTO lontano da essere un codice "bello e funzionale". Così si procede col refactoring come si ritiene più opportuno per rendere il codice più auto-esplicativo possibile, per far si ke una classe svolga uno ed un solo compito (se una classe è troppo grande allora molto probabilmente fa qualkosa di più di quanto gli compete), e per renderlo di più facile comprensione per chi deve leggere il codice.
La cosa bella è ke grazie ai test appena scritti siamo al sicuro, dato ke anke se commettiamo un errore nel refactoring, ce ne accorgiamo subito perchè qualke test fallirà.
Per ulteriori informazioni vi consiglio di dare un okkiata al nostro codice (ma è di pubblico dominio ora ke c penso? :confused: suppongo d si! feeek, viicius, cionciiii! :p) così vi renderete conto di come sia ben strutturato senza aver effettuato alcuna progettazione UML et similia a monte, ma utilizzando bensì una progettazione continua durante tutta la scrittura del codice...
*snip*
La cosa bella è ke grazie ai test appena scritti siamo al sicuro, dato ke anke se commettiamo un errore nel refactoring, ce ne accorgiamo subito perchè qualke test fallirà.
*snip*
E' una lama a doppio taglio... Ma non voglio star qui a discutere di quale sia la migliore strategia, ho già espresso il mio parere.
Da quello che dici vai molto orgoglioso della struttura del codice che sta venendo fuori 'da sola'. Ma finora sembra che col refactoring vi preoccupiate di eliminare lo 'spaghetti-code', ma in quale momento cercate di capire se la struttura ad alto livello è buona o no? Per buona intendo non ridondante, con codice centralizzato, e facilmente manutenibile ed estensibile?
C'è qualcuno che se ne occupa?
E' una lama a doppio taglio... Ma non voglio star qui a discutere di quale sia la migliore strategia, ho già espresso il mio parere.
Da quello che dici vai molto orgoglioso della struttura del codice che sta venendo fuori 'da sola'. Ma finora sembra che col refactoring vi preoccupiate di eliminare lo 'spaghetti-code', ma in quale momento cercate di capire se la struttura ad alto livello è buona o no? Per buona intendo non ridondante, con codice centralizzato, e facilmente manutenibile ed estensibile?
C'è qualcuno che se ne occupa? si, praticamente VICIUS :D
comunque a parte tutto nonostante l'esperienza di Diamonds io non riesco proprio ad apprezzare il valore del TDD: secondo me questi test hanno un costo di manutenzione troppo alto perché ad ogni refactoring i test ovviamente falliscono, e spesso non è il codice che non va, sono proprio i test (vanno mantenuti anch'essi).
se il punto forte di una qualsiasi metodologia è agire poco producendo molto, i test causano esattamente il contrario: fanno agire precisamente il doppio del necessario (se non di più).
i test sono l'unico punto della metodologia di fek sui quali non concordo.
i test sono l'unico punto della metodologia di fek sui quali non concordo.
In pratica non concordi con la metodologia fek in toto...la TDD è il punto fondamentale... Altrimenti non si potrebbe applicare tutto il metodo...
Comunque non è vero che i test hanno bisogno di manutenzione, se ne avessero bisogno allora sono stati scritti male... Inoltre Eclipse aiuta con il refactoring, visto che c'è la possibilità di cambiare il nome ai metodi cambiando automaticamente tutte le occorrenze nel codice... Con questo raramente bisogna rimettere mano ai test...
*snip*
Inoltre Eclipse aiuta con il refactoring, visto che c'è la possibilità di cambiare il nome ai metodi cambiando automaticamente tutte le occorrenze nel codice... Con questo raramente bisogna rimettere mano ai test...
*snip*
TDD: Tool Driven Development :sofico:
TDD: Tool Driven Development :sofico:
IMHO molte metodologie di sviluppo non sono applicabili senza gli adeguati strumenti... Ad esempio fare i diagrammi UML a mano richiederebbe tempi di qualche ordine maggiori rispetto a farli con un tool ad hoc... Stessa cosa per il TDD, senza Eclipse che aiuta nel refactoring bisognerebbe rimettere mano ai test ogni volta che si rinominano i metodi (e a gran parte del codice)...
^TiGeRShArK^
18-10-2005, 12:28
E' una lama a doppio taglio... Ma non voglio star qui a discutere di quale sia la migliore strategia, ho già espresso il mio parere.
Da quello che dici vai molto orgoglioso della struttura del codice che sta venendo fuori 'da sola'. Ma finora sembra che col refactoring vi preoccupiate di eliminare lo 'spaghetti-code', ma in quale momento cercate di capire se la struttura ad alto livello è buona o no? Per buona intendo non ridondante, con codice centralizzato, e facilmente manutenibile ed estensibile?
C'è qualcuno che se ne occupa?
ovviamente col refactoring intendevo anke l'eliminazione delle duplicazioni e delle ridondanze, anzi questo è uno dei punti principali, soprattutto all'interno dei test.
Inoltre queste operazioni dovrebbero essere un pò tutti a farle...
vista l'elevata leggibilità del codice chiunque può mettere mano al codice quando vede qualcosa ke non lo convince e effettuare del refactoring per migliorarne la struttura.
dimenticavo un messaggio subliminale:
LEGGETE EXTREME PROGRAMMING ADVENTURES IN C# :D
IMHO molte metodologie di sviluppo non sono applicabili senza gli adeguati strumenti... Ad esempio fare i diagrammi UML a mano richiederebbe tempi di qualche ordine maggiori rispetto a farli con un tool ad hoc... Stessa cosa per il TDD, senza Eclipse che aiuta nel refactoring bisognerebbe rimettere mano ai test ogni volta che si rinominano i metodi (e a gran parte del codice)...
Ovviamente concordo in pieno. :mano:
Inoltre abbiamo dei canoni strettissimi di complessità da rispettare per metodi e classi (addirittura per le espressioni)...e questo permette una elevata leggibilità del codice...
Se questi canoni non sono rispettati la build con ant fallisce e quindi fino a quando non si sono raggiunti i canoni non dovrebbe essere fatto il commit...
leadergl
18-10-2005, 12:43
sto seguendo con molto interesse questa discussione ed il progetto, Diamonds, su cui state lavorando...però volevo farvi alcune domande...
sono studente in informatica e quindi queste cose mi interessano abbastanza così come scrivere del codice leggibile, veloce e stabile.
Nel privato uso VisualBasic, all'univ ho usato Pascal ed adesso mi sto avvicinando a C..quindi prendo ad esempio il VisualBasic.
Quando creo una funzione od una procedura per un mio programma in VisualBasic come faccio a scrivere il relativo codice di test? e come faccio a testare la relativa funzione?
Non posso farlo con la generazione dell'eseuguibile...dovrei farlo in debugging? ma non perderei una marea di tempo? ...si insomma con quale metodologia creo ed eseguo codice di test per i miei algoritmi VisualBasic?
so che forse sono leggermente OT e mi scuso...però credo che bene o male possa far parte della discussione...
si, praticamente VICIUS :D
comunque a parte tutto nonostante l'esperienza di Diamonds io non riesco proprio ad apprezzare il valore del TDD: secondo me questi test hanno un costo di manutenzione troppo alto perché ad ogni refactoring i test ovviamente falliscono, e spesso non è il codice che non va, sono proprio i test (vanno mantenuti anch'essi).[...]
Se facendo un piccolo refactoring falliscono troppi test vuol dire che c'è qualcosa che non va. Un campanello d' allarme che ti dice che forse devi guardare meglio quello che stai facendo.
ciao ;)
Se facendo un piccolo refactoring falliscono troppi test vuol dire che c'è qualcosa che non va. Un campanello d' allarme che ti dice che forse devi guardare meglio quello che stai facendo.
Probabilmente intende refactoring pesanti, come togliere aggiungere funzionalità ad un metodo o una classe...
Probabilmente intende refactoring pesanti, come togliere aggiungere funzionalità ad un metodo o una classe...
I refactoring pesanti non dovrebbero mai capitare. TDD è una metodologia agile e consiglia di fare piccoli passi, procedere lentamente senza mai fermarsi invece di grossi salti nel buio. Certo a volte capitano ma sono sicuramente mosche bianche. In ogni caso è proprio quando capitano questi rari casi che i test vengono piu utili.
Se a progetto finito il committente ti chiede di cambiare l'unita di misura in tutto il progetto, oltre a lanciare qualche madonna e a pensare a quanti euro in piu chiedere, come reagisci? Con i test puoi fare le tue modifiche e lanciarli per vedere tutte le aree che sono affette. Senza non ti resta che accendere un cero al santo patrono dei debugger e sperare che non ci siano strani side-effects.
ciao ;)
se il punto forte di una qualsiasi metodologia è agire poco producendo molto, i test causano esattamente il contrario: fanno agire precisamente il doppio del necessario (se non di più).
i test sono l'unico punto della metodologia di fek sui quali non concordo.
Preferisco la meta del codice e la quasi certezza di non avere bug che il doppio ed il perenne rischio di dover usare gdb da console. :D
ciao ;)
*snip*
ed il perenne rischio di dover usare gdb da console.
*snip*
Quello, seppur ridotto dalla qualità e quantità dei test (e anche qui ci sarebbe parecchio da discutere), rimane comunque perenne.
In medio stat Vicius.
Angus: quel "tanto da discutere" lo possiamo anche fare qui... E' stato aperto appositamente questo thread ;) Dai che sono curioso...esprimi tutti i tuoi dubbi su ogni punto...
Come accennavi qualche post fa, i test vanno innanzitutto scritti *bene*.
Invito chi fosse interessato a leggere CCA (http://www.bullseye.com/coverage.html), che descrive le problematiche che riguardano la misura della qualità dei test e se gli stessi sono sufficienti a garantire un basso richio di bug. Per esempio esistono tool che cercano di scovare le parti di codice non coperte da test.
Il TDD secondo me è molto utile dal punto di vista funzionale, mentre un buon linguaggio e un buon compilatore possono ovviare a tanti strafalcioni di programmazione. Un esempio della discussione infinita si trova qui (http://osteele.com/archives/2003/08/test-versus-type).
Imho una strategia vincente in assoluto non c'è, ma va scelta quella giusta caso per caso, o meglio ancora vanno utilizzate tutte in modiche quantità ;-)
ps: pensavo che il thread riguardasse principalmente l'organizzazione di un gruppo di lavoro, mea culpa.
ps: pensavo che il thread riguardasse principalmente l'organizzazione di un gruppo di lavoro, mea culpa.
Sì...inizialmente...ma diciamo che in parte le metodologie di sviluppo come la TDD coprono anche questo...
Riguardo ai tool per scoprire il codice non coperto da test... Se non sbaglio VICIUS sta usando un software di questo tipo...
Se a progetto finito il committente ti chiede di cambiare l'unita di misura in tutto il progetto, oltre a lanciare qualche madonna e a pensare a quanti euro in piu chiedere, come reagisci? Con i test puoi fare le tue modifiche e lanciarli per vedere tutte le aree che sono affette. Senza non ti resta che accendere un cero al santo patrono dei debugger e sperare che non ci siano strani side-effects. ad ogni modo: con i test devi modificare una marea di codice (i test appunto) e un'altra marea di codice (il programma vero e proprio); in entrambi potresti commettere degli errori.
senza i test le due maree di codice da modificare diventano una marea sola.
imho.
Preferisco la meta del codice e la quasi certezza di non avere bug che il doppio ed il perenne rischio di dover usare gdb da console. :D mi sa che hai scambiato "metà" e "doppio" :D
senza i test le due maree di codice da modificare diventano una marea sola.
Piena di errori...e con la possibilità di metterci più del doppio a risolverli, se non se ne introducono di nuovi correggendoli...
ad ogni modo: con i test devi modificare una marea di codice (i test appunto) e un'altra marea di codice (il programma vero e proprio); in entrambi potresti commettere degli errori.
senza i test le due maree di codice da modificare diventano una marea sola.
imho.
Certo anche i test sono codice quindi rischiano di essere difettosi. Dovrai ammettere che è infinitamente piu facile trovare un bug in un test come questo.
public void testFibonacciDiZero()
{
assertEquals(0, fibonacci(0));
}
Che in una ipotetica funzione ricorsiva che viene testata. Non che serva la ricorsione per far passare questo test. :D
ciao ;)
mi sa che hai scambiato "metà" e "doppio" :D
Supponi di essere in grado di scrivere in media mille linee di codice al giorno.
Suponi ora che le linee di codice usate dai test siano circa il 50%.
Le linee di codice utili per il progetto sono quindi la meta.
Procedendo senza scrivere i test sarebbero, invece, mille linee utili. 100%. Quindi il doppio.
ciao ;)
Verba volant...
Vorrei sperare che il thread non si riduca ad uno sterile 'io ce l'ho più grosso del tuo'.
In cosa una metodologia è migliore di un'altra? A parità di software prodotto direi che è il tempo impiegato. Ma come si misura il tempo impiegato? In giorni/uomo? Non credo che sia una misura affidabile. Più i progetti sono grandi più le metodologie di sviluppo si inseriscono in un contesto di gestione delle risorse molto più ampio.
Come scala il TDD (per esempio) all'aumentare delle persone e al diminuire del tempo (quello vero) a disposizione?
I discorsi fatti negli ultimi post sembrano invece affrontare il problema dal punto di vista probabilistico o statistico:
C'è una fazione che afferma che il codice totale scritto mediante TDD è sì più lungo (ma di quanto?) del codice scritto senza TDD, ma contiene statisticamente meno errori perchè 'autoreferenziato' e quindi (?) di migliore qualità. L'altra fazione afferma che invece probabilisticamente il doppio del codice contiene semplicemente il doppio degli errori o anche più.
Non mi sembra un approccio corretto.
Bisogna dare atto al TDD che porta dei vantaggi in fase di refactoring per controllare che quello che funzionava prima delle modifiche continui a funzionare. Per funzionare intendo proprio l'aspetto funzionale del codice, non la sua correttezza sintattica/semantica che può essere controllata da un buon compilatore o strumento analogo. Non lo vedo invece come alternativa alle fasi di progettazione, che anche se solo su carta rimane indispensabili in progetti di medie/grandi dimensioni e aiuterebbe la stesura di test mirati ed efficienti, che non richiedano a loro volta continui refactoring.
Credo che finora il TDD abbia faticato ad emergere semplicemente perchè i framework attuali non sono stati accompagnati da tool all'altezza. Col tempo mi aspetto che il TDD diventi una cosa talmente naturale e automatizzata da fare che non ci renderemo neanche più conto di usarlo.
Ora sto decisamente vaneggiando, mi fermo qui.
Angus: le tue considerazioni sono tutte giuste...senza ombra di dubbio... Sulla questione "misure", per ora mi sto basando su quello che vedo con Diamonds, e di conseguenza non ho ancora studiato niente su TDD e XP, quindi per ora ho le conoscenze di un corso base di ingegneria del software (in cui non si facevano TDD e XP)...
Angus: le tue considerazioni sono tutte giuste...senza ombra di dubbio... Sulla questione "misure", per ora mi sto basando su quello che vedo con Diamonds, e di conseguenza non ho ancora studiato niente su TDD e XP, quindi per ora ho le conoscenze di un corso base di ingegneria del software (in cui non si facevano TDD e XP)...
Dove lavoro facciamo largo uso di XP, ma solo perchè finora siamo stati quattro gatti a programmare seriamente. Nell'immediato futuro dovrò affrontare la crescita dei progetti ed aspetti che tempo fa non avevo minimamente preso in considerazione, come la manutenibilità del software da parte di persone che non ne hanno mai scritta una sola riga. Anche io mi baso solo su studi universitari e per la gran parte su quello che leggo in rete. Ho provato alcuni framework per il TDD ma non potevo permettermi il loro costo iniziale (in termini di tempo). Dovresti però aver incontrato di sfuggita, durante il corso di ingegneria del sw, almeno la teoria del Code Coverage. O ti hanno rimpinzato di UML e basta? A tal proposito:
Ma dove li mettiamo i Design Patterns? Voi diamanti ne fate uso? E chi è il vostro pusher? :sofico:
Ma dove li mettiamo i Design Patterns? Voi diamanti ne fate uso? E chi è il vostro pusher? :sofico:
Si c'è qualcosa ma è nascosto nei menadri del codice. Il pusher per ora è un vacanza dovrebbe tornare questa sera :asd:
ciao ;)
In cosa una metodologia è migliore di un'altra? A parità di software prodotto direi che è il tempo impiegato. Ma come si misura il tempo impiegato? In giorni/uomo? Non credo che sia una misura affidabile.
Di certo con una sola misura non si puo capire molto. Ce ne sono decine. Ci si deve mettere li e decidere quali sono quelle che si ritengono piu importanti da usare per fare un confronto.
Più i progetti sono grandi più le metodologie di sviluppo si inseriscono in un contesto di gestione delle risorse molto più ampio.
Come scala il TDD (per esempio) all'aumentare delle persone e al diminuire del tempo (quello vero) a disposizione?
A questo non so rispondere. Non ho mai lavorato in un grande team che facesse uso di TDD o altre tecniche XP. Ma devo ammettere che mi piacerebbe.
I discorsi fatti negli ultimi post sembrano invece affrontare il problema dal punto di vista probabilistico o statistico:
Ci sono altri modi? Un processo è qualcosa di troppo astratto influenzato da troppi fattori per essere misurato da una formula matematica.
ciao ;)
O ti hanno rimpinzato di UML e basta? A tal proposito:
Ma dove li mettiamo i Design Patterns? Voi diamanti ne fate uso? E chi è il vostro pusher? :sofico:
Niente Code Coverage, se ricordo bene...UML (gran parte del corso), le metodologie di sviluppo classiche e i Design Patterns...ma era mezza annnualità...
^TiGeRShArK^
18-10-2005, 21:44
come la manutenibilità del software da parte di persone che non ne hanno mai scritta una sola riga.
boh...
io su questo posso solo portare la mia personale esperienza....
durante la storia precedente (quella andata a buon fine N.d.A.) ho fatto un paio di task...
il codice ovviamente l'avevo già visto prima, ma quando sono andato a riprenderlo era completamente cambiato dall'ultima volta.... praticamente rimanevano invariati solo i nomi di "alcune" classi e il funzionamento generale del software...
ebbene.. mi è venuto molto semplice andare a studiare quel codice e vedere dove andava fatto il mio intervento per sviluppare i task...
inoltre, grazie all'uso dei test, mi sono subito accorto ke era stata fatta una confusione sulle coordinate utilizzate.... infatti credo ke la maggior parte di noi siano abituati a pensare con l'origine posta in alto a sinistra... in Open GL invece l'origine è posta in basso a sinistra...
dopo aver modificato il software per aggiungere il mio task ho subito visto che il test che falliva era quello opposto (falliva lo spostamento verso il basso anzikè quello verso l'alto).
In questo modo sono riuscito a tracciare abbastanza in fretta il bug e a porvi soluzione... non oso immaginare se fossimo stati senza test quanto tempo sarebbe occorso prima di tracciare TUTTE le occorrenze del bug e porvi rimedio......
Morale della favola... almeno per quanto ho visto io il codice ottenuto è facilmente leggibile anche da ki non ha mai messo mani al codice e soprattutto la fase di debug è codiuvata dai test, aiuto ke spesso può risultare provvidenziale (e lo so bene dato ke al lavoro stiamo procedendo senza test... :muro: e con parti di codice scritte praticamente in aramaico da qualcuno......Credo ke se avessimo applicato questa metodologia anke lì tutto sarebbe stato + facile)
my two centu liri! ;)
dimenticavo... se alla toughtworks spingono molto su questa metodologia di sviluppo credo ke sia una delle migliori ad oggi esistente (se non la migliore :p)
Angus: ti va di dare un'occhiata al nostro repository, se vai nella sottosezione ci sono tutte le istruzioni ;)
Angus: ti va di dare un'occhiata al nostro repository, se vai nella sottosezione ci sono tutte le istruzioni ;)
Certo che mi va! Ho evitato di farlo finora perchè in ufficio sono assediato dai turchi (analisti funzionali) e la prossima scadenza è venerdì :(
Invece il pc di casa è ancora inballato per il trasloco in corso :cry:
Tornando un pò all'argomento, oggi ho visto un libro che a prima vista m'ispira molto, qualcuno lo conosce?
"Ingegneria del codice" di Steve McConnell
http://education.mondadori.it/Libri/SchedaLibro.asp?IdLibro=88-04-54034-6
Interessato ai vari commenti...prima di spendere (eventualmente inutilmente) 80 eu
Che poi ho anche letto su un libro di uml che XP è una cosa "pericolosa" per il fatto che c'è poca progettazione inizialmente e si "butta" codice così come capita :doh: Ma che comunque (XP) può andar bene per piccoli/medi progetti con team di alto livello e organizzazione al massimo...
Tornando un pò all'argomento, oggi ho visto un libro che a prima vista m'ispira molto, qualcuno lo conosce?
"Ingegneria del codice" di Steve McConnell
http://education.mondadori.it/Libri/SchedaLibro.asp?IdLibro=88-04-54034-6
Interessato ai vari commenti...prima di spendere (eventualmente inutilmente) 80 eu
Che poi ho anche letto su un libro di uml che XP è una cosa "pericolosa" per il fatto che c'è poca progettazione inizialmente e si "butta" codice così come capita :doh: Ma che comunque (XP) può andar bene per piccoli/medi progetti con team di alto livello e organizzazione al massimo... l'autore di quel libro non conosce fek :Prrr:
Ehehe, probabile :D
Parteciperei volentieri a diamonds, mi piace come cosa. L'unico problema è che attualmente il tempo a disposizione è sempre pochissimo e comunque sono ancora in fase di studio di java, che dato il tempo procede lento :cry:
Attendo poi commenti per l'altro libro :p
Tornando un pò all'argomento, oggi ho visto un libro che a prima vista m'ispira molto, qualcuno lo conosce?
"Ingegneria del codice" di Steve McConnell
http://education.mondadori.it/Libri/SchedaLibro.asp?IdLibro=88-04-54034-6
Interessato ai vari commenti...prima di spendere (eventualmente inutilmente) 80 eu
Che poi ho anche letto su un libro di uml che XP è una cosa "pericolosa" per il fatto che c'è poca progettazione inizialmente e si "butta" codice così come capita :doh: Ma che comunque (XP) può andar bene per piccoli/medi progetti con team di alto livello e organizzazione al massimo...
Spettacolare come libro. Da leggere assolutamente. Anche se forse 80€ mi sembrano veramente troppi. Io l'ho pagato circa 28 sterline.
ciao ;)
io dovrei ringraziare fek per varie cose che ho imparato da lui, sia insegnatemi esplicitamente che implicitamente.
Non avevo letto prima, che bel complimento, grazie :)
Spettacolare come libro. Da leggere assolutamente. Anche se forse 80€ mi sembrano veramente troppi. Io l'ho pagato circa 28 sterline.
ciao ;)
Azz...28 £ --> circa 41 € :eek: :eek: :eek:
Il problema sarebbe solo che in inglese ci metterei una vita per capire fuori qualcosa, quindi a questo punto meglio in italiano...anche se dovrei iniziare a leggere un pò di manuali in inglese, fanno solo bene..
A parte il prezzo (forse un pò esagerato), quindi mi consigli di prenderlo ? Hai trovato qualcosa di scritto con cui non sei proprio d'accordo (es dice una cosa quando in realtà non è così et similiar)?
Il grande fek, che onore averti in questo topic :D A questo punto però attendo anche tuoi commenti su tutto :Prrr:
Se ho capito bene,vorresti fare dei programmi software efficenti senza neanche utilizzare un minimo di documentazione UML?
Si'. L'unica documentazione sempre aggiornata il codice. Il resto e' documentazione sempre e comunque non aggiornata, che ha un costo mantenere e che non fornisce alcun valore al cliente.
Io invidio chi ci riesce,e stai pur certo che di "luminari" del settore che riescono ad utilizzare extreme programming ce ne sono,ma sono davvero mosche bianche.
Non sono proprio mosche bianche, diciamo che pian piano stanno diventando la maggioranza, a partire da:
http://www.thoughtworks.com/index.html
In pochissimi anni e' passata dall'essere una piccola azienda di software all'essere una multinazionale con sedi in tutto il pianeta. E usano solo metodologie agili di sviluppo.
Non penso ci si possa illudere di fare dei progetti utilizzando metodologie agili tranne se non si e' sotto determinate condizioni.
Io penso che non ci si possa illudere di fare dei progetti di una certa qualita' con la speranza di consegnargli in tempo e di dare valore al cliente cercando di progettare tutto a priori, magari attraverso documenti UML ed una metodologia Waterfall. A parte in rarissimi casi, quando le specifiche sono immutabili e perfettamente formalizzate. Ovvero in una strettissima minoranza dei casi, e di solito non in situazioni di mercato, dove l'economia stessa impone continui cambiamenti ai requisiti, tali da rendere anti economiche metodologie di sviluppo con una curva dei costi classica.
Io non so al giorno d'oggi quale sia il cliente che preferisca spendere soldi per mesi senza vedere uno straccio di applicazione, ma solo gran documentazione che non gli risolve alcun problema. L'alternativa e' vedere un'applicazione che inizia a risolvergli i problemi fin dal primo ciclo, dopo un paio di settimane.
E qui ti sorge spontanea la domanda.Ma e' cosi facile creare un team di sviluppo che riesca ad intervenire sul codice scritto da altri e a sviluppare lo stesso progetto software senza fare uso di "scartoffie UML" che descrivano un percorso guida?
Se pensi che un gruppo di ragazzi sostanzialmente alle prime armi in quanto a programmazione, guidati da me che non ho certo grande esperienza da Coach, ci riesce piuttosto bene proprio su questo forum, devo dire che non e' cosi' difficile mettere in pratica un po' di XP :)
P.s. Se ti interessa l'argomento c'e' questo libro Giancarlo Succi, Michele Marchesi, Extreme Programming Examined
Ce n'e' un altro interessante: Extreme Programming Refactored, che in sintesi nega ogni singola pratica dell'XP. Una lettura utile.
Farlo all'inizio penso sia un supporto che ti eviti "orrori" nella generazione del codice :p .
Come si fa a fare un software per la gestione di un magazzino dell'iperstanda o un virtual store senza fare a monte uno studio concettuale.Il rischio di perdersi per strada penso sia elevatissimo.Si rischia di accorgersi solo alla fine dell'inconsistenza del proprio prodotto
E' l'esatto contrario invece. Nessun cliente capisce uno schema UML per quanto dettagliato e non e' in grado di sapere se il design stesso ricalca i suoi bisogni, risolve i suoi problemi, segue le sue specifiche (che spesso neppure e' in grado di formulare correttamente). E se dopo mesi passati a scrivere documentazione e design ci si aggorge che il design non risolve il problema perche' alla prima demo il cliente esce con un: "ma non e' quello che chiedevo io"?
Si butta tutto e si riparte.
E se cambiano le specifiche perche' cambia il mercato?
Si butta tutto e si riparte.
Al contrario, se il cliente vede ogni due settimane un'applicazione con la quale puo' sperimentare e "giocare", e' in grado di capire immediatamente se l'applicazione si sta indirizzando verso il suo obiettivo o meno. E puo' dare indicazioni tempestive per "guidare" il resto dello sviluppo. E puo' cambiare le specifiche sapendo che il team di sviluppo adotta pratiche tali da appiattire la curva dei costi e cambiare il design a costi virtualmente costanti durante tutto l'arco dello sviluppo.
E' semplicemente un modo piu' economico di scrivere software piu' robusto e che corrisponde alle richieste del cliente.
Chi deve costruire un palazzo sicuramente prima di prendere in mano i suoi strumenti (o molto più spesso di dire a qualcun'altro di farlo), sicuramente farà un progetto, e avrà una sua metodologia per pensare cosa fare, ma soprattutto per descrivere a chi lo paga in che modo agirà e perchè ha deciso di optare per una scelta invece che un'altra.
Esempio classico: quando si costruisce un ponte, lo si progetta fin nei minimi dettagli e poi lo si costruisce. Ed e' un procedimento che funziona da centinaia di anni.
Ma... scrivere software non e' come costruire un ponte :)
E' un procedimento totalmente differente, perche' le specifiche dei ponti o delle case non cambiano in continuazione, i requisiti sono facilmente formalizzabili, i calcoli delle tempistiche sono anch'essi legati a formule piuttosto precise.
Tutto questo nel software non esite, se non in situazioni particolari e infrequenti. Le specifiche nel software cambiano in continuazione, i requisiti si modificano, non solo, nella maggior parte dei casi non possono essere formalizzati, perche' neppure il cliente li conosce fino a che non vede l'applicazione girare.
La sintesi e': non si puo' costruire un software come si costruisce un ponte perche' sono "oggetti" inerentemente differenti e necessitano di metodologie differenti. Nel software servono metodologie che permettano di calcolare in maniera il piu' precisa possibile il costo di sviluppo a partire dalle specifiche del cliente che mutano in continuazione. Dev'essere possibile dire al cliente "Se tu vuoi questo nelle prossime due settimane, ti costa questo, se vuoi quello, ti costa quello, quello in due settimane non e' possibile, o lo dividi o chiedi altro". Sulla base di questi dati il cliente sceglie di volta in volta le feature che rappresentano per lui il maggior valore economico a fronte della spesa.
Nel software non funziona dire "Tu vuoi l'applicazione che faccia tutto questo e io te la faccio in 6 mesi". Che poi diventano 12 e all'ottavo mese il cliente smette di pagare e va da un'altra parte...
E' una lama a doppio taglio... Ma non voglio star qui a discutere di quale sia la migliore strategia, ho già espresso il mio parere.
Da quello che dici vai molto orgoglioso della struttura del codice che sta venendo fuori 'da sola'. Ma finora sembra che col refactoring vi preoccupiate di eliminare lo 'spaghetti-code', ma in quale momento cercate di capire se la struttura ad alto livello è buona o no? Per buona intendo non ridondante, con codice centralizzato, e facilmente manutenibile ed estensibile?
C'è qualcuno che se ne occupa?
Ce ne occupiamo principalmente io e Vicius che abbiamo un'idea "molto generale" del design globale. Sappiamo dall'esperienza che la game logic deve essere separata dall'engine logic, ma non ci spingiamo oltre. Il codice ci dice "come vuole essere sistemato" in base alle specifiche che il Customer ci da' e il suo input al termine di ogni Ciclo (input a partire dall'applicazione che esamina).
Ad ogni punto noi guardiamo lo stato del progetto e cerchiamo di semplificarlo, magari mi accorgo che un certo numero di classi inizia ad assomigliare ad un qualche Design Pattern ed a quel punto inizio un refactoring che diriga il codice verso quel Design Pattern (non lo impongo a priori), perche' so che quel DP mi da' alcuni vantaggi e mi semplifica la struttura logica magari.
E' un design continuo (si chiama evolutivo). Usare una metodologia agile non significa non fare design, ma significa farlo in continuazione ad ogni passo dello sviluppo, e capire come il codice vuole essere strutturato.
Questo articolo di Martin Fowler spiega il concetto molto meglio di come posso fare io:
http://www.martinfowler.com/articles/designDead.html
(Lui e' un pochino piu' bravo di me come divulgatore :p)
Credo che finora il TDD abbia faticato ad emergere semplicemente perchè i framework attuali non sono stati accompagnati da tool all'altezza. Col tempo mi aspetto che il TDD diventi una cosa talmente naturale e automatizzata da fare che non ci renderemo neanche più conto di usarlo.
Ora sto decisamente vaneggiando, mi fermo qui.
Verissimo. Fare TDD in C++ senza tool di refactoring decenti ad esempio (Ref++ e' ok, ma non all'altezza dei tool di refactoring di Java), il framework di unit testing me lo sono scritto da solo (in TDD :p), non e' certo una passeggiata al parco ed inizia a non essere cosi' attraente rispetto a metodologie piu' classiche. Il C++ e' una brutta bestia.
Ma quando si passa a Java (C#/SmallTalk/etc), i costi di refactoring crollano grazie ai tool, i costi di unit testing sono bassissimi e i benefici dell'avere test che non solo aiutano il refactoring ma documentano il codice stesso, formalizzano i requisiti, comunicano i bug. Tanti vantaggi per un po' di codice in piu' :)
The3DProgrammer
22-10-2005, 00:59
E' l'esatto contrario invece. Nessun cliente capisce uno schema UML per quanto dettagliato e non e' in grado di sapere se il design stesso ricalca i suoi bisogni, risolve i suoi problemi, segue le sue specifiche (che spesso neppure e' in grado di formulare correttamente). E se dopo mesi passati a scrivere documentazione e design ci si aggorge che il design non risolve il problema perche' alla prima demo il cliente esce con un: "ma non e' quello che chiedevo io"?
Si butta tutto e si riparte.
E se cambiano le specifiche perche' cambia il mercato?
Si butta tutto e si riparte.
Al contrario, se il cliente vede ogni due settimane un'applicazione con la quale puo' sperimentare e "giocare", e' in grado di capire immediatamente se l'applicazione si sta indirizzando verso il suo obiettivo o meno. E puo' dare indicazioni tempestive per "guidare" il resto dello sviluppo. E puo' cambiare le specifiche sapendo che il team di sviluppo adotta pratiche tali da appiattire la curva dei costi e cambiare il design a costi virtualmente costanti durante tutto l'arco dello sviluppo.
E' semplicemente un modo piu' economico di scrivere software piu' robusto e che corrisponde alle richieste del cliente.
e vallo a spiegare ad alcuni prof universitari!!
ho dovuto fare un annetto fa un progetto di sistema informativo (solo design UML e database, con qualke maskera x l'anagrafica ecc) proprio mentre in quel periodo stavo sviluppando un gestionale three tier x un'azienda milanese (High medical technologies SRL) con MFC/DAO 3.5. Con poseidon ne è venuto fuori un file da 20 MB su cui ho lavorato 3 mesi x realizzare il design di un sottoinsieme delle funzionalità del sw che stavo realizzando (ricordo che il prof pretendeva 3 modelli, uno di business in cui si valutavano le effettive richieste del cliente con annessa catena del valore di Porter ed altre amenità varie, modello concettuale e realizzativo). Conclusioni: ho terminato prima il sw che il progetto :asd:
cmq, oggettivamente, a posteriori devo dire che a qualkosa è servito, anche se IMHO un lavoro del genere prima dello sviluppo vero è proprio è improponibile
e vallo a spiegare ad alcuni prof universitari!!
ho dovuto fare un annetto fa un progetto di sistema informativo (solo design UML e database, con qualke maskera x l'anagrafica ecc) proprio mentre in quel periodo stavo sviluppando un gestionale three tier x un'azienda milanese (High medical technologies SRL) con MFC/DAO 3.5. Con poseidon ne è venuto fuori un file da 20 MB su cui ho lavorato 3 mesi x realizzare il design di un sottoinsieme delle funzionalità del sw che stavo realizzando (ricordo che il prof pretendeva 3 modelli, uno di business in cui si valutavano le effettive richieste del cliente con annessa catena del valore di Porter ed altre amenità varie, modello concettuale e realizzativo). Conclusioni: ho terminato prima il sw che il progetto :asd:
cmq, oggettivamente, a posteriori devo dire che a qualkosa è servito, anche se IMHO un lavoro del genere prima dello sviluppo vero è proprio è improponibile
Lo feci anch'io per l'esame di Ingegneria del Software II: sei mesi di analisi dei requisiti, documenti, diagrammi UML, senza una riga di codice, perche' la professoressa si vantava di questa peculiarita'.
E' stato un esame utilissimo perche' mi ha insegnato fondamentalmente due cose: il software non si costruisce in quel modo, e le donne non devono costruire software :)
jappilas
22-10-2005, 01:15
Lo feci anch'io per l'esame di Ingegneria del Software II: sei mesi di analisi dei requisiti, documenti, diagrammi UML, senza una riga di codice, perche' la professoressa si vantava di questa peculiarita'.
E' stato un esame utilissimo perche' mi ha insegnato fondamentalmente due cose: il software non si costruisce in quel modo, e le donne non devono costruire software :)
stessa cosa che mi ha suggerito il fatto di avere avuto una donna a Fondamenti d' Informatica II ... :mano:
la nozione te la posso generalizzare così, e bada bene solo per esperienza personale, non sono maschilista: le donne che programmano fanno ridere :D
prova a leggere i sorgenti scritti da una donna, fanno ridere per davvero, sono tutti incasinati :D indentazione completamente sballata, errori dappertutto... :D
la mia esercitatrice di Algoritmi 1 è una perfetta scema che dice che alle sue lezioni lei programma in pseudocodice perché non vuole perdere tempo a ragionare sulla sintassi del C... MA CHE RAZZA DI DISCORSO, si vede benissimo che è na sega :rotfl: :rotfl:
oltrettutto lo pseudolinguaggio che usa lei è tutto particolare... vabbè va', velo pietoso...
Non avevo letto prima, che bel complimento, grazie :) di niente, lo meriti: grazie a te un programmatore nel mondo è diventato più produttivo :sofico:
porti sempre argomenti interessanti sul forum, e anche quando non sono d'accordo su quello che dici mi fai comunque ragionare, e questo non fa mai male a nessuno ;)
E' l'esatto contrario invece. Nessun cliente capisce uno schema UML per quanto dettagliato e non e' in grado di sapere se il design stesso ricalca i suoi bisogni, risolve i suoi problemi, segue le sue specifiche (che spesso neppure e' in grado di formulare correttamente). E se dopo mesi passati a scrivere documentazione e design ci si aggorge che il design non risolve il problema perche' alla prima demo il cliente esce con un: "ma non e' quello che chiedevo io"?
Si butta tutto e si riparte.
E se cambiano le specifiche perche' cambia il mercato?
Si butta tutto e si riparte.
Al contrario, se il cliente vede ogni due settimane un'applicazione con la quale puo' sperimentare e "giocare", e' in grado di capire immediatamente se l'applicazione si sta indirizzando verso il suo obiettivo o meno. E puo' dare indicazioni tempestive per "guidare" il resto dello sviluppo. E puo' cambiare le specifiche sapendo che il team di sviluppo adotta pratiche tali da appiattire la curva dei costi e cambiare il design a costi virtualmente costanti durante tutto l'arco dello sviluppo.
E' semplicemente un modo piu' economico di scrivere software piu' robusto e che corrisponde alle richieste del cliente. ottimo, ottimo: mi ritrovo perfettamente in queste parole, vuol dire che sono un buon allievo!! mwhauhauwhauwhauwhauwa :sofico: :sofico:
Verissimo. Fare TDD in C++ senza tool di refactoring decenti ad esempio (Ref++ e' ok, ma non all'altezza dei tool di refactoring di Java), il framework di unit testing me lo sono scritto da solo (in TDD :p), non e' certo una passeggiata al parco ed inizia a non essere cosi' attraente rispetto a metodologie piu' classiche. Il C++ e' una brutta bestia.
Ma quando si passa a Java (C#/SmallTalk/etc), i costi di refactoring crollano grazie ai tool, i costi di unit testing sono bassissimi e i benefici dell'avere test che non solo aiutano il refactoring ma documentano il codice stesso, formalizzano i requisiti, comunicano i bug. Tanti vantaggi per un po' di codice in piu' :) come dicevo però sul TDD ancora non mi trovo d'accordo: secondo me questi test che stiamo facendo hanno un costo troppo elevato che rallenta più che percettibilmente lo sviluppo del lavoro. è innegabile che il codice di Diamonds senza i test si dimezza, e a quanto pare non sempre questi test hanno funzionato a dovere (vedi l'esperienza del sistema di coordinate: ci ha dimostrato una cosa che ritenevo praticamente impossibile, cioè che i programmi possono "funzionare per caso" :D non avevo mai visto un programma funzionare così :D).
il problema della documentazione secondo me è diverso: tu dici che la documentazione può essere completamente eliminata in favore dei test, i quali formalizzano il comportamento del programma al suo posto; io dico non proprio: secondo me in mancanza di test la documentazione ci deve essere, ma ad un altro livello: a livello funzionale.
esempio pratico, in Diamonds non bisogna documentare che abbiamo una classe Engine intesa come motore grafico del gioco basato su OpenGL; mentre invece bisogna documentare che il sistema di coordinate ha l'origine posto in alto a sinistra e l'asse delle Y orientato verso il basso.
la documentazione non deve coprire aspetti concettuali, imho deve coprire aspetti esclusivamente funzionali; è per questo che ho aperto nella sottosezione il thread "Diamonds knowledge" chiedendo di metterlo in rilievo.
The3DProgrammer
22-10-2005, 01:45
Lo feci anch'io per l'esame di Ingegneria del Software II: sei mesi di analisi dei requisiti, documenti, diagrammi UML, senza una riga di codice, perche' la professoressa si vantava di questa peculiarita'.
E' stato un esame utilissimo perche' mi ha insegnato fondamentalmente due cose: il software non si costruisce in quel modo, e le donne non devono costruire software :)
quoto ;)
x curiosità, dove ti sei laureato?
repne scasb
22-10-2005, 10:57
e le donne non devono costruire software
stessa nozione che mi ha inculcato avere una donna a Fondamenti d' Informatica II
le donne che programmano fanno ridere
prova a leggere i sorgenti scritti da una donna, fanno ridere per davvero
la mia esercitatrice di Algoritmi 1 è una perfetta scema
si vede benissimo che è na sega
quoto
Tutto molto offensivo.
Anche solo molto ironico. Non rovinare questo topic perche' e' interessantissimo.
Io conosco anche donne che porgrammano molto bene... Probabilmente è anche una questione derivante dal fatto che il pensiero femminile è organizzato in maniera diversa da quello maschile...e per questo, secondo uno studio, i maschi sono superiori in certi campi e le donne in altri...
Elentari
22-10-2005, 11:07
Tutto molto offensivo.
Non c'è nulla di offensivo invece. Io sono una donna, sono laureata in ingegneria elettronica, ho anche preso 30 in un esame di informatica ma.. non so programmare. Non mi piace. Non ci sono portata.
E secondo me le donne in generale non sono portate a programmare.
Elentari: conosci fek ? Ti ho chiesto questo perchè dalla location sembrate molto vicini ;)
jappilas
22-10-2005, 12:36
Tutto molto offensivo.
Ho avuto una docente che effettivamente ignorava quello che pretendeva di insegnare (programmazione C, C++, assembly e Smalltalk applicate con metodologia indistinta), che cercava di imporre agli allievi metodi e costrutti che regolamente si rivelavano errati
Tra tutti quelli che hanno seguito con quella docente, quasi tutti hanno dovuto studiare programmazione per conto proprio, anche reimparando da zero, scrollandosi di dosso i preconcetti inculcati da un corso che apparteneva a quelli di primi anni (e il primo e secondo anno sono quelli che ho avvertito operare maggior imprinting sulla forma mentis dello studente)
All' epoca (6 anni fa) mi convinsi di aver subito un danno (pago per ricevere una formazione e quello che viene fatto passare per dogma di fede si rivela inesatto e inconsistente ) e sperai che quello rimanesse un caso isolato
in un certo senso lo è rimasto (e mi scuso per il post che appare una generalizzazione sarcastica, voleva essere amara ironia)... però tra le persone aventi dimestichezza con la programmazione, che ho incrociato (scope maggiore di "conosciuto"), rientrano poche donne, e quelle poche, quasi tutte studentesse motivate (tra l' altro, quando entrai le ragazze a seguire quei corsi erano mosche bianche), nessuna docente, quindi della mia età o più giovani...
una sola persona di età maggiore della mia, e l' unica con una profonda conoscenza dell' assembly itanium, l' ho incontrata su un forum e ne ho grande ammirazione...
Tutto molto offensivo. tranquilla/o, non era riferito a te, ;) non ti considero una donna :D un robot più che altro :p
Io conosco anche donne che porgrammano molto bene... Probabilmente è anche una questione derivante dal fatto che il pensiero femminile è organizzato in maniera diversa da quello maschile...e per questo, secondo uno studio, i maschi sono superiori in certi campi e le donne in altri... <OT>infatti hai centrato il punto fondamentale, io la penso esattamente così come hai detto tu: il pensiero maschile è diverso da quello femminile, e dipende dagli ormoni (NB: non esistono solo ormoni sessuali: gli ormoni sono sostanze che regolano il funzionamento di tutto il nostro corpo). in generale per esperienza posso dirti che secondo me mentre gli uomini hanno maggiormente sviluppata una intelligenza di tipo razionale, le donne sono più intelligenti dal punto di vista sociale: sono più brave a comunicare; non a caso nelle superiori le insegnanti sono praticamente tutte donne.</OT>
Elentari: conosci fek ? Ti ho chiesto questo perchè dalla location sembrate molto vicini ;)
Abbastanza vicini :p
<OT>infatti hai centrato il punto fondamentale, io la penso esattamente così come hai detto tu: il pensiero maschile è diverso da quello femminile, e dipende dagli ormoni (NB: non esistono solo ormoni sessuali: gli ormoni sono sostanze che regolano il funzionamento di tutto il nostro corpo). in generale per esperienza posso dirti che secondo me mentre gli uomini hanno maggiormente sviluppata una intelligenza di tipo razionale, le donne sono più intelligenti dal punto di vista sociale: sono più brave a comunicare; non a caso nelle superiori le insegnanti sono praticamente tutte donne.</OT>
Pienamente d'accordo, uomini e donne sono diversi, hanno attitudini diverse e riescono al meglio in compiti diversi, spesso complementari. E' una cosa perfettamente naturale e non c'e' nulla di negativo. Ovviamente si fanno discorsi di media, c'e' sempre la proverbiale eccezione che conferma la regola.
Eccezione che io pero' in 15 anni non ho mai incontrato: non ho mai visto una donna scrivere buon codice leggibile e ben strutturato.
la mia esercitatrice di Algoritmi 1 è una perfetta scema che dice che alle sue lezioni lei programma in pseudocodice perché non vuole perdere tempo a ragionare sulla sintassi del C
E a mio parere ha perfettamente ragione.
In un corso di ALGORITMI lo scopo ultimo e far comprendere a fondo il funzionamento degli algoritmi studiati.
Lo studente si deve concentrare su questi, e non sulla sintassi del C.
Io ho avuto un'insegnate alle superiori che ci ha insegnato alla perfezione le basi dell'informatica, la programmazione procedurale (attraverso il Pascal), e gli algoritmi fondamentali.
Dopo anni e anni di esperienza devo dire che spesso e volentieri vado avanti agevolmente grazie alla forma mentis e alla metodologia con cui ci ha forgiato.
E verò però il fatto (anche se non so perchè, probabilmente valida la spiegazione di cionci) che le persone valide, nel mondo della programmazione, siano in maggioranza maschi.
E a mio parere ha perfettamente ragione.
In un corso di ALGORITMI lo scopo ultimo e far comprendere a fondo il funzionamento degli algoritmi studiati.
Lo studente si deve concentrare su questi, e non sulla sintassi del C. a ogni modo dovrebbe ragionare sulla sintassi del suo pseudolinguaggio, e si vede benissimo che non lo fa :D la sintassi cambia da una riga all'altra :rotfl:
in questo modo tavolta si creano persino delle ambiguità sul significato del programma :O :Prrr:
e potrebbe anche avere ragione sull'uso dello pseudolinguaggio (imho no però) ma fermo rimane che è scema :Prrr: :Prrr:
e non dico che tutte le donne lo sono: ci sono le oche bone e sceme e ci sono le ragazze carine e intelligenti (e poi ci sono anche quelle brutte e pure sceme, ma spesso non si considerano nemmeno ragazze :D); la mia prof non è intelligente, sorry :Prrr:
Puntuale un articolo sull'argomento del topic:
http://msdn.microsoft.com/msdnmag/issues/04/04/ExtremeProgramming/
TDD e Design Evolutivo, da leggere tutto d'un fiato.
Domanda:
Riguardo a qualcosa con una GUI, prendiamo in esempio una banalissima calcolatrice.
Come partite?
Io ho fatto così, prima di tutto mi sono creato dei pulsanti messi a caso nella form per poter testare la base (addizione tra due numeri, l'evento del pulsante che richiama una classe esterna in cui sono presenti le operazioni e simili), fatto questo e dopo aver visto il corretto funzionamento sono passato al resto (- * / e gli altri numeri) per poi concludere e mettere a posto (graficamente) le cose
Voi come avreste fatto?
Cioè, sareste partiti direttamente a fare tutto da codice (anche il minimo pulsante) oppure avreste utilizzato le cose a disposizione? Prima il funzionamento o prima l'aspetto "esteriore" ?
Sono curioso perchè i tre prof che ho dicono TUTTI di partire a mettere bene a posto graficamente la GUI per poi passare al funzionamento, cosa imho completamente sbagliata :mbe: Imho meglio far andare e poi mettere a posto, tanto per quello (se si usa quanto a disposizione) per creare dei pulsanti e usare funzioni/classi già create ci vuole poco
E' giusto quello che hai fatto tu. Separa la parte di logica che fa le operazioni dalla GUI e testa la logica separatamente. Poi usa un oggetto che "traduce" comandi ed eventi della GUI in comandi ed eventi per la tua logica; poi incanala la GUI in questo oggetto. Cosi' puoi testare la logica anche senza avere una GUI di test.
Infine metti a posto la GUI esteticamente, ma e' solo l'ultimissima cosa. Ma che razza di professori hai?
comunque l'esempio che hai fatto tu (quello della calcolatrice) era banale: per sviluppare una calcolatrice non serve certo una metodologia ferrea!
Ma che razza di professori hai? e perché io allora? :cry:
jappilas
24-10-2005, 10:48
Domanda:
Riguardo a qualcosa con una GUI, prendiamo in esempio una banalissima calcolatrice.
Come partite?
Io ho fatto così, prima di tutto mi sono creato dei pulsanti messi a caso nella form per poter testare la base (addizione tra due numeri, l'evento del pulsante che richiama una classe esterna in cui sono presenti le operazioni e simili), fatto questo e dopo aver visto il corretto funzionamento sono passato al resto (- * / e gli altri numeri) per poi concludere e mettere a posto (graficamente) le cose
Voi come avreste fatto?
Cioè, sareste partiti direttamente a fare tutto da codice (anche il minimo pulsante) oppure avreste utilizzato le cose a disposizione? Prima il funzionamento o prima l'aspetto "esteriore" ?
Sono curioso perchè i tre prof che ho dicono TUTTI di partire a mettere bene a posto graficamente la GUI per poi passare al funzionamento, cosa imho completamente sbagliata :mbe: Imho meglio far andare e poi mettere a posto, tanto per quello (se si usa quanto a disposizione) per creare dei pulsanti e usare funzioni/classi già create ci vuole poco
presta attenzione perchè è una questione un po' a tranello...
gli sviluppatori a volte ci "cadono", quando pensano che il loro SW sarà usato solo da altri sviluppatori o da... loro stessi, e "l' importante è che funzioni, dell' aspetto esteriore o se la sequenza di azioni e dialog box è poco consistente, chissene"... ricordo ancora che parecchi progetti open source dimostravano di aver seguto un approccio simile, funzionando (più o meno) ma risultando di scarsa usabilità
l' esempio della calcolatrice imho non è atto a esemplificare la differenza in termini di approccio tra "curare l' interfaccia" vs "curare il codice": una calcolatrice con le 4 operazioni associa praticamente una funzione ad ogni pulsante, in una singola finestra contenitore, e c'è praticamente un solo stato (waiting_for_input), quindi l' unico problema è effettivamente l' allineamento dei pulsanti (che si aggiusta in un paio di secondi in un GUI editor):
se avessi dovuto creare ex novo un' applicazione più seria, avresti dovuto cercare di mantenere il più possibile separate logica e interfaccia (lato estetico) del programma, però tenendo conto dei casi in cui magari l' interfaccia stessa o altre parti risentono della modalità operativa, impostata in qualche variabile, o l' utente debba seguire determinati passi per compiere un' azione, in una sequenza di dialog box in cui cliccare, eccetera,
in quel caso mi vedresti preparare un mockup strutturale prima o durante la stesura preliminare del codice
il mockup avrebbe il solo scopo di testare la congruità interna ed esterna del programma e dell' interfaccia (più che da un punto di vista estetico, da quello delle modalità e sequenze operative, la cui definizione inficia il design del codice sconfinando nel suo dominio)
Si'. L'unica documentazione sempre aggiornata il codice. Il resto e' documentazione sempre e comunque non aggiornata, che ha un costo mantenere e che non fornisce alcun valore al cliente.
Non sono proprio mosche bianche, diciamo che pian piano stanno diventando la maggioranza, a partire da:
http://www.thoughtworks.com/index.html
In pochissimi anni e' passata dall'essere una piccola azienda di software all'essere una multinazionale con sedi in tutto il pianeta. E usano solo metodologie agili di sviluppo.
Io penso che non ci si possa illudere di fare dei progetti di una certa qualita' con la speranza di consegnargli in tempo e di dare valore al cliente cercando di progettare tutto a priori, magari attraverso documenti UML ed una metodologia Waterfall. A parte in rarissimi casi, quando le specifiche sono immutabili e perfettamente formalizzate. Ovvero in una strettissima minoranza dei casi, e di solito non in situazioni di mercato, dove l'economia stessa impone continui cambiamenti ai requisiti, tali da rendere anti economiche metodologie di sviluppo con una curva dei costi classica.
Io non so al giorno d'oggi quale sia il cliente che preferisca spendere soldi per mesi senza vedere uno straccio di applicazione, ma solo gran documentazione che non gli risolve alcun problema. L'alternativa e' vedere un'applicazione che inizia a risolvergli i problemi fin dal primo ciclo, dopo un paio di settimane.
Se pensi che un gruppo di ragazzi sostanzialmente alle prime armi in quanto a programmazione, guidati da me che non ho certo grande esperienza da Coach, ci riesce piuttosto bene proprio su questo forum, devo dire che non e' cosi' difficile mettere in pratica un po' di XP :)
Ce n'e' un altro interessante: Extreme Programming Refactored, che in sintesi nega ogni singola pratica dell'XP. Una lettura utile.
Purtroppo per ora posso attaccarmi solo a quanto leggo sui libri e a quello che mi "propinano" i docenti di ingegneria.
Non ti nascondo che a me UML piace moltissimo,ma se mi trovo qui a discutere e' anche per sentire ,chi magari ,ha gia toccato con mano queste problematiche in ambito lavorativo.
Dal punto di vista "accademico" in UML vedo la possibilita' di spaccare il capello in 4 e di non lasciare nulla al caso.
Vi seguiro' con interesse in queste discussioni :)
Purtroppo per ora posso attaccarmi solo a quanto leggo sui libri e a quello che mi "propinano" i docenti di ingegneria.
Non ti nascondo che a me UML piace moltissimo,ma se mi trovo qui a discutere e' anche per sentire ,chi magari ,ha gia toccato con mano queste problematiche in ambito lavorativo.
Dal punto di vista "accademico" in UML vedo la possibilita' di spaccare il capello in 4 e di non lasciare nulla al caso.
Vi seguiro' con interesse in queste discussioni :)
Ma nessuno discute UML, anzi. Martin Fowler che e' uno dei piu' importanti propositori di metodologie agili, e' anche uno dei piu' grandi esperti di UML.
Il problema dei professori all'Universita' e' il non aver mai scritto software (a parte pochissime rare eccezioni), quindi non conoscono di fatto le metodologie che in pratica si rivelano piu' o meno efficaci. Scrivere tutta la documentazione in UML in maniera formare per mesi e' perfetto a livello "accademico" e in teoria funziona perfettamente se i requisiti sono perfettamente stabili e chiari. Ma nel mondo reale dello sviluppo i requsiti non sono ne' stabili, cambiano a ritmi vertiginosi, ne' chiari, il cliente neppure spesso sa quello che vuole fino a che non lo vede.
Quindi, in ambienti di sviluppo reali, le metodologie teoriche semplicemente non funzionano e non sono produttive. Lo scoprirai quando entrerai in un ambiente di lavoro reale.
Questo vuol dire che nessuno usa metodologie di sviluppo basate su documentazione formale con successo? No. La NASA usa quasi solo metodologie di questo tipo per sviluppare il software delle sonde, o degli shuttle, ad esempio. Possono perche' loro hanno requisiti stabili e sono il loro cliente. Quindi possono scrivere tutta la documentazione prima, verificarla formalmente e poi passare allo sviluppo. Quello che scrivono deve essere "nearly zero defects". Sviluppare cosi' costa tantissimo, ma la NASA puo' permetterselo.
Ragazzo del '99
24-10-2005, 19:30
Non c'è nulla di offensivo invece. Io sono una donna, sono laureata in ingegneria elettronica, ho anche preso 30 in un esame di informatica ma.. non so programmare. Non mi piace. Non ci sono portata.
E secondo me le donne in generale non sono portate a programmare.
Strano che il primo programmatore della storia universalmente riconosciuto sia una donna, Ada Byron contessa di Lovelace :D
Poi usa un oggetto che "traduce" comandi ed eventi della GUI in comandi ed eventi per la tua logica; poi incanala la GUI in questo oggetto. Cosi' puoi testare la logica anche senza avere una GUI di test.
Avresti mica un esempio per questa parte? :confused:
Ma che razza di professori hai?
Se ti facessi un elenco di quello che fanno/vogliono/etc penso che avresti voglia anche tu di ucciderli (si torna a quanto detto prima, sono professori di matematica che sono passati a insegnare programmazione, a parte uno che ci sta dentro, avendo lavorato in qualche progetto da programmatore, ma gli altri lasciamo stare. Ti dico solo che mi è successo una volta: l'assistente di laboratorio mi aveva detto di dichiarare direttamente TUTTE le variabili d'istanza pubbliche e alcune statiche, così era più comodo gestirle (voglio vederlo a gestire quelle statiche in diversi oggetti, se questo non è richiesto :mbe: ) ...ovviamente non ho fatto così.. :muro: )
71104: era il primo esempio che mi è venuto in mente, banale sì...ma se vuoi provo a recuperare alcuni sorgenti che sono stati fatti seguendo i prof, tanto per vedere delle cose assurde (lasciamo stare il fatto del dividere la logica dalla GUI che forse siamo stati in 2 a farlo)
Ah, fek...vuoi rabbrividire ancora? Tieniti pronto, questa è pesante... tu cosa faresti a un prof che ti dice di fare copia e incolla del codice (senza modificarlo, direttamente prendere e mettere uguale da un'altra parte, nella stessa classe) perchè è più veloce, e se gli dici che sarebbe più comodo creare un metodo da richiamare ti dice che è solo uno spreco di tempo?
jappilas: non volevo dire di non curare assolutamente la parte grafica, anzi...se è fatto bene e comunque comodo da usare fa risparmiare tempo anche a me che lo utilizzo. Però mi sembra altamente stupido partire subito con la creazione di tutta la parte esterna per poi passare al codice vero e proprio di logica.
in quel caso mi vedresti preparare un mockup strutturale prima o durante la stesura preliminare del codice
il mockup avrebbe il solo scopo di testare la congruità interna ed esterna del programma e dell' interfaccia (più che da un punto di vista estetico, da quello delle modalità e sequenze operative, la cui definizione inficia il design del codice sconfinando nel suo dominio)
Uhm..avresti qualche link di esempio :confused:
Comunque, per creare la GUI voi come fate? Usate le comodità che offrono gli IDE oppure tutti masochisti (però a questo punto voglio sapere anche il motivo ;) ) a scrivere solo ed unicamente codice anche per la minima cosa (es pulsante) ?
Concludendo, comunque molte volte sono anche i professori che fanno perdere la voglia, cioè...ad alcuni interessa solo che il programma funzioni e non interessa com'è stato scritto(questi imho sarebbero completamente da eliminare -.-)....altri vogliono che sia fatto tutto a scuola e se qualcosa viene fatto a casa non va bene...poi ad alcuni non va bene il linguaggio/metodo/etc perchè per loro dev'essere solo quello....e altre cose di questo tipo..... per quanto mi riguarda molte delle volte faccio come voglio io, poi se mi viene detto qualcosa che mi aiuta a semplificare le cose o comunque cose che non sò...meglio
Ah, fek...vuoi rabbrividire ancora? Tieniti pronto, questa è pesante... tu cosa faresti a un prof che ti dice di fare copia e incolla del codice (senza modificarlo, direttamente prendere e mettere uguale da un'altra parte, nella stessa classe) perchè è più veloce, e se gli dici che sarebbe più comodo creare un metodo da richiamare ti dice che è solo uno spreco di tempo?
Gli riderei in faccia. Fragorosamente :)
Gli riderei in faccia. Fragorosamente :) ma lol :D
certo in effetti, :asd: a questo punto allora il concetto di funzione non serve più a nulla, ritorniamo ai vecchi tempi dei programmi monolitici costituiti da un unico grosso blocco... :asd:
già fek mi cazzia quando faccio funzioni troppo lunghe (perché io riesco a concepire l'utilità del concetto di funzione solo se il codice che essa contiene lo si usa più d'una volta), figuriamoci questo pazzo :asd:
Non sarebbe male una cosa del tipo: "A scuola con fek"
In cui tutti i corsi che parlano/toccano la programmazione sono fatti direttamente da lui (dopo una settimana però ho l'impressione che sarebbe propenso al suicidio :rolleyes: ). Ci sarebbero molti più programmatori/informatici seri :D
jappilas
24-10-2005, 20:40
Non sarebbe male una cosa del tipo: "A scuola con fek"
In cui tutti i corsi che parlano/toccano la programmazione sono fatti direttamente da lui (dopo una settimana però ho l'impressione che sarebbe propenso al suicidio :rolleyes: ). Ci sarebbero molti più programmatori/informatici seri :D
è vero, personalmente imparo moltissimo ogni volta che lo leggo :)
ho però la sensazione che una "cosa" (sezione, rubrica, thread o altro) fissa, implicherebbe oberarlo definitivamente di impegni... :O
Comunque, per creare la GUI voi come fate? Usate le comodità che offrono gli IDE oppure tutti masochisti (però a questo punto voglio sapere anche il motivo ;) ) a scrivere solo ed unicamente codice anche per la minima cosa (es pulsante) ?
Personalmente cerco di usare CASE tools il piu possibile per cose noiose come le GUI.
Personalmente penso che andare a scriversi una interfaccia complessa completamente a mano spesso è indice di turbe mentali e traumi infantili :D
ciao ;)
Non sarebbe male una cosa del tipo: "A scuola con fek"
In cui tutti i corsi che parlano/toccano la programmazione sono fatti direttamente da lui (dopo una settimana però ho l'impressione che sarebbe propenso al suicidio :rolleyes: ). Ci sarebbero molti più programmatori/informatici seri :D
Adesso non esagerare! :D
Uhm...case tools? :rolleyes: :confused:
Ok ok....fek, quando vieni nella mia scuola a sostituire tutti i miei prof e s'inizia a fare qualcosa di serio? :D :Prrr:
Elentari
24-10-2005, 21:43
Strano che il primo programmatore della storia universalmente riconosciuto sia una donna, Ada Byron contessa di Lovelace :D
Un'eccezione che conferma la regola. Una piccola particella di sodio dispersa in un mare di cellule d'acqua :)
Una sola donna contro un numero consistente di uomini. Questo non contraddice la mia teoria sul fatto che noi donne non siamo portate per natura a programmare.
Uhm...case tools? :rolleyes: :confused:
Ok ok....fek, quando vieni nella mia scuola a sostituire tutti i miei prof e s'inizia a fare qualcosa di serio? :D :Prrr:
Computer-Aided Software Engineering. Sono qui programmmini visuali che ti fanno fare tutto da interfaccia grafica come gli editor di interfacce.
ciao ;)
^TiGeRShArK^
25-10-2005, 09:27
Comunque, per creare la GUI voi come fate? Usate le comodità che offrono gli IDE oppure tutti masochisti (però a questo punto voglio sapere anche il motivo ;) ) a scrivere solo ed unicamente codice anche per la minima cosa (es pulsante) ?
dipende....
la prima volta ke ho scritto un'interfaccia grafica ho fatto tutto a manina per imparare meglio l'uso dei vari oggetti...
poi sono passato senza troppi rimpianti al gui editor di JBuilder (a parte quando si impallava ke mi faceva bestemmiare in tedesco! :muro: ).
Ora per necessità sono dovuto tornare a fare tutto a manina in quanto sto sviluppando delle applicazioni MIDP x Nokia 9500.... e vsita la particolarità di quello che devo fare l'editor del netbeans col mobile pack non soddisfaceva le mie esigenze..
Cmq la mia idea è ke x imparare all'inizio va bene scrivere tutto a mano, occorre fare lo stesso se si hanno particolari esigenze....
Invece in tutti gli altri casi è MOLTO meglio sviluppare tutto con i GUI editor e concentrare i propri sforzi sulla logica del programma.
Eventualmente si potrebbe effettuare una piccola fase di tuning manuale se i GUI editor sballano qualcosa... (e di solito sballano... o se sballano!:muro: )
Computer-Aided Software Engineering. Sono qui programmmini visuali che ti fanno fare tutto da interfaccia grafica come gli editor di interfacce.
ciao ;)
Guarda mamma, senza codice!
Guarda mamma, senza codice!
spero solo di non fare la fine di pierino :asd:
ciao ;)
Ho ripulito...il primo/a che continua la polemica verrà sospeso...
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.