Deve-se usar o pseudocódigo antes da codificação real?

O pseudocódigo nos ajuda a entender as tarefas de maneira independente do idioma. É uma boa prática ou abordagem sugerida ter a criação de pseudocódigo como parte do ciclo de vida do desenvolvimento? Por exemplo:

• Identifique e divida as tarefas de codificação
• Gravar pseudocódigo
• Obtenha a aprovação [por PL ou TL]
• Iniciar a codificação com base no pseudocódigo

Essa é uma abordagem sugerida? É praticado na indústria?

Escrever pseudocódigo antes da codificação é certamente melhor do que apenas codificar sem planejamento, mas está longe de ser uma prática recomendada. O desenvolvimento orientado a testes é uma melhoria.

Melhor ainda é analisar o domínio do problema e projetar soluções usando técnicas como histórias de usuário, casos de uso, cartões CRC, diagramação, adotadas por metodologias como Sala Limpa, RUP, Lean, Kanban, Agile, etc.

Compreender completamente a natureza do problema e os componentes que você usa para implementar a solução é o princípio por trás das melhores práticas.

Uso comentários como uma espécie de pseudo-código de nível muito alto, pois escrevo os comentários antes de escrever o código. Acho que pensar em todo o problema, mesmo em um nível alto, melhora consideravelmente meu código.

Não, não pseudo-codifique primeiro

Isso é demais. Você está fazendo o trabalho de escrever a lógica sem nenhum dos benefícios. Em vez disso, sugiro o seguinte:

1. Protótipo no idioma que você irá enviar (AKA Escreva um para jogar fora )
2. Diagramas de arquitetura com trechos de código para testar suposições / designs principais
3. Desenvolvimento Orientado a Testes, onde você escreve primeiro a sua interface / estrutura de código, seguida pelos testes e pela implementação do código.

Todos esses três direcionam você diretamente para sua solução, diferentemente do pseudo-código. Pessoalmente, costumo usar as técnicas 1 ou 2, dependendo do tamanho da equipe. Para equipes menores (por exemplo, 5 pessoas ou menos), a prototipagem funciona muito bem. Para equipes maiores que têm vários grupos de desenvolvedores trabalhando em paralelo, eu descobri que a documentação produzida anteriormente pela técnica 2 funciona bem porque fornece algo para discutir cedo e ajuda a definir melhor os limites dos componentes. Tenho certeza de que o TDD funcionaria muito bem também, mas ainda tenho que trabalhar em uma equipe comprometida com esse processo.

Na minha opinião, o pseudo-código tem apenas dois propósitos válidos:

(1) Para estudantes de programação que precisam aprender os conceitos de modularidade e algoritmos, mas ainda não são fluentes em uma linguagem de programação.

(2) Comunicar como algo funcionará a uma pessoa não técnica ou apenas por conveniência em uma reunião do quadro branco.

O pseudo-código é uma abordagem sugerida? Para programadores iniciantes, eu digo que sim. Ajuda o novo programador a aprender a traduzir um problema em código sem se preocupar com a sintaxe exata do idioma. Isso molda o processo de pensamento e pode ajudar a incorporar hábitos úteis (e suponho que maus hábitos também). É por isso que é usado tanto nas escolas.

É praticado na indústria? Na minha experiência, não. Ninguém tem tempo para detalhar o projeto entre a documentação (requisitos, especificações, storyboards, casos de uso ou qualquer outra coisa que eles usem) e o código real. Geralmente, supõe-se que já tenha sido pensado o suficiente sobre o problema antes da luz verde para codificar. Nesse ponto, a codificação do projeto é mais importante do que adicionar mais uma camada de preparação do design.

Eu recomendaria definitivamente o pseudocódigo. Isso ajuda a esclarecer o que você fará e a identificar itens que podem ter esquecido ou problemas em potencial. É muito mais fácil / rápido corrigir seu código quando ele ainda está nos estágios de planejamento, em vez de esperar até que você já tenha codificado uma grande parte dele.

