Progettazione software mediante pseudocodifica?

 I thought agile is about schedule only?

Non è solo pianificazione. Lo sviluppo di software agile riguarda più lo sviluppo evolutivo e la distribuzione iterativa in time-box con la pianificazione adattativa che incoraggia la risposta flessibile alle modifiche richieste dal proprietario del prodotto.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Nella mia esperienza, i grafici sono molto più facili da comprendere dal punto di vista del cliente. Sono visivamente accattivanti e molte volte molto colorate e facili da seguire. Tuttavia, è molto difficile mantenere i grafici a causa della natura della disconnessione con il codice dell'applicazione reale. Ogni volta che viene apportata una modifica all'applicazione, lo sviluppatore deve prendersi il tempo necessario per aggiornare tutta la documentazione, inclusi i grafici. Tuttavia, questo problema può essere facilmente eliminato una volta che c'è un BA nel team o nella società, che comprende bene il processo aziendale del cliente e può gestire i diagrammi UML.

Strumenti come UML possono semplificare questo processo ma funzionano bene solo con la programmazione orientata agli oggetti. Lo pseudo codice è molto più semplice per i team tecnici. Il processo di creazione di questo codice aumenta notevolmente la velocità della fase di sviluppo del linguaggio di programmazione effettiva.

Ci sono altre alternative che potresti avere anche tu:

• Diagrammi del flusso di dati
• Diagrammi di stato
• Diagrammi di flusso di processo

Buoni riferimenti per guardare: Tutorial sulla progettazione software . Inoltre, consiglierei personalmente di leggere un buon blog su Pseudocodice o codice? pubblicato da Coding Horror - il mio blog preferito da leggere:)

Tutto sommato, ci sono alcuni compromessi che è necessario prendere in considerazione.

Quando si programma in linguaggio assembly, scrivere pseudo-codice ha molto senso. L'algoritmo potrebbe essere verificato prima di impiegare lo sforzo per tradurlo manualmente in linguaggio assembly e quindi eseguire il debug della traduzione. Aveva ancora un senso per i linguaggi compilati di prima generazione come FORTRAN IV, dove l'unico costrutto di controllo era GOTO, tutte le variabili (eccetto gli argomenti formali) erano globali ei nomi delle variabili erano limitati a sei caratteri.

Oggi facciamo pochissima programmazione nel linguaggio assembly, e vedo poco valore nello scrivere pseudo-codice invece di scrivere solo codice. In un linguaggio decente, il codice effettivo seguirà lo pseudo-codice quasi parola per parola, e lo pseudo-codice è solo una perdita di tempo.

Tuttavia, non inizio la codifica in basso. Seguo TDD e inizio con un test. Quindi inizio a scrivere il codice in alto e gradualmente riesco a spostarlo verso il basso in base alle necessità per far passare i test.

L'alternativa allo pseudo-codice non sta scrivendo 1000 righe di classi di basso livello. Inizia invece in alto, chiamando l'API ideale ma inesistente per il tuo dominio. Quindi crea l'API.

Trovo che gli schemi di classe valgano a malapena lo sforzo, anche quando si salta l'elenco di tutti i metodi e si mostra semplicemente la gerarchia dell'ereditarietà. I diagrammi di sequenza sono buoni, ma si sentono scomodi quando li disegno (probabilmente solo io).

Trovo che i diagrammi di flusso dei dati e i diagrammi delle strutture siano più utili (anche se i diagrammi di struttura sono comunemente associati a BDUF e sono quindi sfavorevoli al momento). I DFD sono particolarmente utili per la decomposizione funzionale. Ogni "bolla" in un DFD può essere scomposto nel suo DFD fino a raggiungere il livello di dettaglio desiderato.

Penso che gli strumenti grafici siano migliori della pseudocodifica, ma UML è semplicemente così complicato che combina il male con quei metodi: -)

Per essere un po 'più chiari: penso che la programmazione sia principalmente un modo per analizzare un certo problema, separarlo dai componenti più piccoli e dalla loro interazione. Questo è "un viaggio, non una destinazione", migliora costantemente la tua conoscenza del problema, quindi il grafico dei componenti sta cambiando: i livelli appaiono e svaniscono, le funzioni e gli elementi dei dati si spostano su e giù, ecc.

Lo strumento naturale per seguire questo processo è uno sketchboard, il più semplice possibile, ma abbastanza complesso da consentire una rapida comprensione (stessi colori, forme, frecce per lo stesso significato logico). Non ho trovato il proiettile d'argento, e forse scriverò il mio un giorno, ma ora uso gliffy ; combinato con la funzione di zoom di prezi sarebbe quasi perfetto.

Perché non lo pseudocodifica? Lo pseudocodice è un passo avanti verso l'implementazione, una "forma serializzata del grafico del componente", quando si formano ancora le tue idee. Non va bene, limita la testa. Nella mia esperienza ho scoperto che più tardi comincio a codificare, meno codice devo buttare via ...

Ma forse è perché ho scritto tutti quei codici buttati fuori, quindi non devo scriverli ora, l'esperienza che ho acquisito da loro è con me quando progetta il sistema? Bene, devo modificare la dichiarazione.

Se ti perdi con il tuo grafico e vedi molte possibili soluzioni equivalenti, vai allo pseudocodice, o scrivi anche quel codice con gli oggetti mock: in Java, non c'è differenza. Guarda il codice, senti la struttura e l'usabilità di questi componenti, ti aiuterà a correggere il tuo grafico e prendere decisioni. Ma funziona SOLO se sei pronto a buttare via quel codice se ritieni che sia male. Penso che questo sia il vantaggio dello pseudocodice: meno la tentazione di mantenerlo quando funziona, ma è sbagliato nella struttura (e come sempre, non hai abbastanza tempo). : -)