Assolutamente.

Ogni volta che sto implementando qualcosa che non ho mai fatto prima (e l'algoritmo richiede più di pochi passaggi), lo tracciamo. Trovo che mi costringa davvero ad analizzare l'intera soluzione a un livello più atomico e più approfondito rispetto a quando non è stato tracciato. Trovo che ci siano tre principali vantaggi in questa pratica:

• Meno "oh craps" perché ho pensato all'intero algoritmo attraverso
• Risolve qualsiasi potenziale problema sui problemi che possono verificarsi nel resto del sistema
• Mi consente di camminare facilmente qualcun altro attraverso l'algoritmo

Le due diverse occasioni in cui effettivamente utilizzo sono:

• Algoritmi di livello basso (ish). Intendo una soluzione molto specifica per un problema molto specifico. Generalmente li passerò dai colleghi prima dell'implementazione.
• Flusso utente. Non solo posso usarlo per passare un peer, ma lo userò anche per spiegare (in modo molto non tecnico) il flusso a un esperto di usabilità.

Detto questo, non produco diagrammi di flusso ogni giorno (e anche quando hanno finito, è generalmente una sessione di lavagna a meno che non scriva un documento di progettazione tecnica).

Mai

I diagrammi di flusso, specialmente se praticati più di 25 anni fa, sono stati sostituiti da tecniche di diagrammi molto più espressive (c.f. Diagrammi di azione, Grafici di sequenza, Diagrammi di stato, ecc.)

Gli studi di IBM hanno dimostrato che l'uso dei diagrammi di flusso non ha avuto alcun effetto sulla qualità della progettazione o dell'implementazione di un sistema (sebbene fossero marginalmente utili per comunicare con gli utenti e altri sviluppatori) [riferimento preciso non facilmente disponibile, ma citato in James Tecniche di diagrammi di Martin per analisti e programmatori ].

Non ho disegnato un diagramma di flusso classico dalla mia prima classe di programmazione nel 1976, e non ho visto nessun altro crearne uno sin dai primi anni '80. I diagrammi di flusso erano utili per comunicare la logica del programma quando il codice era in linguaggio assembly. Verso la fine degli anni '60, i programmatori di linguaggio assembly usavano lo pseudo-codice. Quando si programma nei moderni linguaggi OO, né i diagrammi di flusso né lo pseudo-codice hanno alcun valore. Potresti scrivere codice di alto livello nella lingua di implementazione.

Di tanto in tanto disegna diagrammi UML, principalmente su carta, per esprimere idee di design, ma questi diagrammi vivono solo fino alla fine della discussione. Traccio anche i diagrammi di transizione di stato di volta in volta, quindi li converto in una tabella di stato nel linguaggio di implementazione.

Uso sempre i diagrammi di flusso per una serie di motivi:

1. Sono a mio parere migliori dei diagrammi dei casi di utilizzo di UML. Possono riflettere un numero di casi d'uso diversi e il loro modo di interagire, e fanno un lavoro migliore nel complesso portando l'esperienza dell'utente e le decisioni insieme.

2. Sono più facili da capire e più intuitivi. La tua mente segue naturalmente le frecce come un labirinto dall'inizio alla fine. È possibile utilizzare i diagrammi di flusso per terminare e fare riferimento a un altro diagramma di flusso per una diversa user story. In genere posso stamparli in un libro numerato da una pagina e capovolgere rapidamente le pagine per passare al prossimo diagramma di flusso.

3. Sono universali. Poche persone al di fuori dell'ingegneria del software conoscono e comprendono i diagrammi UML, in cui i diagrammi del diagramma di flusso sono molto più riconoscibili dagli utenti e dagli analisti aziendali. Cerco di comunicare casi d'uso complessi a un cliente e a volte fatica a comprenderli, disegno loro un diagramma di flusso e capiscono perché alla fine capiscono tutte le sfumature che lo rendono MOLTO PIÙ complesso di quanto pensassero.

I diagrammi di flusso sono utili quando le cose devono essere fatte in un ordine specifico. Dove realmente brillano nella mia mente sta mostrando dove sono prese le decisioni e facendo in modo che ogni possibile decisione abbia un percorso. Questo impedisce la creazione di programmi in cui è richiesta l'approvazione di mamager, ma non ha modo di affrontarla se il manager (che approva il 98% delle volte) dice no. Ci ricordano che il percorso più comune non è l'unico percorso. Li trovo utili nel parlare agli utenti dei requisiti perché spesso ti diranno solo il percorso più comune.

I diagrammi di flusso possono essere utili per il codice di ingegneria molto mal strutturato. Soprattutto se ha gotos. Per fortuna non ho visto molto codice goto-riddden di recente.

Come altri hanno notato per comunicare con gli utenti finali. Ordinamento l'avvio di un trasmettitore TV documentato dal diagramma di flusso. Le persone dell'hardware e del software avevano una specifica comune su cui lavorare.

Il diagramma di attività UML e il diagramma di flusso sono utili per mostrare la complessità medio-bassa di un processo o di un algoritmo.

Sono molto buoni quando comunicano con gli utenti aziendali in merito alle regole aziendali.

Esiste una variazione sulla forma di BPMN 2.0 che è molto utile in Business Process Modelling.

Alcuni strumenti BPMN possono generare l'esecuzione di applicazioni Web dai grafici.

Quindi sì, i diagrammi di flusso hanno ancora un posto, ma devono essere usati con saggezza.

Non sono un programmatore. Sono un tecnico dell'ingegneria dell'hardware.

Per me ha senso iniziare almeno con commenti che spieghino i blocchi logici che verranno utilizzati. Dopo, estrapola lo scheletro del programma con il codice effettivo. È simile all'avvio di uno script di un film con una story board e successivamente alla compilazione dei dettagli dell'azione e della finestra di dialogo.

Non dovrebbe essere pianificato attentamente qualche sforzo utile? Nell'ambito dell'hardware, iniziamo con un documento di richiesta del cliente, quindi scriviamo un documento con le specifiche dell'hardware, quindi estrapoliamo lo schema, quindi tracciamo un layout della scheda, quindi forniamo la documentazione dell'assembly. Non iniziamo semplicemente ad afferrare le parti e a saldarle insieme per trovare le idee per realizzare il prodotto finale.

Non vedo quanto un codice efficiente possa essere scritto in un programma da 15KB o 15MB senza un sacco di lavoro di preparazione prima di iniziare l'attuale codifica.