Cuando comencé a programar, me basé en gran medida en los diagramas de flujo (y en los gráficos de espaciado de impresoras). Mientras estaba en la clase COBOL, no pude comenzar a escribir ningún código hasta que el instructor aprobó mi diagrama de flujo. En aquel entonces, tenía que hacer un diagrama de flujo para todo.

Hoy, veinticinco años después, me encuentro solo diagramas de flujo de dos tipos de cosas. Algoritmos muy específicos donde la lógica es complicada o conceptos muy generales para garantizar que obtenga todos los grandes pasos definidos y en el orden correcto.

¿Hay otros casos de uso para diagramas de flujo que simplemente he pasado por alto?

Absolutamente.

Cada vez que implemente algo que no he hecho antes (y el algoritmo toma más de unos pocos pasos), lo trazaré. Me parece que realmente me obliga a analizar toda la solución a un nivel más atómico y más exhaustivo que si no se trazara. Encuentro que hay tres beneficios principales para esta práctica:

• Menos "oh craps" porque he pensado en todo el algoritmo
• Elimina cualquier posible golpe en los problemas que pueden ocurrir en el resto del sistema
• Me permite guiar fácilmente a alguien más a través del algoritmo

Las dos ocasiones diferentes donde realmente uso estas son:

• Algoritmos de nivel bajo (ish). Me refiero a una solución muy específica para un problema muy específico. Generalmente pasaré esto por pares antes de la implementación.
• Flujo de usuario. No solo puedo usar esto para pasar por un compañero, sino que también lo usaré para explicar (de una manera muy no técnica) el flujo a un experto en usabilidad.

Habiendo dicho todo eso, no produzco diagramas de flujo a diario (e incluso cuando se realizan, generalmente es una sesión de pizarra a menos que esté escribiendo un documento de diseño técnico).

Nunca

Los diagramas de flujo, especialmente los practicados hace más de 25 años, han sido reemplazados por técnicas de diagramación mucho más expresivas (ver Diagramas de acción, Gráficos de secuencia, Gráficos de estado, etc.).

Los propios estudios de IBM mostraron que el uso de diagramas de flujo no tuvo efecto en la calidad del diseño o implementación de un sistema (aunque fueron marginalmente útiles para comunicarse con los usuarios y otros desarrolladores) [referencia precisa no disponible fácilmente, pero fue citada en Técnicas de diagramación de James Martin para analistas y programadores ].

No he dibujado un diagrama de flujo clásico desde mi primera clase de programación en 1976, y no he visto a nadie más crear uno desde principios de los 80. Los diagramas de flujo fueron útiles para comunicar la lógica del programa cuando el código estaba en lenguaje ensamblador. A fines de la década de 1960, los programadores de lenguaje ensamblador usaban pseudocódigo. Al programar en lenguajes OO modernos, ni los diagramas de flujo ni el pseudocódigo tienen ningún valor. También puede escribir código de alto nivel en el lenguaje de implementación.

De vez en cuando dibujo diagramas UML, principalmente en papel, para expresar ideas de diseño, pero esos diagramas solo viven hasta el final de la discusión. También dibujo diagramas de transición de estado de vez en cuando, luego los convierto en una tabla de estado en el lenguaje de implementación.

Uso diagramas de flujo todo el tiempo por varias razones:

1. Son mejores que los diagramas de casos de uso de UML en mi opinión. Pueden reflejar varios casos de uso diferentes y cómo interactúan, y en general hacen un mejor trabajo al unir la experiencia del usuario y las decisiones.

2. Son más fáciles de entender y más intuitivos. Tu mente, naturalmente, sigue las flechas como un laberinto de principio a fin. Puede usar diagramas de flujo para finalizar y hacer referencia a otro diagrama de flujo para una historia de usuario diferente. Por lo general, puedo imprimirlos en un libro numerado de páginas y rápidamente voltear páginas para navegar al siguiente diagrama de flujo.

3. Son universales. Pocas personas ajenas a la ingeniería de software conocen y entienden los diagramas UML, donde los diagramas de flujo son mucho más reconocibles por los usuarios y analistas de negocios. Intento comunicar casos de uso complejos a un cliente y, a veces, luchan por comprenderlo, les dibujo un diagrama de flujo y entienden por qué finalmente comprenden todos los matices que lo hacen MUCHO MÁS complejo de lo que pensaban.

Los diagramas de flujo son útiles cuando las cosas deben hacerse en un orden específico. Donde realmente brillan en mi mente es mostrar dónde se toman las decisiones y asegurarse de que cada posible decisión tenga un camino. Esto evita la creación de programas en los que se requiere la aprobación de un mamager, pero no hay forma de tratarlo si el gerente (que aprueba el 98% del tiempo) dice que no. Nos recuerdan que el camino más común no es el único. Los encuentro útiles al hablar con los usuarios acerca de los requisitos porque a menudo solo le dirán la ruta más común.

Los diagramas de flujo pueden ser útiles para ingeniería inversa de código muy mal estructurado. Particularmente si tiene gotos. Afortunadamente, no he visto mucho código pasado por goto recientemente.

Como otros destacaron por comunicarse con los usuarios finales. Ordeno el inicio de un transmisor de TV documentado por diagrama de flujo. Las personas de hardware y software tenían una especificación común para trabajar.

El Diagrama de actividad y el Diagrama de flujo de UML son útiles para mostrar la complejidad baja a media de un proceso o algoritmo.

Son muy buenos cuando se comunican con los usuarios comerciales sobre las reglas comerciales.

Existe una variación en la forma de BPMN 2.0 que es muy útil en el modelado de procesos empresariales.

Algunas herramientas BPMN pueden generar aplicaciones web en ejecución a partir de gráficos.

Entonces, sí, los diagramas de flujo todavía tienen un lugar, pero deben usarse con prudencia.

No soy programador Soy un técnico en ingeniería de hardware.

Para mí tiene sentido comenzar al menos con comentarios que expliquen los bloques lógicos que se utilizarán. Después de eso, desarrolla el esqueleto del programa con el código real. Es similar a comenzar un guión de película con un guión gráfico y luego completar los detalles de acción y el diálogo posterior.

¿No debería planearse cuidadosamente cualquier esfuerzo que valga la pena? En el ámbito del hardware, comenzamos con un documento de requisitos del cliente, luego escribimos un documento de especificación de hardware, luego desarrollamos el esquema, luego dibujamos un diseño de placa y luego presentamos la documentación del ensamblaje. No solo comenzamos a tomar piezas y soldarlas juntas a medida que se nos ocurren ideas para hacer el producto final.

No veo cuán eficiente se puede escribir el código en un programa de 15 KB o 15 MB sin mucho trabajo de preparación antes de comenzar la codificación real.