Oppure

Loading
14/01/13 13:45
Saik
Ragazzi mi trovo davanti un bel dilemma :D finora ho programmato "seguendo l'istinto" cioè leggo il problema e poi comincio a scrivere codice, purtroppo mi sono accorto che questo metodo va bene per programmi piccoli e semplici ma nel caso di grossi progetti o di progetti di gruppo questo metodo risulta inefficace.
Che metodi usate voi per "progettare" i vostri capolavori :D ? :-?

P.S ho utilizzato già lo pseudocodice e il linguaggio UML ma entrambi non soddisfano le mie esigenze :D

aaa
14/01/13 18:20
pierotofy
Solitamente:
- Inquadro il problema
- Se il problema e' grande, lo divido in tanti sotto problemi e do' priorita' a quelli che ritengo piu' difficili e/o importanti per lo scopo del progetto
- Su una lavagna (o un pezzo di carta) scrivo una descrizione della mia soluzione ad alto livello (niente dettagli d'implementazione)
- Controllo la mia descrizione e valuto se ci sono modi migliori di risolvere il problema
- Una volta che sono soddisfatto della soluzione, la controllo per possibili errori o per problemi che potrei aver sottovalutato
- Identifico le librerie che mi aiuteranno a risolvere il problema (per non reinventare la ruota)
- A quel punto mi metto al computer e comincio a creare degli stubs per le classi (se programmo ad oggetti) e/o moduli che conterranno la mia soluzione
- Comincio a riempire i metodi o funzioni con la mia soluzione (seguendo la descrizione scritta sulla carta o lavagna)
- Se qualcosa non quadra, ritorno alla lavagna e devo ri-analizzare il problema
- Una volta implementata la soluzione eseguo qualche test funzionale
- Se ho qualcuno disponibile vicino a me, gli chiedo di guardare il mio codice e di vedere se c'e' qualcosa che potrebbe essere migliorato.

Questo ovviamente per progetti individuali.

UML lascialo perdere; troppo formale e fornisce troppi dettagli dell'implementazione in mia opinione.
Ultima modifica effettuata da pierotofy 14/01/13 18:25
Il mio blog: piero.dev
19/01/13 15:35
Saik
Grazie mille del tuo parere nei prossimi giorni sperimenterò il tuo metodo :D e vedro' come mi trovo :D
aaa
24/01/13 10:51
Tw1st3r_Ev0
Anch'io faccio come te per creare qualche banale programma!
Però quando si tratta di fare grossi progetti vado ovviamente a disegnarmi su carta l'intera struttura del progetto usando i diagrammi di flusso, in modo che quando andrò a sviluppare l'intero programma su un IDE, so che passaggi devo seguire e da dove devo cominciare. :)
La soluzione di piero comunque è anche ottima e piu professionale :k:
Ultima modifica effettuata da Tw1st3r_Ev0 24/01/13 10:53
aaa
02/02/13 3:05
Farrow
Postato originariamente da pierotofy:

Solitamente:
- Inquadro il problema
- Se il problema e' grande, lo divido in tanti sotto problemi e do' priorita' a quelli che ritengo piu' difficili e/o importanti per lo scopo del progetto
- Su una lavagna (o un pezzo di carta) scrivo una descrizione della mia soluzione ad alto livello (niente dettagli d'implementazione)
- Controllo la mia descrizione e valuto se ci sono modi migliori di risolvere il problema
- Una volta che sono soddisfatto della soluzione, la controllo per possibili errori o per problemi che potrei aver sottovalutato
- Identifico le librerie che mi aiuteranno a risolvere il problema (per non reinventare la ruota)
- A quel punto mi metto al computer e comincio a creare degli stubs per le classi (se programmo ad oggetti) e/o moduli che conterranno la mia soluzione
- Comincio a riempire i metodi o funzioni con la mia soluzione (seguendo la descrizione scritta sulla carta o lavagna)
- Se qualcosa non quadra, ritorno alla lavagna e devo ri-analizzare il problema
- Una volta implementata la soluzione eseguo qualche test funzionale
- Se ho qualcuno disponibile vicino a me, gli chiedo di guardare il mio codice e di vedere se c'e' qualcosa che potrebbe essere migliorato.

Questo ovviamente per progetti individuali.

UML lascialo perdere; troppo formale e fornisce troppi dettagli dell'implementazione in mia opinione.


Sublime... :k:
aaa