|
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 il 14/01/2013 alle 19:25
| 
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.
