È accettabile chiedere la gestione per lo pseudo codice? [chiuso]

Non chiedere pseudocodice. Se i tuoi superiori pensassero che ne avevi bisogno, l'avrebbero già provveduto.

Ecco cosa dovresti fare invece:

Verifica i requisiti

Se non è testabile, non è un requisito; è una funzione o un desiderio.

Più specificamente, ogni singolo requisito dovrebbe essere SMART :

• specifico
• misurabile
• assegnabili
• Realistici
• Timely

Raccogli i tuoi requisiti in modo tale che siano specifici sufficienti per scrivere codice contro, misurabili abbastanza da consentire a te e al cliente di concordare un criterio per dichiarare il successo, assegnabile a qualcuno che può eseguire il lavoro, realistico abbastanza da essere raggiungibile e tempestivo (puoi stimare il tempo di completamento e impostare le scadenze) .

Ulteriori letture
Padroneggiare il processo dei requisiti: ottenere i requisiti giusti (terza edizione)

Chiedere lo pseudocodice, secondo me, deriva da frustrazione che i requisiti sono ambigui e non abbastanza chiari.

Sono d'accordo con Robert Harvey sul fatto che i requisiti correttamente scritti dovrebbero - dovrebbe - annullare la necessità di avere uno pseudocodice a portata di mano.

Scrivere uno pseudocodice potrebbe essere una specie di esercitazione pratica per il management per far capire quanto sono stati imprecisi.

Forse un grande esercizio, ma non siamo in grado di insegnare loro, e puzza di compiti a casa come punizione per me ("Non darò orientamenti ambigui, non darò ..."). Scrivere pseudocodice impone precisione, ma al costo di imporre certe formalità.

Quale pseudocodice sarebbe, comunque?

1. Dell'implementazione che vuoi consegnare?

2. O dell'ipotetico test unitario di questa implementazione?

Questa è una distinzione molto importante.

1. Questo non è proprio il loro lavoro. Non hanno alcun business nel progettare, o nemmeno sapere cosa c'è dentro la blackbox, a patto che la scatola faccia il trucco. La stessa logica di business potrebbe avere rappresentazioni algoritmiche molto diverse e spetta al programmatore scegliere quella che gli piace.

2. Sono d'accordo! Ora puoi scrivere la tua implementazione in qualsiasi modo tu sembri in forma, purché superi il test. Come TDD / BDD.

Quindi ora siamo nel campo da baseball.

Perché una suite di test scritta correttamente legge come una buona spec.

In effetti, alcuni framework davvero offuscano la distinzione tra specifiche e test. Dai un'occhiata a Cetriolo , ad esempio (attenzione, io non sono in alcun modo affiliato con il prodotto).

1: Describe behaviour in plain text

2:WriteastepdefinitioninRuby

3: Run and watch it fail (TBC)

L'essenza della fornitura di prodotti per i clienti è capire il processo di comunicazione. Spesso le specifiche non sono inizialmente chiare e dovrai spostare le cose in quella direzione. Dovrai porre tutte le domande necessarie fino a quando non avrai compreso il processo aziendale in relazione al tuo caso d'uso. Spesso questo significa che parli con un esperto (di solito un analista di business).

Se non riesci a comprendere le specifiche del processo, hai poche speranze di scrivere codice corretto. In definitiva, il tuo codice dovrebbe articolare chiaramente il processo. In altre parole, scrivi il codice in modo che mostri e comprenda cosa dovrebbe accadere. Normalmente, si desidera utilizzare variabili denominate per esprimere le transizioni da uno stato iniziale a uno stato finale. La maggior parte dei processi sono macchine di stato di una forma o di un'altra indipendentemente dal fatto che la macchina di stato sia esplicita nel codice.

Se pensi che ti sarà d'aiuto, sì, chiedigli uno pseudo-codice. O, forse, descrizioni più specifiche dei processi di livello inferiore. O un diagramma di flusso, anche. Se sono dirigenti con un interesse acquisito nel completare con successo un progetto, perché dovrebbero avere un problema con la richiesta?

Se, tuttavia, trovi che ti serve spesso lo pseudo-codice, allora c'è chiaramente un problema di comunicazione tra te e loro. O non sono abbastanza chiari e / o non sei molto bravo a convertire le richieste in codice.

Hai ricevuto requisiti intricati, con logica di business non del tutto chiara e contesti ancora molto vaghi. Il problema è che chiedere "pseudo-codice" andrà a metà strada, senza troppo amore, e poi ti ostacolerà nello sviluppo; di mezzo inteso o non ben preso le decisioni. Probabilmente si ritorcerà contro anche.

Crea una story-board da essa, parte del design del codice e cerca di portare dettagli concreti da portare. Piccole scene strutturate, storie. Comunicare che si sta facendo proprio questo e dopo un po 'comunicare con le persone sul materiale.

La migliore forma di documento, con schermate raffigurate. Ora la documentazione non dovrebbe avere molti overhead, ma il mio ideale sarebbe un formato come docbookx, che è versionable, conserva i diagrammi separatamente. Ma non dovrebbe richiedere più tempo e molta energia, quindi vai per docx / odt altrimenti. Unzippable e quindi versionable.

Se poi puoi portare la struttura nel suo insieme, hai fatto la metà dell'implementazione. Sai cosa c'è dentro. Dovresti essere in grado di ottenere feedback sulla maggior parte dei problemi. Priorità per esempio.

Durante l'implementazione, puoi dare una panoramica del lavoro svolto.