Esta no es una pregunta de sí / no. Más bien, uno debería preguntarse cuándo usar el pseudocódigo. Es importante comprender el problema antes de diseñar una solución, y es importante tener una visión clara de la solución antes de implementarla. El pseudocódigo se puede usar en cualquiera de estos pasos:
- Al definir el problema, es común anotar casos de uso, a veces usando secuencias de acciones.
- Al diseñar una solución. Los diagramas de clases son agradables, pero solo describen la parte "estática", es decir, los datos. Para la parte dinámica, tan pronto como necesite lidiar con un bucle y datos no triviales, creo que el pseudocódigo es el mejor método disponible. Las alternativas gráficas incluyen máquinas de estado (buenas para flujo de control complejo con pocos datos) y diagramas de flujo de datos (buenas para flujos simples con datos complejos).
- Al implementar la solución (o justo antes). Algunos lenguajes de programación son difíciles de leer (pensar, ensamblar). Una representación alternativa puede ser valiosa en este caso. Si no está familiarizado con los idiomas, también vale la pena hacerlo.
También se usa el pseudocódigo que en realidad es el código apropiado en un lenguaje de alto nivel, generalmente se llama creación de prototipos.
Además de lograr la comprensión, el pseudocódigo también es bueno para la comunicación.
Si se pregunta si debería usar pseudocódigo de manera regular, estoy personalmente en contra de todo tipo de reglas rígidas. Esto puede convertirse fácilmente en una aburrida pérdida de tiempo si se usa para problemas triviales que todos en el equipo entienden. El uso de pseudocódigo para las especificaciones que mantiene a lo largo de la vida del proyecto también puede ser costoso y ofrecer poco valor.