Se uno pseudo uso prima di codifica reale?

Question

Pseudocodice ci aiuta a comprendere compiti in modo indipendente dal linguaggio. E 'meglio pratica o approccio suggerito di avere creazione pseudocodice come parte del ciclo di sviluppo? Per esempio:

• Identificare e dividere i compiti di codifica
• Scrivi pseudocodice
• farlo approvare [da PL o TL]
• iniziare a scrivere codice basato sul Pseudocodice

E 'questo un approccio suggerito? È praticata nel settore?

Answer 1

Scrivendo pseudocodice prima di codifica è certamente meglio di una semplice codifica senza pianificazione, ma è ben lungi dall'essere una pratica migliore. sviluppo test-driven è un miglioramento.

Ancora meglio è quello di analizzare il dominio del problema e le soluzioni di progettazione utilizzando tecniche come le storie degli utenti, casi d'uso, le schede CRC, diagrammi, come esposto da metodologie, come camere bianche, RUP, magra, Kanban, Agile, ecc.

comprendere a fondo la natura del problema e le componenti da utilizzare per implementare la soluzione è il principio alla base delle migliori pratiche.

Answer 2

Io uso i commenti come una sorta di molto pseudo codice di alto livello, nel senso che io scrivo i commenti prima di scrivere il codice. Trovo che il pensiero attraverso l'intero problema, anche ad alto livello, migliora notevolmente il mio codice.

Answer 3

No, non pseudo-codice prima

Questo è troppo alto. Stai facendo il lavoro di scrittura della logica con nessuno dei vantaggi. Io suggerirei una delle seguenti invece:

1. Prototype nella lingua che si sta andando a spedire con (AKA Scrivi un buttare via )
2. diagrammi Architettura w / code snippets a ipotesi di test / disegni chiave
3. Test Driven Development in cui si scrivono le interfacce / struttura del codice prima, seguita da test, seguiti da l'attuazione del codice.

Tutti e tre questi mossa che direttamente verso la soluzione, a differenza di pseudo-codice. Personalmente tendo ad utilizzare tecniche di 1 o 2 a seconda delle dimensioni della squadra. Per i più piccoli team (ad esempio 5 meno persone o), la prototipazione funziona molto bene. Per le squadre più grandi che hanno più gruppi di sviluppatori che lavorano in parallelo, ho trovato che la documentazione prodotta dalla tecnica precoce 2 funziona bene perché ti dà qualcosa da discutere presto e aiuta a definire i confini dei componenti meglio. Sono sicuro che TDD avrebbe funzionato molto bene anche, ma devo ancora lavorare su una squadra che aveva commesso a questo processo.

Answer 4

A mio parere, pseudo-codice ha solo due scopi validi:

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

(2) Per comunicare come qualcosa lavorerà per una persona non tecnica, o solo per il gusto di opportunità in un incontro di tipo bianco-board.

Answer 5

è pseudo-codice di un approccio suggerito? Per i programmatori inesperti, dico di sì. Aiuta il nuovo programmatore imparare a tradurre un problema in codice senza preoccuparsi della sintassi esatta del linguaggio. Questo dà forma al processo di pensiero e può aiutare Radicamento utili abitudini (e suppongo cattive abitudini troppo). Questo è il motivo per cui è usato nelle scuole così tanto.

E 'praticata nel settore industriale? Nella mia esperienza, no. Nessuno ha il tempo di sgrossare il progetto tra la documentazione (requisiti, le specifiche, story board, casi d'uso o qualsiasi altra cosa che usano) e il codice vero e proprio. Si ritiene generalmente che il pensiero sufficiente è già stata messa nel problema prima del semaforo verde al codice. A quel punto, la codifica il progetto è più importante di aggiungere un altro strato di preparazione del design.

Answer 6

Consiglio vivamente pseudocodice. Ti aiuta a chiarire che cosa avete intenzione di fare e identificare gli oggetti che si possono avere dimenticato o potenziali problemi. La sua molto più facile / più veloce per risolvere il tuo codice quando è ancora in fase di pianificazione piuttosto che aspettare fino a quando hai già codificato una gran parte di esso.

Answer 7

Pseudocodice può essere utile se non si ha familiarità con la lingua, o se è necessario modificare i contesti mentali. In rare occasioni in cui scrivo pseudocodice, è sulla carta. A volte basta togliere le mani dalla tastiera e scarabocchi su carta può aiutare a ottenere intorno a un blocco mentale.

Ma come parte formalizzata del processo di sviluppo? Non c'è modo. E 'uno strumento utile per gli individui sporadicamente. Ci sono modi migliori di "sapere quello che stai scrivendo prima di scrivere", come:

