Filosofia di programmazione

[Kleidemos]

In tutti i corsi di informatica insegnano:
prima di mettersi a programmare bisogna sempre "pensare" e "abbozzare" qualcosa su carta...In linea logica ciò è vero, in questo modo il risultato sarà sicuramente più elegante e funzionale, ma...io non ci riesco, quando ho in mente un programma mi metto davanti al mio pc e scrivo le idee come vengono; cercando, poi, di integrare il tutto al meglio possibile.
Non sò come è, ma se non ho davanti una tastiera ed un monitor non riesco a scrivere una riga (neppure in Pseudocodice!!) .
Voi come procedete??
Quale è la vostra "filosofia di programmazione?
Procedete in modo impulsivo o determinato a priori??


Ciao a Tutti

[atragon]

<<Procedete in modo impulsivo o determinato a priori??

A parer mio per programmi piccoli e dalla logica immediata puoi anche buttare giù le cose al volo, al massimo farai qualche aggiustamento di corsa ma per applicativi seri mettersi a scrivere codice prima di pensare all'architettura se non è suicida sicuramente rischia di farti perdere molto, molto tempo...si può spezzare un problema in varie parti e risolvere quelle, ma comunque una logica ci vuole sempre e comunque...alla fine i risultati arrivano.

[Kleidemos]

Originally posted by "atragon"

<<Procedete in modo impulsivo o determinato a priori??

A parer mio per programmi piccoli e dalla logica immediata puoi anche buttare giù le cose al volo, al massimo farai qualche aggiustamento di corsa ma per applicativi seri mettersi a scrivere codice prima di pensare all'architettura se non è suicida sicuramente rischia di farti perdere molto, molto tempo...si può spezzare un problema in varie parti e risolvere quelle, ma comunque una logica ci vuole sempre e comunque...alla fine i risultati arrivano.


tu come fai di solito?

[atragon]

Vedi sopra...se devo scrivere qualche utility volante cerco di buttare giù il codice e pazienza se viene fuori alla "va là che vai bene" ...ma se si tratta di cose che possono avere un impatto di un certo peso mi metto sempre a pensare bene a come fare il tutto, al limite, qualche volta, ricorrendo ai classici schemi a blocchi, un po' retrò, forse, ma talvolta molto utili...certo sperando di averne il tempo, quello è un altro discorso...

[cionci]

Anche io solitamente faccio così... Poi ultimamente mi sono buttato in un progetto abbastanza grande che faceva ampio uso di classi e gerarchie di classi create da me...
In pratica dopo averlo quasi finito la struttura e parte del codice mi è toccato riscriverlo praticamente da capo per ottenere la gerarchia di oggetti che volevo e a cui all'inizio non avevo pensato...

Se il progetto è grande conviene SEMPRE scrivere (o disegnare) qualcosa prima... Magari non serve entrare troppo nel dettaglio, ma qualcosa che riguarda i moduli (o le classi) del programma e la loro interazione conviene farlo...

UML l'hanno studiato per questo... Purtroppo strumenti validi di authoring UML come TogheterSoft o Rational Rose sono molto cari anche se molto utili (spesso generano anche l'intestazione delle classi in Java e/o C++)

[/\/\@®¢Ø]

Spesso e' difficile sapere a priori cosa si vuol ottenere. Anche quando si ha chiara l'idea del cosa ottenere, non si sa bene come, e ce se ne accorge solo durante la produzione del codice. A volte quindi un modo comodo e' quello di buttare giu' un prototipo "a getto" si vede cosa va e cosa no, e poi si riparte da zero (o tenendo quel che risulta riutilizzabile) con una impostazione piu' rigorosa.

[lombardp]

Originally posted by "/\/\@®¢Ø"

Spesso e' difficile sapere a priori cosa si vuol ottenere. Anche quando si ha chiara l'idea del cosa ottenere, non si sa bene come, e ce se ne accorge solo durante la produzione del codice.

Questo è vero per progetti di piccole dimensioni. Come dice Cionci, quando la dimensione del progetto è medio-grande, è quasi impossibile produrre del codice prima di aver progettato lo scheletro (strutture dati, gerarchia delle classi, etc...).

[/\/\@®¢Ø]

Originally posted by "lombardp"



