Si dovrebbe usare lo pseudocodice prima dell'effettiva codifica?

Lo pseudocodice ci aiuta a comprendere le attività in modo indipendente dal linguaggio. È buona pratica o approccio suggerito avere la creazione di pseudocodici come parte del ciclo di vita dello sviluppo? Per esempio:

• Identificare e dividere le attività di codifica
• Scrivi pseudocodice
• Ottieni l'approvazione [da PL o TL]
• Inizia la codifica basata su Pseudocodice

È un approccio suggerito? È praticato nel settore?

Scrivere pseudocodice prima della codifica è sicuramente meglio della semplice codifica senza pianificazione, ma è ben lungi dall'essere una buona pratica. Lo sviluppo guidato dai test è un miglioramento.

Ancora meglio è analizzare il dominio problematico e progettare soluzioni usando tecniche come user story, casi d'uso, schede CRC, diagrammi, come sposate con metodologie come Cleanroom, RUP, Lean, Kanban, Agile, ecc.

Comprendere a fondo la natura del problema e i componenti utilizzati per implementare la soluzione è il principio alla base delle migliori pratiche.

Uso i commenti come una specie di pseudo codice di altissimo livello, in quanto scrivo i commenti prima di scrivere il codice. Trovo che pensare a tutto il problema, anche a un livello elevato, migliora notevolmente il mio codice.

No, non prima pseudo-codice

Questo è troppo sovraccarico. Stai facendo il lavoro di scrivere la logica senza nessuno dei vantaggi. Suggerirei invece uno dei seguenti:

1. Prototipo nella lingua con cui spedirai (AKA Scriverne uno da buttare via )
2. Diagrammi di architettura con frammenti di codice per testare ipotesi / progetti chiave
3. Test Driven Development in cui si scrivono prima le interfacce / la struttura del codice, quindi i test, quindi l'implementazione del codice.

Tutti e tre questi ti portano direttamente alla tua soluzione, a differenza dello pseudo-codice. Personalmente tendo ad usare le tecniche 1 o 2 a seconda delle dimensioni della squadra. Per i team più piccoli (ad es. 5 persone o meno), la prototipazione funziona molto bene. Per i team più grandi che hanno più gruppi di sviluppatori che lavorano in parallelo, ho scoperto che la documentazione prodotta in anticipo dalla tecnica 2 funziona bene perché ti dà qualcosa da discutere in anticipo e ti aiuta a definire meglio i confini dei componenti. Sono sicuro che anche TDD funzionerebbe molto bene, ma devo ancora lavorare su un team che si è impegnato in questo processo.

Secondo me, lo pseudo-codice ha solo due scopi validi:

(1) Per gli studenti di programmazione che hanno bisogno di apprendere i concetti di modularità e algoritmi, ma non sono ancora fluenti in un linguaggio di programmazione.

(2) Comunicare come funzionerà qualcosa a una persona non tecnica, o semplicemente per motivi di opportunità in una riunione di tipo lavagna.

Lo pseudo-codice è un approccio suggerito? Per i programmatori principianti, dico di sì. Aiuta il nuovo programmatore a imparare come tradurre un problema in codice senza preoccuparsi dell'esatta sintassi della lingua. Ciò modella il processo di pensiero e può aiutare a radicare abitudini utili (e suppongo anche cattive abitudini). Questo è il motivo per cui è usato così tanto nelle scuole.

È praticato nell'industria? Nella mia esperienza, no. Nessuno ha il tempo di analizzare il progetto tra la documentazione (requisiti, specifiche, storyboard, casi d'uso o qualsiasi altra cosa utilizzino) e il codice effettivo. Si presume generalmente che il problema sia già stato inserito nel problema prima del semaforo verde da codificare. A quel punto, codificare il progetto è più importante dell'aggiunta di un ulteriore livello di preparazione del progetto.

Consiglio vivamente pseudocodice. Ti aiuta a chiarire cosa stai per fare e identificare gli elementi che potresti aver dimenticato o potenziali problemi. È molto più facile / veloce riparare il tuo codice quando è ancora in fase di pianificazione piuttosto che aspettare fino a quando non avrai già codificato gran parte di esso.

Lo pseudocodice può essere utile se non si ha familiarità con la lingua o se è necessario modificare i contesti mentali. Nella rara occasione in cui scrivo pseudocodice, è su carta. A volte semplicemente staccare le mani dalla tastiera e scarabocchiare sulla carta può aiutare a aggirare un blocco mentale.

