¿Se debe usar el pseudocódigo antes de la codificación real?

El pseudocódigo nos ayuda a comprender las tareas de una manera independiente del lenguaje. ¿Es la mejor práctica o el enfoque sugerido tener la creación de pseudocódigo como parte del ciclo de vida del desarrollo? Por ejemplo:

• Identificar y dividir las tareas de codificación.
• Escribir pseudocódigo
• Obtenga aprobación [por PL o TL]
• Iniciar codificación basada en pseudocódigo

¿Es este un enfoque sugerido? ¿Se practica en la industria?

Escribir pseudocódigo antes de la codificación es ciertamente mejor que solo codificar sin planificar, pero está lejos de ser una buena práctica. El desarrollo basado en pruebas es una mejora.

Aún mejor es analizar el dominio del problema y diseñar soluciones utilizando técnicas como historias de usuarios, casos de uso, tarjetas CRC, diagramación, tal como lo propugnan metodologías como Cleanroom, RUP, Lean, Kanban, Agile, etc.

Comprender a fondo la naturaleza del problema y los componentes que utiliza para implementar la solución es el principio detrás de las mejores prácticas.

Utilizo los comentarios como una especie de pseudocódigo de muy alto nivel, ya que escribo los comentarios antes de escribir el código. Me parece que pensar en todo el problema, incluso a un alto nivel, mejora considerablemente mi código.

No, no pseudocódigo primero

Esto es demasiado sobrecarga. Estás haciendo el trabajo de escribir la lógica sin ninguno de los beneficios. Sugeriría cualquiera de los siguientes en su lugar:

1. Prototipo en el idioma con el que va a enviar (AKA Escriba uno para tirar )
2. Diagramas de arquitectura con fragmentos de código para probar suposiciones / diseños clave
3. Test Driven Development donde primero escribes tus interfaces / estructura de código, seguido de pruebas, seguido de la implementación del código.

Los tres te llevan directamente a tu solución, a diferencia del pseudocódigo. Personalmente, tiendo a usar las técnicas 1 o 2 según el tamaño del equipo. Para equipos más pequeños (por ejemplo, 5 personas o menos), la creación de prototipos funciona muy bien. Para los equipos más grandes que tienen múltiples grupos de desarrolladores trabajando en paralelo, descubrí que la documentación producida temprano por la técnica 2 funciona bien porque le brinda algo para discutir temprano y lo ayuda a definir mejor los límites de los componentes. Estoy seguro de que TDD también funcionaría muy bien, pero todavía tengo que trabajar en un equipo que se haya comprometido con este proceso.

En mi opinión, el pseudocódigo tiene solo dos propósitos válidos:

(1) Para estudiantes de programación que necesitan aprender los conceptos de modularidad y algoritmos, pero que aún no dominan un lenguaje de programación.

(2) Comunicar cómo funcionará algo a una persona no técnica, o simplemente por conveniencia en una reunión tipo pizarra.

¿Es el seudocódigo un enfoque sugerido? Para los programadores principiantes, digo que sí. Ayuda al nuevo programador a aprender cómo traducir un problema en código sin preocuparse por la sintaxis exacta del lenguaje. Esto da forma al proceso de pensamiento y puede ayudar a arraigar hábitos útiles (y supongo que los malos hábitos también). Por eso se usa tanto en las escuelas.

¿Se practica en la industria? En mi experiencia, no. Nadie tiene tiempo para desbastar el proyecto entre la documentación (requisitos, especificaciones, guiones gráficos, casos de uso o cualquier otra cosa que usen) y el código real. En general, se supone que ya se ha pensado lo suficiente en el problema antes de la luz verde para codificar. En ese punto, codificar el proyecto es más importante que agregar una capa más de preparación de diseño.

Definitivamente recomendaría pseudocódigo. Le ayuda a aclarar lo que va a hacer e identificar elementos que puede haber olvidado o posibles problemas. Es mucho más fácil / rápido arreglar su código cuando todavía está en las etapas de planificación en lugar de esperar hasta que ya haya codificado una gran parte de él.

El seudocódigo puede ser útil si no está familiarizado con el idioma o si necesita cambiar los contextos mentales. En la rara ocasión en que escribo pseudocódigo, está en papel. A veces, simplemente quitar las manos del teclado y garabatear en papel puede ayudar a sortear un bloqueo mental.

¿Pero como parte formalizada del proceso de desarrollo? De ninguna manera. Es una herramienta esporádicamente útil para las personas. Hay mejores formas de "saber lo que está escribiendo antes de escribirlo", como:

1. definir el contrato (condiciones previas / posteriores / invariantes) del método antes de comenzar
2. TDD
3. 1 y 2 combinados (redacción de pruebas para ejecutar el contrato)

También sugeriría que obtener cualquier tipo de aprobación antes de comenzar a escribir código es probable que cause mucho más problemas de lo que vale. Las revisiones de diseño (pre-implementación) pueden ser útiles, pero deben estar en un nivel más alto que los algoritmos individuales.

No estaré de acuerdo con las respuestas anteriores y diré que no, pero con una advertencia: puede deshacerse del psuedocode solo si está fervientemente dedicado a refactorizar su código para tratar los problemas que surgen. Psuedocode es, en esencia, una forma de definir su código antes de definirlo; es una abstracción innecesaria en muchas circunstancias, y dado que su código nunca será perfecto la primera vez (y probablemente, no siga el diseño del psuedocode hasta su finalización), me parece extraño.