1. la definizione del contratto di (pre / post / condizioni invarianti) del metodo prima di iniziare
2. TDD
3. 1 e 2 combinati (scrivere i test per l'esecuzione del contratto)

Vorrei anche suggerire che ottenere qualsiasi tipo di approvazione prima di iniziare a scrivere il codice può causare molto più problemi di quanto ne vale la pena. revisioni di progetto (pre-implementazione) possono essere utili, ma hanno bisogno di essere ad un livello superiore a quello singoli algoritmi.

Answer 8

ho intenzione di essere in disaccordo con le risposte precedenti e non dire, ma con un avvertimento: si può sbarazzarsi di psuedocodarlo solo se si sta febbrilmente dedicato al refactoring il codice per affrontare i problemi che emergono. Psuedocodarlo è, a sua essenza, un modo di definire il codice prima di definire il codice; si tratta di un'astrazione non necessaria in molte circostanze, e dal momento che il codice non sarà mai perfetto la prima volta (e probabilmente, non segue il design della psuedocodarlo a compimento), sembra estranea a me.

Answer 9

Se si scrive COBOL o C, pseudocodice può essere utile perché scrivere il codice vero e ci vorrà molto più tempo, e se è possibile verificare l'algoritmo / requisiti dal pseudocodice, è possibile risparmiare un po 'di tempo.

In linguaggi più moderni, pseudocodice non fanno molto senso. Cosa funzionerebbe meglio sta scrivendo metodo mozzi, e riempiendo il livello logico alto, e più dettagli necessario per verificare l'algoritmo e requisiti, tutto questo in codice effettivo. È quindi possibile dimostrare che il codice per il team guidato per l'approvazione, e hanno il codice vero e proprio già avviato.

Answer 10

Le uniche volte che ho pseudocodice utilizzato negli ultimi 10 anni sono il colloquio quando stiamo lavorando su una lavagna e il particolare linguaggio non importa.

E 'certamente utile per parlare attraverso un processo / algoritmo in termini sciolti senza impantanarsi con la sintassi. Per esempio. scrivendo una classe C ++ che ha C Proprietà #, proprio per illustrare il punto.

E ha il suo posto, ma deve essere utilizzato solo se necessario (è un lavoro che ti buttare via) e di certo non fa parte di un processo formale, a meno che non si dispone di standard ISO-tipo che insistono su di esso.

Answer 11

For myself and the people I have worked with for the last few years pseudocode has pretty much turned into not entirely perfect real code. unless you work with many languages at the same time, most people seem to start thinking in the general pattern of their main language. I have worked in .net shops for a while so most people's whiteboard scribbles around the office tend to look like vb or c# with some of the punctuation missing.

The exercise is still valuable when debating options and such, but the language agnostic bit tends to drift away as you spend more time with a few languages.

Answer 12

More and more, pseudocode is written graphically with tools like UML. For instance, try out yUML.

an online tool for creating and publishing simple UML diagrams. It's makes it really easy for you to:

• Embed UML diagrams in blogs, emails and wikis.
• Post UML diagrams in forums and blog comments.
• Use directly within your web based bug tracking tool.
• Copy and paste UML diagrams into MS Word documents and Powerpoint presentations...

...yUML saves you time. It's designed to for those that like to create small UML diagrams and sketches.

Without yUML, creating a UML diagram might involve loading up a UML tool, creating a diagram, giving it a name, fiddling with layout, exporting it to bitmap, and then uploading it online somewhere. yUML doesn't make you do any of that...

Answer 13

Great work. You started a good discussion. As of me, I used to write pseudo codes when I was learning programming to understand the various loops and algorithms. This was more then one and half decades ago. That days, even programming languages were not much powerful... and event driven programming was future. Now with 4GLs and 5GLs, we think in the language itself rather then in plain English. When we think of a problem, we think in terms of objects and operations. And until it is a complex algo, writing pseudo codes (or P-S-E-U-DO-Codes, just kidding) does not make any sense. Better, represent the solution in a graphic way.

Answer 14

Depends on the language used, and your familiarity with it.

Many modern languages such as Python or Java are already so close to pseudocode that writing some ad hoc pseudocode first is wasteful, IMHO. Better just do it right away using the tracer bullet approach.

It's a different deal if you're making some low-level, close to metal things, or aren't yet comfortable with the language you're using. Then pseudocode can definitely be useful.

Answer 15

There tend to be a couple circumstances where pseudocode tends to get broken out in my work, which is in academia where programming tends to get used as a tool or the "and now we solve it" filling in the middle of a project:

1. When the code is going to be more counter-productive to an actual understanding of what's going to happen than pseudo-code will be. SAS for example, will take up half the whiteboard doing some fairly basic programming tasks. See also C, which some other posters have discussed.
2. With a lot of data analysis and statistics coding, there tends to be a lot of tinkering with the code as results are generated. Pseudocode is somewhat easier to use for "herein lies a back-and-forth process, if the diagnostic plot doesn't look right, try X".
3. Students learn lots of different programming languages. For example, among people I know, a statistics problem might be analyzed in SAS, R or Stata. Something that requires something closer to traditional programming might be done in R, Matlab, C, C++, Java, Python... it really depends on what particular student is implementing the program, and for what purpose. But it's still useful for the Java people and the Python people and the Matlab people to have a joint idea of what the others are doing, and how the approach, rather than the code itself, works.

Answer 16

This is not a yes/no kind of question. Rather, one should wonder when to use pseudo-code. It is important to understand the problem before designing a solution, and it is important to have a clear view of the solution before you implement it. Pseudo-code can be used in any of these steps:

1. When defining the problem, it's common to write down use cases, sometimes using sequences of actions.
2. When designing a solution. Class diagrams are nice, but they only describe the "static" part, i.e. the data. For the dynamic part, as soon as you need to deal with a loop and non-trivial data, I find pseudo-code to be the best method available. Graphical alternatives include state machines (good for complex control flow with little data) and dataflow diagrams (good for simple flows with complex data).
3. When implementing the solution (or just before). Some programming languages are hard to read (think, assembly). An alternative representation can be valuable in this case. If you are unfamiliar with the languages, it's also worth doing.

Pseudo-code that's actually proper code in a high-level language is also used, it's usually called prototyping.

In addition to achieving understanding, pseudo-code is also good for communication.

If you are wondering if you should use pseudo-code on a regular basis, I am personally against all kinds of rigid rules. This can easily turn into a boring waste of time if used for trivial problems everybody in the team understands. Using pseudo-code for specifications that you maintain throughout the project's life can also be costly and offer little value.