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:
- Ao definir o problema, é comum anotar casos de uso, às vezes usando sequências de ações.
- 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).
- 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.