O pseudocódigo pode ser útil se você não estiver familiarizado com o idioma ou se precisar alterar contextos mentais. Nas raras ocasiões em que escrevo pseudocódigo, está no papel. Às vezes, tirar as mãos do teclado e rabiscar no papel pode ajudar a contornar um bloqueio mental.

Mas como parte formalizada do processo de desenvolvimento? De jeito nenhum. É uma ferramenta esporadicamente útil para indivíduos. Existem maneiras melhores de "saber o que você está escrevendo antes de escrevê-lo", como:

1. definição do contrato (condições pré / pós / invariantes) do método antes de iniciar
2. TDD
3. 1 e 2 combinados (escrevendo testes para executar o contrato)

Eu também sugeriria que obter qualquer tipo de aprovação antes de começar a escrever o código provavelmente causará muito mais problemas do que vale a pena. Revisões de design (pré-implementação) podem ser úteis, mas precisam estar em um nível superior aos algoritmos individuais.

Discordo das respostas anteriores e digo não, mas com uma ressalva: você pode se livrar do código psuedocode apenas se se dedicar febrilmente a refatorar seu código para lidar com problemas que surgem. O Psuedocode é, em sua essência, uma maneira de definir seu código antes de definir seu código; é uma abstração desnecessária em muitas circunstâncias e, como seu código nunca será perfeito na primeira vez (e provavelmente não seguirá o design do psuedocode até a conclusão), isso me parece estranho.

Se você estiver escrevendo COBOL ou C, o pseudocódigo pode ser útil, pois a gravação do código real levará muito mais tempo e, se você puder verificar seus algoritmos / requisitos a partir do pseudocódigo, poderá economizar algum tempo.

Em linguagens mais modernas, o pseudocódigo não faz tanto sentido. O que funcionaria melhor é escrever stubs de métodos e preencher a lógica de nível superior e os detalhes necessários para verificar o algoritmo e os requisitos, tudo isso no código real. Em seguida, você pode mostrar esse código ao líder da equipe para aprovação e ter seu código real já iniciado.

As únicas vezes que usei pseudocódigo nos últimos 10 anos são em entrevistas quando estamos trabalhando em um quadro branco e o idioma específico não importa.

Certamente, é útil conversar sobre um processo / algoritmo em termos gerais, sem se preocupar com a sintaxe. Por exemplo, escrever uma classe C ++ que possua propriedades C #, apenas para ilustrar o ponto.

Ele tem o seu 'lugar', mas só deve ser usado onde for necessário (é um trabalho que você jogará fora) e certamente não faz parte de um processo formal, a menos que você tenha padrões do tipo ISO que insistam nele.

Para mim e para as pessoas com quem trabalhei nos últimos anos, o pseudocódigo praticamente se transformou em código real não totalmente perfeito. a menos que você trabalhe com vários idiomas ao mesmo tempo, a maioria das pessoas parece começar a pensar no padrão geral de seu idioma principal. Eu trabalho nas lojas .net há algum tempo, para que os rabiscos do quadro branco da maioria das pessoas ao redor do escritório pareçam vb ou c # com algumas pontuações ausentes.

O exercício ainda é valioso ao debater opções e afins, mas o pouco agnóstico do idioma tende a se afastar à medida que você passa mais tempo com alguns idiomas.

Cada vez mais, o pseudocódigo é escrito graficamente com ferramentas como UML. Por exemplo, experimente yUML .

uma ferramenta online para criar e publicar diagramas UML simples. É realmente fácil para você:

• Incorpore diagramas UML em blogs, e-mails e wikis.
• Poste diagramas UML em fóruns e comentários do blog.
• Use diretamente na sua ferramenta de rastreamento de bugs baseada na Web.
• Copie e cole diagramas UML em documentos do MS Word e apresentações do Powerpoint ...

... yUML economiza seu tempo. Ele foi projetado para aqueles que gostam de criar pequenos diagramas e esboços UML.

Sem o yUML, a criação de um diagrama UML pode envolver o carregamento de uma ferramenta UML, a criação de um diagrama, a atribuição de um nome, a mexer no layout, a exportação para o bitmap e o upload on-line em algum lugar. yUML não faz você fazer nada disso ...

