¿Debería uno usar pseudocódigo antes de la codificación real?

Question

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

• Identificar y dividir las tareas de codificación
• Escribir seudocódigo
• Obtenga lo aprobado [por PL o TL
• Iniciar codificación basada en pseudocódigo

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

Answer 1

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

Aún mejor es analizar el dominio del problema y las soluciones de diseño utilizando técnicas como historias de usuarios, casos de uso, tarjetas CRC, diagramas, según lo adoptan metodologías como la sala de limpieza, 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.

Answer 2

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

Answer 3

No, no se pseudocódice primero

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

1. Prototipo en el idioma que vas a enviar (también conocido como Escribe uno para tirar)
2. Diagramas de arquitectura con fragmentos de código para probar suposiciones / diseños clave
3. Desarrollo impulsado por las pruebas donde escribe primero sus interfaces/estructura de código, seguido de pruebas, seguido de la implementación del código.

Los tres lo mueven directamente hacia su solución, a diferencia del Pseudo-Code. Personalmente, tiendo a usar las técnicas 1 o 2 dependiendo del 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 que trabajan en paralelo, descubrí que la documentación producida temprano por la Technique 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 había comprometido con este proceso.

Answer 4

En mi opinión, Pseudo-Code tiene solo dos propósitos válidos:

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

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

Answer 5

¿El pseudocódigo es un enfoque sugerido? Para programadores principiantes, digo que sí. Ayuda al nuevo programador a aprender a traducir un problema en código sin preocuparse por la sintaxis exacta del idioma. Esto da forma al proceso de pensamiento y puede ayudar a los 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 el tiempo para desacuerdo el proyecto entre la documentación (requisitos, especificaciones, paneles de cuentos, casos de uso o cualquier otra cosa que usen) y el código real. En general, se supone que ya se ha pensado suficiente en el problema antes de la luz verde al código. En ese momento, codificar el proyecto es más importante que agregar una capa más de preparación de diseño.

Answer 6

Definitivamente recomendaría el 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/más rápido corregir 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.

Answer 7

El pseudocó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 quitarse las manos del teclado y garabatear en papel puede ayudar a moverse por un bloque mental.

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

1. Definición del contrato (condiciones previas/post/invariantes) del método antes de comenzar
2. TDD
3. 1 y 2 combinados (escribiendo 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 (preimplementación) pueden ser útiles, pero deben estar en un nivel más alto que los algoritmos individuales.

Answer 8

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

Answer 9

Si está escribiendo COBOL o C, el pseudocódigo puede ser útil porque escribir el código real llevará mucho más tiempo, y si puede verificar su algoritmo/requisitos desde el pseudocódigo, puede ahorrar algo de tiempo.

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

Answer 10

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

Ciertamente es útil para hablar a través de un proceso/algoritmo en términos sueltos sin empantanarse con la sintaxis. Por ejemplo, escribir una clase C ++ que tiene 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 es parte de un proceso formal, a menos que tenga estándares de tipo ISO que lo insista.

Answer 11

Para mí y para las personas con las que he trabajado durante los últimos años, el pseudocódigo se ha convertido 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 de .NET por un tiempo, por lo que la pizarra de la mayoría de las personas los garabatos por la oficina tienden a parecerse a VB o C# con algo de la puntuación que falta.

El ejercicio sigue siendo valioso al debatir las opciones y demás, pero el bit de agnóstico del idioma tiende a alejarse a medida que pasa más tiempo con algunos idiomas.

Answer 12

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 simples de UML. Le hace realmente fácil:

• Incorporar diagramas UML en blogs, correos electrónicos y wikis.
• Publicar 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, jugar al diseño, exportarlo a mapa de bits y luego subirlo en línea en algún lugar. Yuml no te hace hacer nada de eso ...

Answer 13

Buen trabajo. Comenzaste una buena discusión. A partir de mí, solía escribir códigos de pseudo cuando estaba aprendiendo programación para comprender los diversos bucles y algoritmos. Esto fue más de una y media décadas. Ese día, incluso los lenguajes de programación no eran muy poderosos ... y la programación impulsada por eventos era futuro. Ahora con 4GL y 5GL, pensamos en el idioma en sí mismo en lugar de en inglés. Cuando pensamos en un problema, pensamos en términos de objetos y operaciones. Y hasta que sea un algo complejo, escribir códigos de pseudo (o codos PSEU-do, broma) no tiene ningún sentido. Mejor, represente la solución de manera gráfica.

Answer 14

Depende del lenguaje utilizado y su familiaridad con él.

Muchos idiomas 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 solo hazlo de inmediato usando el bala trazadora Acercarse.

Es una oferta diferente si está haciendo algunas cosas de bajo nivel, cerca de metal, o aún no se siente cómodo con el idioma que está usando. Entonces el pseudocódigo definitivamente puede ser útil.

Answer 15

Tiende a haber un par de circunstancias en las que el pseudocódigo tiende a romperse en mi trabajo, que se encuentra en la academia donde la programación tiende a utilizar como herramienta o el "y ahora lo resolvemos" llenando la mitad de un proyecto:

1. Cuando el código sea más contraproducente para una comprensión real de lo que sucederá, 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 otros carteles han discutido.
2. Con una gran cantidad de análisis de datos y codificación de estadísticas, tiende a haber muchos retoques con el código a medida que se generan resultados. El pseudocódigo es algo más fácil de usar para "En este documento se encuentra un proceso de ida y vuelta, si el diagnóstico no se ve bien, intente X".
3. Los estudiantes aprenden muchos lenguajes de programación diferentes. Por ejemplo, entre las personas que conozco, se puede analizar un problema de estadística en SAS, R o Stata. Algo que requiere algo más cercano a la programación tradicional podría hacerse en R, Matlab, C, C ++, Java, Python ... realmente depende de qué estudiante en particular esté implementando el programa y para qué propósito. Pero todavía es útil para el pueblo de Java y el pueblo de Python y el pueblo de Matlab para tener una idea conjunta de lo que los demás están haciendo y cómo el Acercarse, en lugar del código en sí, funciona.

Answer 16

Esta no es un tipo de pregunta sí/no. Más bien, uno debería preguntarse cuando para usar pseudo-có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 implementarlo. El código de pseudo se puede usar en cualquiera de estos pasos:

1. Al definir el problema, es común escribir casos de uso, a veces utilizando secuencias de acciones.
2. Al diseñar una solución. Los diagramas de clase 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, encuentro que el pseudo-código es el mejor método disponible. Las alternativas gráficas incluyen máquinas de estado (buenas para el flujo de control complejo con pequeños datos) y diagramas de flujo de datos (bueno 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 (piense, ensamblaje). Una representación alternativa puede ser valiosa en este caso. Si no está familiarizado con los idiomas, también vale la pena hacerlo.

El pseudo-código que en realidad es un código adecuado en un lenguaje de alto nivel también se usa, generalmente se llama prototipos.

Además de lograr la comprensión, el pseudocódigo también es bueno para la comunicación.

Si se pregunta si debe usar pseudocódigo regularmente, estoy personalmente en contra de todo tipo de reglas rígidas. Esto puede convertirse fácilmente en una pérdida de tiempo aburrida 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.