Si está escribiendo COBOL o C, el pseudocódigo puede ser útil porque escribir el código real tomará mucho más tiempo, y si puede verificar sus algoritmos / requisitos a partir del pseudocódigo, puede ahorrar algo de tiempo.

En lenguajes más modernos, el pseudocódigo no tiene tanto sentido. Lo que funcionaría mejor es escribir stubs de métodos y completar la lógica de nivel superior, y tantos detalles como sea necesario para verificar el algoritmo y los requisitos, todo esto en código real. Luego puede mostrar ese código al Jefe de equipo para su aprobación, y tener su código real ya iniciado.

Las únicas veces que he usado pseudocódigo en los últimos 10 años son entrevistas cuando estamos trabajando en una pizarra y el idioma en particular no importa.

Sin duda, es útil para hablar a través de un proceso / algoritmo en términos sueltos sin atascarse con la sintaxis. Por ejemplo, escribir una clase de C ++ que tenga propiedades de C #, solo para ilustrar el punto.

Tiene su lugar, pero solo debe usarse donde sea necesario (es un trabajo que tirará) y ciertamente no forma parte de un proceso formal, a menos que tenga estándares de tipo ISO que insistan en ello.

Para mí y para las personas con las que he trabajado durante los últimos años, el pseudocódigo se ha convertido prácticamente en un código real no del todo perfecto. a menos que trabaje con muchos idiomas al mismo tiempo, la mayoría de las personas parecen comenzar a pensar en el patrón general de su idioma principal. He trabajado en tiendas .net durante un tiempo, por lo que los garabatos de pizarra de la mayoría de las personas en la oficina tienden a parecerse a vb o c # y faltan algunos de los signos de puntuación.

El ejercicio sigue siendo valioso cuando se debaten opciones y cosas por el estilo, pero el bit agnóstico del idioma tiende a desaparecer a medida que pasa más tiempo con algunos idiomas.

Cada vez más, el pseudocódigo se escribe gráficamente con herramientas como UML. Por ejemplo, prueba yUML .

Una herramienta en línea para crear y publicar diagramas UML simples. Esto hace que sea realmente fácil para usted:

• Incruste diagramas UML en blogs, correos electrónicos y wikis.
• Publique diagramas UML en foros y comentarios de blogs.
• Use directamente dentro de su herramienta de seguimiento de errores basada en la web.
• Copie y pegue diagramas UML en documentos de MS Word y presentaciones de Powerpoint ...

... yUML te ahorra tiempo. Está diseñado para aquellos que les gusta crear pequeños diagramas y bocetos UML.

Sin yUML, crear un diagrama UML podría implicar cargar una herramienta UML, crear un diagrama, darle un nombre, manipular el diseño, exportarlo a un mapa de bits y luego cargarlo en línea en algún lugar. yUML no te obliga a hacer nada de eso ...

Buen trabajo. Comenzaste una buena discusión. Como yo, solía escribir pseudocódigos cuando estaba aprendiendo programación para comprender los diversos bucles y algoritmos. Esto fue hace más de una década y media. En aquellos días, incluso los lenguajes de programación no eran muy potentes ... y la programación dirigida por eventos era futura. Ahora con 4GLs y 5GLs, pensamos en el lenguaje en sí en lugar de en inglés simple. Cuando pensamos en un problema, pensamos en términos de objetos y operaciones. Y hasta que sea algo complejo, escribir pseudocódigos (o códigos PSEU-DO, es broma) no tiene ningún sentido. Mejor, represente la solución de forma gráfica.

Depende del idioma utilizado y su familiaridad con él.

Muchos lenguajes modernos como Python o Java ya están tan cerca del pseudocódigo que escribir un pseudocódigo ad hoc primero es un desperdicio, en mi humilde opinión. Mejor hazlo de inmediato usando el enfoque de trazador de bala .

Es un trato diferente si estás haciendo cosas de bajo nivel, cercanas al metal, o aún no te sientes cómodo con el lenguaje que estás usando. Entonces el pseudocódigo definitivamente puede ser útil.

Suele haber un par de circunstancias en las que el pseudocódigo tiende a romperse en mi trabajo, que es en la academia donde la programación tiende a usarse como una herramienta o el "y ahora lo resolvemos" en el medio de un proyecto:

1. Cuando el código será más contraproducente para una comprensión real de lo que va a suceder que lo será el pseudocódigo. SAS, por ejemplo, ocupará la mitad de la pizarra haciendo algunas tareas de programación bastante básicas. Ver también C, que algunos otros carteles han discutido.
2. Con una gran cantidad de análisis de datos y codificación de estadísticas, tiende a haber muchos ajustes en el código a medida que se generan los resultados. El pseudocódigo es algo más fácil de usar porque "aquí se encuentra un proceso de ida y vuelta, si el diagrama de diagnóstico no se ve bien, intente con X".
3. Los estudiantes aprenden muchos lenguajes de programación diferentes. Por ejemplo, entre las personas que conozco, un problema de estadísticas podría analizarse en SAS, R o Stata. Algo que requiere algo más cercano a la programación tradicional se puede hacer en R, Matlab, C, C ++, Java, Python ... realmente depende de qué estudiante en particular esté implementando el programa y con qué propósito. Pero sigue siendo útil para la gente de Java y la gente de Python y la gente de Matlab tener una idea conjunta de lo que están haciendo los demás y cómo funciona el enfoque , en lugar del código en sí.

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:

1. Al definir el problema, es común anotar casos de uso, a veces usando secuencias de acciones.
2. 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).
3. 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.