Quando devono essere elaborati diagrammi delle classi, diagrammi di flusso dei dati e diagrammi di flusso?

Dipende molto dalla metodologia di progetto che stai utilizzando (ad esempio Rational Unified Process versus Scrum) e quanto apprezzi la documentazione di processo rispetto al codice.

In alcuni contesti è importante che tutti i requisiti e le decisioni di progettazione siano tracciabili: perché abbiamo scelto questa alternativa, chi l'ha decisa, dove è stata implementata? Di solito, questo significa che una funzionalità è progettata separatamente prima di essere implementata, e il design è catturato con descrizioni testuali, diagrammi, ecc. Questi documenti sono deliverable di una fase di progettazione. Se hai questi requisiti, ovviamente i diagrammi dovrebbero essere creati prima di scrivere le tue lezioni.

D'altra parte, la maggior parte dei progetti non ha bisogno di documentare ogni fase del loro processo. In effetti, il movimento Agile favorisce esplicitamente "software funzionante su una documentazione completa". Il codice contiene già il design, quindi non è necessario creare diagrammi aggiuntivi. Ogni volta che vengono apportate modifiche al codice (nuove funzionalità aggiunte, bug corretti), il design cambia e i vecchi schemi non sono aggiornati. L'aggiornamento di tutti i documenti per riflettere le modifiche richiede un notevole sforzo che potrebbe essere altrimenti speso per aggiungere valore. Rallenta lo sviluppo.

C'è probabilmente una via di mezzo tra questi due estremi che è giusto per le tue circostanze. Per esempio, trovo che uno schizzo di un diagramma può essere un modo molto efficace per comunicare un'idea di design ad altre persone, e che diagrammi e panoramiche sono inestimabili per introdurre nuove persone in un sistema su cui dovrebbero lavorare. Il codice stesso contiene troppi dettagli di implementazione che riducono il design complessivo, quindi "leggere il codice" non è una buona risposta a "hai qualche diagramma che descrive la tua architettura?". Questo non significa che devo creare diagrammi dettagliati per ogni classe.

Uso gli elementi e le annotazioni della rete di Petri per creare programmi JavaScript che utilizzano l'API di Acrobat / JavaScript per le applicazioni del modulo PDF. Il metodo inizia con la creazione di un diagramma per stabilire le relazioni input-output degli elementi della rete (più alcune annotazioni), continua con la definizione di altre annotazioni in due forme e culmina con la scrittura del codice - basato su regole di codifica, la programmazione è una mappatura diretta da le annotazioni nel diagramma e le voci nei moduli ai codici JavaScript.

Se si inizia con i requisiti per il processo logico della propria applicazione, si dovrebbe considerare di iniziare con un diagramma (con un diagramma Petri Net, è possibile "generare" sistematicamente codici basati sulle annotazioni logiche e aggiungere altri tipi di annotazioni come parte della tua documentazione / presentazione / ecc.)

Se vieni premuto per un po 'di tempo, penso che sia molto importante iniziare con un diagramma (come il diagramma di una rete di Petri) che può essere mappato direttamente sui codici. Con la pratica passo meno tempo a eseguire il debug dei codici quando applico gli elementi e le annotazioni della rete di Petri alla programmazione del computer. E il diagramma mi aiuta a eseguire il debug della logica dell'applicazione.

La mappatura dal diagramma e le forme al codice è sistematica. Questo è il motivo per cui non mi interessa apportare modifiche al diagramma e rigenerare nuovamente i codici. Tuttavia è molto noioso. È possibile apportare modifiche allo schema e modificare in modo incrementale il codice correlato. Tuttavia, le modifiche incrementali al codice potrebbero richiedere più tempo e potrebbero essere più complesse rispetto alla completa rigenerazione del codice in determinate situazioni.