Ma come parte formalizzata del processo di sviluppo? Non c'è modo. È uno strumento sporadicamente utile per gli individui. Esistono modi migliori per "sapere cosa stai scrivendo prima di scriverlo", come:

1. definire il contratto (condizioni pre / post / invarianti) del metodo prima di iniziare
2. TDD
3. 1 e 2 combinati (scrivere test per eseguire il contratto)

Suggerirei anche che ottenere qualsiasi tipo di approvazione prima di iniziare a scrivere il codice possa causare molta più seccatura di quanto valga la pena. Le revisioni del progetto (pre-implementazione) possono essere utili, ma devono essere di livello superiore rispetto ai singoli algoritmi.

Non sarò d'accordo con le risposte precedenti e dirò di no, ma con un avvertimento: puoi sbarazzarti del codice psuedoc solo se ti dedichi febbrilmente al refactoring del tuo codice per affrontare i problemi che sorgono. Psuedocode è, nella sua essenza, un modo per definire il tuo codice prima di definirlo; è un'astrazione inutile in molte circostanze, e poiché il tuo codice non sarà mai perfetto la prima volta (e probabilmente, non seguirà il progetto del codice ps fino al completamento), mi sembra estraneo.

Se stai scrivendo COBOL o C, lo pseudocodice può essere utile perché scrivere il codice effettivo richiederà molto più tempo e se puoi verificare il tuo algoritmo / requisiti dallo pseudocodice, puoi risparmiare un po 'di tempo.

Nelle lingue più moderne, lo pseudocodice non ha molto senso. Ciò che funzionerebbe meglio è scrivere gli stub dei metodi e compilare la logica di livello superiore e tutti i dettagli necessari per verificare l'algoritmo e i requisiti, tutto questo nel codice reale. È quindi possibile mostrare tale codice al responsabile del team per l'approvazione e avere già avviato il codice reale.

Le uniche volte in cui ho usato lo pseudocodice negli ultimi 10 anni sono intervistate quando lavoriamo su una lavagna e la lingua particolare non ha importanza.

È certamente utile per parlare attraverso un processo / algoritmo in termini sciolti senza impantanarsi con la sintassi. Ad esempio, scrivere una classe C ++ che ha proprietà C #, solo per illustrare il punto.

Ha il suo posto, ma dovrebbe essere usato solo dove necessario (è un lavoro che butterai via) e certamente non fa parte di un processo formale, a meno che tu non abbia standard di tipo ISO che insistano su di esso.

Per me e per le persone con cui ho lavorato negli ultimi anni, lo pseudocodice si è praticamente trasformato in un codice reale non del tutto perfetto. a meno che non lavori con molte lingue contemporaneamente, la maggior parte delle persone sembra iniziare a pensare nel modello generale della loro lingua principale. Ho lavorato nei negozi .net per un po ', quindi la maggior parte degli scarabocchi di lavagna in ufficio tendono ad apparire come vb o c # con alcuni segni di punteggiatura mancanti.

L'esercizio è ancora prezioso quando si discutono opzioni e simili, ma il linguaggio agnostico tende a spostarsi man mano che passi più tempo con poche lingue.

Sempre più, lo pseudocodice è scritto graficamente con strumenti come UML. Ad esempio, prova yUML .

uno strumento online per la creazione e la pubblicazione di semplici diagrammi UML. Ti rende davvero facile:

• Incorpora diagrammi UML in blog, e-mail e wiki.
• Pubblica diagrammi UML nei forum e nei commenti sul blog.
• Utilizzare direttamente nello strumento di tracciamento dei bug basato sul Web.
• Copia e incolla diagrammi UML in documenti MS Word e presentazioni Powerpoint ...

... yUML ti fa risparmiare tempo. È progettato per coloro a cui piace creare piccoli diagrammi e schizzi UML.

Senza yUML, la creazione di un diagramma UML potrebbe comportare il caricamento di uno strumento UML, la creazione di un diagramma, l'assegnazione di un nome, la manipolazione del layout, l'esportazione in bitmap e il caricamento online da qualche parte. yUML non ti fa fare nulla del genere ...

