in uno dei primi libri presi un bel po di anni fa, prima di entrare nella fase attiva della programmazione, veniva fatta una introduzione sui vari argomenti teorici, ed uno di questi erano i diagrammi di flusso.
vorrei chiedere a chi si cimenta nella programmazione quotidianamente anche in azienda, con un team etc, per quanto possa condividere tale logica, se sia davvero possibile mettere su carta tutto un intero programma (e parlo non solo delle sole fasi: inizio attività condizioni etc) ma se in questa fase vengono prese anche decisioni su quale metodo adottare per raggiungere l’obiettivo, del tipo:
in questa parte del programma usiamo questi tipi di funzioni o componenti nel caso di Gh
e così via per tutto lo sviluppo di esso fino alla conclusione del programma stesso.
è fattibile un discorso del genere oppure si tratta di un pensiero utopistico,
che serve solo come pratica teorica spiegata nei banchi di scuola?
Una decina di anni fa un mio prof di informatica mi disse che per sviluppare un software (credo per una farmacia) disegnarono un diagramma di flusso su tanti fogli da avere occupato tutto il pavimento di una stanza. Vero o non vero…? Ma questo ci riportò.
Il diagramma, secondo me, serve per fissare il meccanismo di funzionamento di una procedura e può essere applicato a vari livelli (dal concetto grossolano fino all’analisi di ogni singolo caso).
Nessuno vieta di fare un diagramma che, in alcuni punti, richiami un altro diagramma e così via fino alla singola istruzione…
Se vuoi creare un unico diagramma enorme stile labirinto nessuno te lo vieta… poi se risulta utile o sconfortante decidilo tu… io ragionerei più stile manuale di istruzioni:
Diagramma con i “componenti principali”
Diagrammi dei singoli “componenti principali” con le “funzioni”
Diagrammi che spiegano il funzionamento delle “funzioni”
Poi, se il programma è veramente complesso, va da se che il numero delle pagine aumenta, ma in quel caso serve un programma per organizzare il lavoro di programmazione… e un team di lavoro… e il supporto per il debugging… e insomma hai messo su una software house.
più che altro, oltre al racconto di Luca, cioè scrivere un pavimento di diagrammi, mi chiedevo se è prassi anche scrivere con quale metodo usare per ogni circostanza, ed ovviamente se vengono anche prese in considerazioni possibili alternative oppure ci si regola strada facendo?
in pratica sarebbe possibile, come dire, (per veri esperti ovviamente) mettere su carta quali tipi di codici necessari per un “vero” programma, anticipando a priori quali algoritmi o componenti siano più adatti per ogni specifico caso, oppure ritornando ai diagrammi si butta giù una prima bozza del funzionamento per poi modificarla quando necessario o anche nel caso cambiarla del tutto?
@lucio_zadra (tocca fare cosi, le risposte non me le prende piu’ )
Nella fattispecie … concordo abbastanza.
Poco tempo fa ho letto un libro su vari linguaggi di programmazione e relativi autori.
C’era anche l’UML. La mia impressione e’ stata che ‘sti 3 furbacchioni (che avevano gia’ dei linguaggi simili) si fossero messi insieme per titar su qualche dollaro.
Non dico che il linguaggio non serva, anzi certo puo’ servire (basta leggere cosa ne dice Rolf Lampa sul forum USA).
Ma alla fine, come per gli altri linguaggi la mia impressione (rispondendo a @0904) e’ che ognuno usa il metodo che preferisce.
Lo strumento e’ una bella cosa, ma se dietro non c’e’ il manico …
Forse nessuno tra chi ha risposto lavora come programmatore professionista in un team … (io no di certo )
Pero’ mi sembra che Lucio abbia comunque spiegato per bene un modo per organizzare i diagrammi.
… Oltre a specificare che molto dipende dalla complessita’ del programma da scrivere e da come e’ organizzato il lavoro.
ovviamente per un programma semplice sarebbe inutile fare un diagramma su carta, il tempo di fare lo schema ti scrivi il codice direttamente, per questo avevo ampliato il discorso a chi lavora con più persone, essendo che “forse” sarebbe più utile in un caso simile, in modo da dividere ad ognuno il proprio compito. comunque era giusto per sapere se nelle proprie esperienze era capitato di usarlo.
Mmmm, non credo… a mio modo di vedere, il diagramma serve per documentare il programma.
Se a distanza di tempo devi riprendere in mano del codice scritto in precedenza e non ti ricordi cosa faceva… il diagramma ti aiuta ad individuare il funzionamento (un pò come avere i commenti all’interno del codice, ti segni che hai fatto una certa procedura per ovviare a qualche malfunzionamento o altri accorgimenti).
Se si lavora in team sicuramente è utile sapere “chi fa cosa” e come ci si deve intefacciare, ma anche un poveraccio che lavora da solo ha bisogno di fare chiarezza su quello che sta facendo… o almeno io, per capirmi, molte volte mi faccio uno schemino su un pezzo di carta segnandomi le cose principali da fare… molte volte mi aggiungo anche un file .txt con delle note su come utilizzare un certo programma o dei riferimenti dove posso reperire informazioni (a volte mi faccio dei pulsanti in Rhino che mi aprono delle finestre di testo che spiegano il funzionamento di uno script, praticamente delle mini-guide).
quindi ritieni che sia uno strumento in più che possa aiutare in determinate circostanze
per la srie: se c’è male non fa
il perchè l’ho avevo chiesto, era per sapere se questo tipo di approccio preliminare, potrebbe aiutare a commettere meno errori nella fase successiva quella della scrittura del codice.
per esempio se scrivo un codice o creo una definizione e successivamente mi accorgo di dover cambiare la fase iniziale del programma perché non va bene per quella intermedia o finale e quindi debbo rielaborale l’impostazione, in questi casi un digramma aiuterebbe o sarebbe la stessa cosa essendo che o lo fai scrivi prima su carta o lo crei direttamente ma il ragionamento è sempre quello?
Salvio, se scrivi un programma che ha vari componenti, credo che avrai fatto un ragionamento… o no?
Ti trovi meglio a tenere tutto a mente? Buon per te… io, intanto che programmo (per quel poco che so fare) ho sempre un foglio e una matita dove annotarmi le cose importanti o farmi qualche schema con le varie situazioni da affrontare.
Devo ancora conoscere qualcuno che fa casino perchè si è fatto uno schema su come agire… è più facile il contrario.
Salvio, sottoscrivo quanto detto da Lucio.
Anch’io mi trovo molto meglio se riesco a scrivere qualcosa su carta prima di avvicinarmi al PC,
anche solo per ragionare.
( Salvo il caso dello scriptino per Rhino di poche righe )
Questo non significa che bisogna per forza prevedere in anticipo la sequenza dettagliata delle istruzioni.
Secondo me al nostro livello non ha senso.
Ci sarebbero comunque degli errori ( salvo di nuovo il mini-script di cui sopra ).
E sarebbe comunque impossibile prevedere cosa succede in pratica.
Meglio provare, una volta deciso come impostare il programma, magari con un ‘prototipo’ temporaneo, anche parziale, semplificato al massimo.
E non credere se ti fai prima il diagramma di flusso o altri schemi questo ti eviti di dover riscrivere il programma da capo.
Dipende dal problema, certo, ma secondo me a volte (anzi spesso) e’ inevitabile.
Pero’ partire da qualche tipo di schema ti aiuta a lavorare con una certa logica, a capire cosa funziona e cosa no, e quindi a decidere in quale direzione andare.
è proprio questo il dubbio che ho. ora a parte le mie conoscenze che non voglio prendere come
esempio, ho chiesto a voi che scrivete codici tutto il giorno avendo studiato e facendolo per lavoro
se tramite questo metodo di pianificazione potesse evitare qualche sorpresina nella fase avanzata.
certamente, anche solo per creare un ciclo che ti ritorna un determinato risultato bisogna aver fatto un minimo di ragionamento. forse il fatto che mi fa incavolare è proprio questo, ormai è qualche anno che sono su questa piattaforma e grazie a “Voi” tutti ho imparato tantissime cose, ma mi meraviglio quando dopo aver ragionato anche più volte su come realizzare una cosa capita “ancora oggi”
di dover trovare una strada alternativa a quella pensata inizialmente.
ma… forse sarà che chiedo sempre di più a me stesso. per la serie: io, sono il mio peggior nemico.
un saluto e grazie della condivisione
Purtroppo questo è l’imprevisto più ricorrente, dovuto ad inesperienza (chi ha fatto centinaia di volte la stessa operazione, ha probabilmente già cercato la strada più veloce o affidabile) oppure all’evoluzione del contesto (prima ci si accontenta di una funzione, poi due, tre, quattro… e alla fine “sciopa” tutto e ti tocca ripartire da zero).
Eh, ti capisco… e la soluzione è che, a volte, bisogna anche saper valutare se quello che ci chiediamo è necessario oppure se sia solo un nostro puntiglio.
Molte volte mi sono sentito dire che bisogna anche portare a casa la pagnotta perché a “filosofeggiare” troppo non si combina un tubo… e, purtroppo, è vero.
Il tempo a nostra disposizione non è infinito… bisogna focalizzare le priorità e portarle a termine per non pentirsi poi di quello che non si è riusciti a fare (ma credo che sia una cosa naturale che invecchiando ci si accorge di come il tempo passi in fretta).
Proprio per questo, mi sono già prefissato di cambiare moto… che 120 cavalli cominciano a essere pochi… almeno 160 ciò…