¿Son buenos los diagramas de flujo?

En general, la gente rara vez dibuja diagramas de flujo tradicionales.

Lo que pasa con los diagramas de flujo que las generaciones más jóvenes no entienden es que fueron una ayuda para resolver un problema que ya no existe porque fue automatizado. Los diagramas de flujo fueron una ayuda visual para pensar en la “programación estructurada” antes de que los conceptos de programación estructurada se integraran a los lenguajes de programación como ciudadanos de primera clase.

La gente solía escribir código en lenguaje ensamblador. En lenguaje ensamblador hay diferentes tipos de saltos y declaraciones de ramificación que uno usa para especificar el flujo de control en un programa. Estas declaraciones usan diferentes modos de direccionamiento para sus objetivos y pueden o no estar condicionadas a diferentes tipos de condiciones. Los programas en lenguaje ensamblador usan estas ramas y saltos como lo deseen: puede saltar por todos lados si lo desea.

Los primeros lenguajes de nivel superior conservaron este mecanismo básico en forma de declaración goto. BASIC agregó la noción de for-loop y creo que al principio Fortran tenía una construcción similar a for-loop, pero sobre todo en BASIC y Fortran construiste la lógica en programas a través de muchos gotos. Esto puede ser confuso. Una forma de mantener su lógica recta es dibujar un diagrama de dónde van todos estos saltos y qué están haciendo las condiciones. Tal diagrama es un diagrama de flujo.

Sin embargo, una mejor manera de mantener todo en orden es no saltar de un lado a otro de su programa, practicar un uso estructurado de la rama y las condiciones, por ejemplo, usar solo gotos en un pequeño conjunto de formas bien definidas: hacer un ciclo mientras una condición es verdadera; para activar diferentes casos de algún valor, etc. Esta fue una programación estructurada, que al principio tuvo que practicarse sin soporte de lenguaje, algo así como cómo es posible hacer una programación orientada a objetos en C colocando punteros de función en estructuras, etc. a pesar de que C no implementa específicamente OOP.

Finalmente, lenguajes como C y Pascal incluyeron estas estructuras de control de forma nativa y los viejos malos hábitos desaparecieron en una generación. Ahora ya nadie habla de programación estructurada precisamente porque la programación estructurada tuvo un éxito total y absoluto. Ganó … de una manera que incluso OOP no lo hizo.

Hay pocas razones para usar diagramas de flujo.
1. En este momento, los programas son pequeños, por lo que puede pensarlos y escribirlos sobre la marcha. Pronto los programas se harán grandes, realmente grandes. Lo suficientemente grande como para que ni siquiera puedas mantener todo el programa en tu cabeza. Comenzarás a escribirlo sobre la marcha y te perderás algo crítico. Más tarde te darás cuenta de que algo ha vuelto inútil tu algoritmo, y ahora tienes que volver a escribirlo todo. (¡Sucede con más frecuencia de lo que piensas!)
2. Pronto verá que hay muchos idiomas y cada uno tiene sus propias preferencias. Si piensa en términos de sintaxis, no podrá compartir y discutir ideas con otros.
3. A veces trabajarás con / para personas que no son de un entorno de codificación. Revisar los diagramas de flujo facilitará las cosas tanto para usted como para ellos. (Además, es posible que no desee revisar su código de propiedad con otros).
4. A medida que los programas se hacen más grandes, los diagramas de flujo serán más significativos y escribirás bloques más sensibles como “ordenar la lista” o “buscar un paquete de la red”.

Dicho todo esto, incluso yo no escribo diagramas de flujo todo el tiempo. Algunas cosas son demasiado pequeñas y claras para necesitar un diagrama de flujo. Pero siempre es una buena práctica para grandes proyectos.

Trabajo para Creately, un inicio de diagramación basado en web. De los millones de diagramas dibujados con nuestra herramienta, un gran porcentaje son diagramas de flujo, seguidos de cerca por los tipos de diagramas UML.

Sin embargo, los diagramas de flujo son dibujados principalmente por usuarios no técnicos. Los diagramas de flujo se utilizan en varios nichos para visualizar procesos. Son fáciles de dibujar y se entienden universalmente (si se adhiere a los símbolos estándar).

En su caso específico, no creo que sea una buena idea comenzar a codificar inmediatamente sin pensar primero en la solución. Cuando un problema es pequeño, no será un problema. Pero cuando un problema se vuelve complejo, ayudará.

Además, cuando trabaje con equipos grandes, se encontrará con personas que no tienen los conocimientos de programación para comprender sus programas. Entonces, si puede mostrar su solución a través de diagramas de flujo, esas personas lo apreciarán mucho.

Realizo diagramas de flujo a diario para empresas de todos los espectros. Los diagramas de flujo trascienden la programación. Piense en el análisis de negocios: algunas personas quieren mapear visualmente sus procesos de negocios para identificar puntos de mejora, encontrar brechas / cuellos de botella en el proceso, poner al personal en la misma página o comunicar a los clientes lo que pueden esperar al participar en sus servicios. Todavía es relevante en TI para ingenieros y analistas, también. Recomiendo y uso Lucidchart.