Ottimo lavoro. Hai iniziato una buona discussione. A partire da me, scrivevo pseudo codici mentre stavo imparando la programmazione per capire i vari loop e algoritmi. Questo è stato più di un decennio e mezzo fa. In quei giorni, anche i linguaggi di programmazione non erano molto potenti ... e la programmazione guidata dagli eventi era futura. Ora con 4GL e 5GL, pensiamo nella lingua stessa piuttosto che in un inglese semplice. Quando pensiamo a un problema, pensiamo in termini di oggetti e operazioni. E fino a quando non è un algo complesso, scrivere pseudo codici (o codici PSEU-DO, solo scherzando) non ha alcun senso. Meglio, rappresentare la soluzione in modo grafico.

Dipende dalla lingua utilizzata e dalla tua familiarità con essa.

Molti linguaggi moderni come Python o Java sono già così vicini allo pseudocodice che scrivere prima uno pseudocodice ad hoc è uno spreco, IMHO. Meglio farlo subito usando l' approccio proiettile tracciante .

È un affare diverso se stai facendo qualcosa di basso livello, vicino alle cose metal, o non sei ancora a tuo agio con la lingua che stai usando. Quindi lo pseudocodice può essere sicuramente utile.

Ci sono un paio di circostanze in cui lo pseudocodice tende a scoppiare nel mio lavoro, che è nel mondo accademico in cui la programmazione tende ad essere utilizzata come uno strumento o il "e ora lo risolviamo" compilando nel mezzo di un progetto:

1. Quando il codice sarà più controproducente per una reale comprensione di ciò che accadrà di quanto lo sarà lo pseudo-codice. SAS, ad esempio, occuperà metà della lavagna facendo alcune attività di programmazione abbastanza basilari. Vedi anche C, di cui alcuni altri poster hanno discusso.
2. Con un sacco di analisi dei dati e codifica delle statistiche, si tende a armeggiare con il codice man mano che vengono generati i risultati. Lo pseudocodice è in qualche modo più facile da usare per "qui sta un processo avanti e indietro, se il diagramma diagnostico non sembra corretto, prova X".
3. Gli studenti imparano molti linguaggi di programmazione diversi. Ad esempio, tra le persone che conosco, un problema statistico potrebbe essere analizzato in SAS, R o Stata. Qualcosa che richiede qualcosa di più vicino alla programmazione tradizionale potrebbe essere fatto in R, Matlab, C, C ++, Java, Python ... dipende davvero da quale particolare studente sta implementando il programma e per quale scopo. Ma è ancora utile per le persone Java, Python e Matlab avere un'idea comune di cosa stanno facendo gli altri e di come funziona l' approccio , piuttosto che il codice stesso.

Questo non è un tipo di domanda sì / no. Piuttosto, ci si dovrebbe chiedere quando usare lo pseudo-codice. È importante comprendere il problema prima di progettare una soluzione ed è importante avere una visione chiara della soluzione prima di implementarla. Lo pseudo-codice può essere utilizzato in uno di questi passaggi:

1. Quando si definisce il problema, è comune scrivere i casi d'uso, a volte usando sequenze di azioni.
2. Quando si progetta una soluzione. I diagrammi di classe sono belli, ma descrivono solo la parte "statica", cioè i dati. Per la parte dinamica, non appena è necessario gestire un ciclo e dati non banali, trovo che lo pseudo-codice sia il miglior metodo disponibile. Le alternative grafiche includono macchine a stati (buone per flussi di controllo complessi con pochi dati) e diagrammi di flussi di dati (buone per flussi semplici con dati complessi).
3. Quando si implementa la soluzione (o appena prima). Alcuni linguaggi di programmazione sono difficili da leggere (pensare, assemblare). Una rappresentazione alternativa può essere preziosa in questo caso. Se non hai familiarità con le lingue, vale anche la pena farlo.

Viene utilizzato anche lo pseudo-codice che in realtà è il codice corretto in un linguaggio di alto livello, di solito si chiama prototipazione.

Oltre a raggiungere la comprensione, lo pseudo-codice è anche buono per la comunicazione.

Se ti stai chiedendo se dovresti usare lo pseudo-codice su base regolare, sono personalmente contrario a tutti i tipi di regole rigide. Questo può facilmente trasformarsi in una noiosa perdita di tempo se utilizzato per problemi insignificanti che tutti nel team capiscono. L'uso di pseudo-codice per le specifiche che si mantengono per tutta la durata del progetto può anche essere costoso e offrire poco valore.