Ótimo trabalho. Você iniciou uma boa discussão. Na minha época, eu costumava escrever pseudo-códigos quando aprendia programação para entender os vários loops e algoritmos. Isso foi há mais de uma década e meia atrás. Naqueles dias, mesmo as linguagens de programação não eram muito poderosas ... e a programação orientada a eventos era futura. Agora, com 4GLs e 5GLs, pensamos no próprio idioma, e não no inglês comum. Quando pensamos em um problema, pensamos em termos de objetos e operações. E até que seja algo complexo, escrever pseudo-códigos (ou códigos PSEU-DO-códigos, apenas brincando) não faz nenhum sentido. Melhor, represente a solução de maneira gráfica.

Depende do idioma usado e de sua familiaridade com ele.

Muitas linguagens modernas como Python ou Java já estão tão próximas do pseudocódigo que escrever primeiro um pseudocódigo ad hoc é um desperdício, IMHO. Melhor fazê-lo imediatamente, usando a abordagem de marcador de marcador .

É um negócio diferente se você está criando coisas de baixo nível, próximas ao metal, ou ainda não se sente confortável com o idioma que está usando. Então o pseudocódigo pode definitivamente ser útil.

Há algumas circunstâncias em que o pseudocódigo tende a ser quebrado no meu trabalho, que é na academia onde a programação tende a ser usada como uma ferramenta ou o preenchimento "e agora resolvemos" no meio de um projeto:

1. Quando o código for mais contraproducente para uma compreensão real do que vai acontecer do que o pseudo-código será. O SAS, por exemplo, ocupará metade do quadro branco, executando algumas tarefas de programação bastante básicas. Veja também C, que alguns outros pôsteres discutiram.
2. Com muita análise de dados e codificação estatística, costuma haver muitos ajustes no código à medida que os resultados são gerados. O pseudocódigo é um pouco mais fácil de usar, "aqui está um processo alternativo, se o gráfico de diagnóstico não parecer correto, tente o X".
3. Os alunos aprendem muitas linguagens de programação diferentes. Por exemplo, entre as pessoas que conheço, um problema estatístico pode ser analisado no SAS, R ou Stata. Algo que requer algo mais próximo da programação tradicional pode ser feito em R, Matlab, C, C ++, Java, Python ... realmente depende de qual aluno em particular está implementando o programa e com qual finalidade. Mas ainda é útil para o pessoal de Java, Python e Matlab ter uma idéia conjunta do que os outros estão fazendo e de como a abordagem , e não o próprio código, funciona.

Este não é um tipo de pergunta sim / não. Em vez disso, deve-se pensar quando usar pseudo-código. É importante entender o problema antes de projetar uma solução e é importante ter uma visão clara da solução antes de implementá-la. O pseudocódigo pode ser usado em qualquer uma destas etapas:

1. Ao definir o problema, é comum anotar casos de uso, às vezes usando sequências de ações.
2. Ao projetar uma solução. Os diagramas de classe são bons, mas apenas descrevem a parte "estática", ou seja, os dados. Para a parte dinâmica, assim que você precisar lidar com um loop e dados não triviais, considero o pseudo-código o melhor método disponível. As alternativas gráficas incluem máquinas de estado (boas para fluxos de controle complexos com poucos dados) e diagramas de fluxo de dados (boas para fluxos simples com dados complexos).
3. Ao implementar a solução (ou pouco antes). Algumas linguagens de programação são difíceis de ler (pense em assembly). Uma representação alternativa pode ser valiosa neste caso. Se você não conhece os idiomas, também vale a pena.

O pseudo-código, que na verdade é o código adequado em uma linguagem de alto nível, também é usado, geralmente chamado de prototipagem.

Além de obter entendimento, o pseudocódigo também é bom para a comunicação.

Se você está se perguntando se deve usar pseudocódigo regularmente, sou pessoalmente contra todos os tipos de regras rígidas. Isso pode facilmente se transformar em um desperdício de tempo chato, se usado para problemas triviais que todos da equipe entendem. O uso de pseudocódigo para especificações que você mantém ao longo da vida do projeto também pode ser caro e oferecer pouco valor.