¿Por qué mi profesor de clase de computación nos hace aprender diagramas de flujo cuando tantos programadores no los usan en su trabajo?

Usted pregunta: ¿Por qué mi profesor de clase de computación nos hace aprender diagramas de flujo cuando tantos programadores no los usan en su trabajo?

Los diagramas de flujo son herramientas utilizadas para representar el flujo de control de un programa (o una sola función / subrutina) utilizando símbolos gráficos simples cuyo significado es muy fácil de memorizar y comprender (inicio, paso, condición, flechas etiquetadas, fin).

Se usan porque son bastante efectivos para representar visualmente algoritmos simples y requieren muy poco conocimiento previo (comparado con, digamos, pseudocódigo o algún lenguaje de programación real). Aprender directamente un lenguaje de programación del mundo real sería demasiado molesto en esta fase (pero no lo será más tarde), y el pseudocódigo aún requiere entender los condicionales y los bucles primero.

Una vez que un estudiante “obtiene” los conceptos básicos del flujo de control, los diagramas de flujo ya no son necesarios (ya que se vuelven engorrosos incluso para algoritmos moderadamente complejos) y se pueden enseñar y usar representaciones más compactas (por ejemplo, pseudocódigo).

Muy poco de lo que se enseña en clase de computación se hace en el trabajo, principalmente porque los programadores del mundo real pueden hacer eso en su cabeza, como una segunda naturaleza. Pero uno tiene que llegar primero, y la forma de llegar es entender cómo funcionan las cosas en primer lugar.

Tu maestro está tratando de que pienses en el flujo del programa; para pensar cómo desglosar y organizar los componentes clave de su software.

Los diagramas de flujo introducen una nueva forma de pensar. También, con suerte, introducen su primera exposición a la estética del software; diagrama de flujo desordenado = diagrama de flujo incorrecto, código desordenado = código BAD.

En cuanto a los programadores que ya no los usan mucho, justo. (Pero, haga algún trabajo en el SSIS de SQL Server y es posible que reciba una descarga).

Pero no usar diagramas de flujo no es lo mismo que no poder leerlos y entenderlos. Si no puede leer un diagrama de flujo, Buckley entenderá el código de otras personas.

Entonces, de todos modos, explícale a tu maestro que no estás interesado en ninguna de esas cosas blandas de alto nivel. Dígale que solo va a programar en Asamblea, porque eso es lo que hacen los verdaderos programadores. Estoy seguro de que ella entenderá.

En la escuela aprendes muchas cosas. No tengo conocimiento de la enseñanza de ningún tema que tenga correspondencia directa relevante con cualquier entorno de trabajo.

Si bien los programadores informáticos a los que hace referencia no usan diagramas de flujo en el trabajo, puedo asegurarles que no tendrían un trabajo en programación informática si no hubieran aprobado las calificaciones requeridas para obtener un trabajo en programación informática si no hubieran aprendido todo. ¡Sobre los diagramas de flujo y cómo funcionan las cosas!

La escuela está ahí para probar su capacidad para comprender las complejidades y para evaluar bien después de absorber dicha información. No está ahí para enseñarte cómo hacer un trabajo, hace muy poco en la forma de prepararte para el “trabajo”. Irónicamente, lo que más se acerca es pedirte que hagas cosas extrañas como aprender ‘diagramas de flujo’, cuando llegues a ‘trabajar’ se te pedirá que hagas muchas muchas cosas que a primera vista parezcan totalmente inanas y cuando se investiguen cambiarán para ser totalmente inane.

Tendrá que hacer tareas inane en el “trabajo” independientemente de sus sentimientos hacia su mérito. Esta es una de las únicas tareas relevantes que la escuela le desafiará, ya que en realidad tienen una correlación directa con la experiencia laboral. En el resto, puedes aprender / probar bien / olvidar, ya que nunca más necesitarás usarlo nunca más.

Porque los diagramas de flujo son algo muy importante que lo ayuda a aprender a programar la forma más fácil de programar al principio cuando es un alumno. Cuando mejoras en la programación, ya no necesitas necesitar esto. Es por eso que los programadores expertos no lo usan.

Tiene sentido, ¿verdad? Recuerda cómo aprendiste a escribir con A. B, C …

Porque si entiendes el flujo, es fácil aplicar la lógica y manipular el flujo. Comprender el flujo puede resolver el 50% del problema.

Puede parecerte estúpido porque puedes visualizarlo dentro de tu cabeza y no puedes ver una aplicación del mundo real.

Confíe en mí, mi amigo, poniéndolo en un papel y mirándolo de nuevo puede darle una mejor perspectiva. Puede darle información adicional para manejar un problema.

En el escenario real, tu mente se contamina con muchos datos inesperados. (Personal o Profesional)

No puedes elegir algo donde lo hayas dejado, así que ponerlo en papel es otra buena manera de conceptualizar el problema en cuestión. Además puedes recogerlo desde donde lo dejaste.

No caigas en los atajos y hazlo. Te alegrarás de haberte forzado a hacer esto. Es un buen hábito para elegir.

Me imagino que es para que desarrolle buenos hábitos en torno a la estructuración de sus programas y para asegurarse de que comprende los requisitos.

Aunque muchos programadores podrían no hacer esto en la práctica, podrían hacerlo de manera completamente mental o informal en un papel de rascar. Como profesor, podría hacer que los estudiantes hagan esto para ayudarles a reforzar ciertos “modelos mentales” que son constructos necesarios dentro de la programación.

Además, si bien algunos profesionales pueden no hacerlo, tener documentos dedicados a describir los requisitos o el flujo de un programa puede ayudar a los equipos técnicos a tener discusiones sobre las mejores maneras de implementar el programa en sí.

Eso es relativo.

Podrías usarlo, para ser honesto. E incluso si no lo hace según los estándares oficiales, la capacidad de entender la idea de propagación …

Quiero decir, descomponer un sistema en un flujo de propagación, es fundamentalmente, para empezar, qué es la programación.

Es como, el proceso mismo, de la programación, para empezar.

La mayoría de las veces, es posible que no sea el único en hacer ese proceso en su trabajo como uno solo, pero otra persona podría, de forma similar, al System Architecht o Manager o Leader o lo que sea.

La forma en que el código transita a través de cada paso puede ser esencial para su comprensión de una tarea.

Un programador en el trabajo no puede extraer explícitamente un diagrama de flujo, pero sí tienen un modelo mental del flujo.

¿Cómo obtuvieron esta comprensión? Sencillo. Alguna vez alguien les enseñó acerca de los diagramas de flujo.