Questo è vero per progetti di piccole dimensioni. Come dice Cionci, quando la dimensione del progetto è medio-grande, è quasi impossibile produrre del codice prima di aver progettato lo scheletro (strutture dati, gerarchia delle classi, etc...).
Questo e' vero quando si lavora in gruppo, e allora e' un altro paio di maniche :D, io pensavo a programmi scritti da soli. In questo caso si corre il rischio di fare un progetto troppo grande o flessibile, si parte col progettare una classe per la conversione di valute e si finisce a lavorare ad un mega-framework economico-finanziario :D ( a me capita sempre cosi' ... :( :D )
A questo punto bisognerebbe forse decidere di che tipo di progetti si sta parlando, visto che in effetti l'approccio puo' cambiare. Anche il fatto che una cosa si faccia per lavoro (tempi ristretti, specifiche un po' piu' chiare ) o "just for fun" cambia...

[Analizzator]

Vediamo se non dico un eresia:
Ho scritto cose lunghette solo in C e in php.
Diciamo che in php al di sopra del centinaio di righe di codice conviene il disegnetto e in C pure.
Che ne pensate?
In java credo convenga sempre e comq, o in ogni situazione in cui si fa un progetto a oggetti.

Il discorso just for fun secondo me non è proprio corretto, io per esempio nelle cose just for fun, visto che ho tempo illimitato cerco di fare tutto al meglio. Quando si deve rispettare una scadenza invece è più facile tendere verso la "spaghettata"

In ogni caso prima do una descrizione qualitativa del tutto e poi siccome in corso di opera vengono sempre fuori, o da me o purtroppo dai clienti necessità di feature non previste prima di rifare tutto da zero si cerca una soluzione estemporanea :)

[cionci]

Comunque per progratti medio-grandi io intedo progetti che coinvolgono o più persone o che già al momento di cominciare siamo sicuri che raggiungeranno un numero di righe di codice superiore alle 5-10 mila (anche se non è una buona unità di misura della complessità del progetto)...

[DanieleC88]

Io ho sempre programmato in VB ed ora anche in Delphi, ma non sono mai riuscito a scrivere qualcosa prima: le applicazioni le creo sfruttando tutte le proprietà di una funzione che potrei non conoscere a fondo: ho bisogno dell'help al mio fianco !

[recoil]

io cerco sempre di pensarci prima, non necessariamente scrivendo su carta. quando penso di aver affrontato tutte le problematiche possibili inizio a scrivere, ma tanto la maggior parte dei problemi si scoprono appunto quando si sta programmando, non prima...

[cionci]

Originally posted by "DanieleC88"

Io ho sempre programmato in VB ed ora anche in Delphi, ma non sono mai riuscito a scrivere qualcosa prima: le applicazioni le creo sfruttando tutte le proprietà di una funzione che potrei non conoscere a fondo: ho bisogno dell'help al mio fianco !
Guarda che per progettazione non si parla mai di scrivere codice che sfrutta le funzioni finali da utilizzare nel progetto... Al limite si scrive l'interfaccia grafica...o alcune simulazioni di ciò che si deve ottenere in fondo (questo per progetti moooolto grandi)...
In generale il progetto è a grandi linee e riguarda l'interazione fra i moduli e non comprende le istruzioni del linguaggio di programmazione in cui sarà sviluppato il progetto...
Si tratta di stabilire delle linee guida su cui si deve sviluppare un progetto...
Ad esempio se io voglio fare un server mail devo pensare prima di tutto ai moduli che compongo il progetto...server pop3, server smtp, modulo di invio delle mail, modulo che gestisce i dati...
Tutti i moduli comunicheranno con il modulo che gestisce i dati...il modulo che gestisce i dati si suddividerà a sua volta in diversi moduli : gestione delle mailbox, gestione della posta in uscita, gestione degli utenti, gestione del file di log, interfaccia con il DBMS...
Poi chiaramente si dovranno studiare le interazione anche fra questi moduli... Ovviamente si può andare ancora più nel dettaglio specificando l'"interfaccia" che ogni modulo mette a disposizione per gli altri...
E tutto questo senza scrivere una riga di codice se non l'intestazione parziale delle funzioni...

[DanieleC88]

Originally posted by "cionci"


Guarda che per progettazione non si parla mai di scrivere codice che sfrutta le funzioni finali da utilizzare nel progetto... Al limite si scrive l'interfaccia grafica...o alcune simulazioni di ciò che si deve ottenere in fondo (questo per progetti moooolto grandi)...
In generale il progetto è a grandi linee e riguarda l'interazione fra i moduli e non comprende le istruzioni del linguaggio di programmazione in cui sarà sviluppato il progetto...
Si tratta di stabilire delle linee guida su cui si deve sviluppare un progetto...
Ad esempio se io voglio fare un server mail devo pensare prima di tutto ai moduli che compongo il progetto...server pop3, server smtp, modulo di invio delle mail, modulo che gestisce i dati...
Tutti i moduli comunicheranno con il modulo che gestisce i dati...il modulo che gestisce i dati si suddividerà a sua volta in diversi moduli : gestione delle mailbox, gestione della posta in uscita, gestione degli utenti, gestione del file di log, interfaccia con il DBMS...
Poi chiaramente si dovranno studiare le interazione anche fra questi moduli... Ovviamente si può andare ancora più nel dettaglio specificando l'"interfaccia" che ogni modulo mette a disposizione per gli altri...
E tutto questo senza scrivere una riga di codice se non l'intestazione parziale delle funzioni...

Cionci, hai perfettamente ragione, ma io quando penso un progetto lo penso già realizzato: perciò mi servo del computer per la progettazione di una buona interfaccia che risponda bene agli eventi generati dall'utente, con le dovute istruzioni e quindi tutto il resto del codice a cui ti riferisci viene, per i miei progetti, stranamente dopo. Per il resto non posso darti torto.