¿Por qué usar un diagrama de flujo es una mala práctica en la programación?

Los diagramas de flujo no son malos. Proporcionan una abstracción de los programas basados ​​en procedimientos.

La razón por la que los diagramas de flujo son menos populares últimamente es diferente: no son lo suficientemente buenos para los programas orientados a objetos abstractos. Los diagramas UML y de relación de entidad reemplazaron los diagramas de flujo. Sin embargo, las funciones en OOP todavía se pueden representar mediante diagramas de flujo.

Otra razón por la cual los diagramas de flujo se volvieron menos populares es que se han vuelto más populares las formas de presentar algoritmos. Las descripciones textuales estructuradas de algoritmos ahora son tan buenas como los diagramas de flujo para representar procedimientos, ahorrando espacio y la molestia de dibujar. Además, muchos libros y artículos solo dan fragmentos de código en un lenguaje popular en lugar de dar diagramas de flujo.

Los diagramas de flujo todavía se usan para representar procesos, secuencias de trabajo, árboles de decisión, etc. Los libros de programación dejaron de usarlos porque ya no están de moda.

Por el contrario, el diagrama de flujo es una buena práctica.
Los sistemas de diagrama de flujo se pueden usar de manera efectiva para documentar:
1. requisitos funcionales o análisis de casos de uso.
2. cómo se implementarán estos requisitos funcionales.
3. control de flujo y flujo de datos en varios niveles de descomposición que pueden usarse de manera efectiva para tener un diseño funcional o de respuesta rápida (OO) robusto y sensible.
Los flujos de proceso tienen un par de ejemplos.

En horas extras, encontrará que es tedioso dibujar un diagrama de flujo de un problema incluso un poco complejo. Utilizamos otras técnicas de modelado como UML que son más avanzadas y ofrecen opciones para describir el problema y la solución en múltiples niveles de abstracciones y no todas deben especificarse. El objetivo es comprender el problema e idear la solución y asegurarse La solución funciona. No existe una regla estricta y rápida para hacerlo. Cualquier cosa que ayude a utilizar diagramas, ejemplos reales de trabajo y / o prototipos de partes de la solución para lograr este objetivo.

Para una pieza de código estrictamente procesal, no es necesariamente una mala práctica, pero puede conducir a un código bastante horrible si no está pensando claramente mientras construye el diagrama de flujo. Sin embargo, en defensa, casi cualquier tipo de herramienta de planificación puede ser mal utilizada y darte un mal resultado. El viejo síndrome de basura en la basura. Los diagramas de flujo también pueden ser muy difíciles de modificar, especialmente cuando necesita cambiar el flujo de su programa.

Me alejé de los diagramas de flujo hace muchos años cuando me presentaron los diagramas de Warnier / Orr. Descubrí que son una forma mucho más agradable de construir lógica que nunca requirió una declaración ‘goto’.

Un desorden enredado de un diseño suele ser un indicador de que tienes un problema muy complejo, o no lo entiendes muy bien, o estás usando la herramienta incorrecta para el diseño. El uso de diagramas de flujo para diseños muy complejos puede ser problemático, ya que un error podría no solo llamarte la atención.

Al final, una mente clara es su mejor defensa.

Otra pregunta estándar de “tipo Quora”. El autor de la pregunta hace una suposición ridícula mientras hace una pregunta. Algo de la siguiente forma: “¿Por qué C ++ es el peor lenguaje de la historia?”, “¿Por qué Python es un lenguaje moribundo?”, “¿Por qué a nadie le gustan las laptops Dell?”, “¿Por qué todos odian las cadenas de estilo C?” es mala practica?

Proporcionaré una fuente para su reclamo, tal vez esto es lo que leyó. El autor aquí http://wiki.c2.com/?TipsForReadi … dice que los diagramas de flujo son horribles para el diseño de código. Los uso regularmente para organizar mi pensamiento sobre el flujo de control de un programa. Mucha gente aquí dice que los encuentran útiles.

Crear un diagrama de flujo casi nunca es una “mala práctica” en la programación. Puede que no sea crítico para el éxito de un proyecto, pero casi siempre será de ayuda, aunque solo sea para ayudarlo a organizar sus pensamientos, pero no puedo pensar en ninguna instancia en la que pueda contribuir al fracaso de un proyecto. o ser alguna vez una “mala práctica”. Si nada más tomándose el tiempo para crear un diagrama de flujo lo obligará a reducir la velocidad y evitará que se apresure e implemente un diseño que realmente no ha pensado muy bien.

Se trata de usar / hacer lo que sea que lo ayude a desarrollarse mejor, más rápido, más fácil, etc. Si usar un diagrama de flujo lo ayuda, entonces úselo. Los problemas surgen principalmente cuando el uso de algo se vuelve obligatorio / institucionalizado (y se ve obligado a usarlo si tiene sentido o no), o cuando alguien se interpone en el camino del descubrimiento / uso de otros enfoques.

No creo que los diagramas de flujo sean una mala práctica. En primer lugar, creo que ayuda a aprender a programar. Se requiere uno para estructurar sus pensamientos y aprender cómo tomar un gran problema y dividirlo en un grupo de problemas más pequeños.

En la práctica, muchos problemas son pequeños problemas que pueden resolverse fácilmente sin diagramas de flujo. A medida que el programador gane habilidad, utilizará el pseudocódigo como un diagrama de flujo en lugar de un simbolismo formal, a menos que así lo requiera la especificación del proyecto. Para problemas complejos o grandes, este pseudocódigo casi siempre es necesario para planificar el trabajo involucrado. Si bien no es un diagrama de flujo formal, debe considerarse lo mismo que los diagramas de flujo y es una buena práctica.

Porque estas reglas son creadas por la educación. No tienen idea.

Diagrama de flujo cuando estoy atrapado en un problema

Los diagramas de flujo son excelentes para comprender nuevos sistemas complejos.

Los diagramas de flujo no deberían incluir todas las situaciones posibles. Solo los puntos principales y manténgalo en 2 o 3 páginas como máximo.

[1] Función de ajuste de línea / hilight página 1

[2] página 2 de 2

Los diagramas de flujo son excelentes para el código de espagueti … mmm mmm

Notas al pie

[1] Imagen en telusplanet.net

[2] http://www.telusplanet.net/publi …

Puedo pensar en dos casos:

1. El diagrama de flujo no es demasiado grande: puede expresar el control de su programa en ~ una página. Bueno, si ese es el caso, ¿por qué no codificarlo directamente? Su programa no es demasiado complicado y un diagrama de flujo puede representar exactamente su funcionamiento, excepto que no funciona. En cambio, escriba un código ordenado que también funcione.
2. El diagrama de flujo es grande: su programa es bastante complejo. Intenta dividirlo, intenta encontrar abstracciones, intenta reducirlo a un problema más pequeño / simple. Ahora las piezas caen en el caso 1.

Una mejor manera de pensar en términos de un diagrama de flujo es ‘pensar en código’. El diagrama de flujo no es particularmente útil en la mayoría de los casos, a menos que esté colaborando con una persona que no puede leer el código.
Por otro lado, hacer casos casi siempre ayuda.

Mi $ 0.02 ..

Si un diagrama de flujo sería útil para el tema particular en cuestión, haga un diagrama de flujo.

Si un diagrama de flujo no encajara realmente, podría ser contraproducente.

Pensar que un método de solución se adapta a cada problema o es inútil en todos los casos es una mala práctica de programación. Mire lo que necesita hacer específicamente y descubra la mejor manera de hacerlo.