¿Los programadores experimentados ‘visualizan’ un programa y la ejecución de sus partes?

Creo que una forma más precisa de describir el proceso de diseño de software es analizar los problemas en términos de áreas funcionales. Por ejemplo, la mayoría de los problemas requieren algún tipo de almacenamiento de datos, algún tipo de conexión en red y quizás una interfaz de usuario que puede ser gráfica, de línea de comandos o basada en la web. Una vez que comprende la funcionalidad que necesita ir a su aplicación, generalmente comienza a desglosar esas áreas aún más de una manera orientada a los componentes, aunque muchas arquitecturas de software no se basan realmente en marcos de componentes literales. Finalmente, desglosa los métodos reales que deben abordarse para implementar cada área funcional del programa.

También creo bastante en la refactorización continua. Por ejemplo, si descubres que estás implementando métodos que transmiten un argumento en particular una y otra vez, para cada función, eso es una señal de que tu diseño OO es deficiente. Puede refactorizar sus objetos para incorporar ese argumento como parte del estado del objeto, simplificando en gran medida todo su código como resultado. Knuth dijo una vez, (parafraseando) “Si planeas tirar uno, tirarás dos”. Personalmente, me parece raro desechar el código, pero las refactorizaciones importantes son bastante comunes en todas las organizaciones y un proceso saludable que puede mejorar en gran medida una base de código determinada.

Si por visualizar quiere decir que veo como Matrix con líneas y conexiones, etc. Personalmente no, no conozco a nadie que lo haga. Sin embargo, generalmente puedo visualizar previamente la ejecución, como si me meto en este método, golpeará esto, asignará este fragmento, luego guardaré en db en este momento, etc. Pero eso tiene que ver más con el hecho así es como escribí el código. Si no sé cómo funciona mi propio código, eso es bastante malo (OK, ha sucedido en ocasiones, mientras codificaba a las 2 a.m. o en Javascript lol). Si se trata de una base de código desconocida, no la tocaré hasta que comprenda al menos un nivel por debajo de la abstracción, que, por supuesto, su mapa mental una vez que mire el código / depurador / etc. por los métodos que le resulten pertinentes.

Una cosa que la gente confunde a veces es pensar que los ingenieros, científicos, etc. son geniales. Mientras que algunos sin duda lo son, la mayoría acaba de descubrir por casualidad o experiencia cómo lidiar con la información presentada, para alguna representación visual es mejor, para otro paso conceptual, etc. Lo más importante es descubrir cuál funciona para usted, porque no hay de manera correcta o incorrecta, solo hay una manera que lo lleva de principio a fin con la información correcta

Algunos lo hacen, pero no la mayoría. La visualización mental es un rasgo común entre los genios de las matemáticas, como Einstein, Planck y Hawking. A menudo visualizo las clases, sus métodos y propiedades, y las interacciones entre las clases en mi mente como esferas e interconexiones. Me ayuda a dibujarlos usando diagramas UML simplificados. Diseñé una capa SOA personalizada en PHP Zend Framework 2 usando esta técnica, encapsulando 8 clases base diferentes.

Cualquier desarrollador puede crear un diagrama UML, y deberían hacerlo. Si alguna vez hay una solución de programación que requiere más de 1 clase, redactela. Sin embargo, a muchos desarrolladores no les gusta hacer esto, debido al disfrute de la retroalimentación inmediata de la salida del código escrito. Sin embargo, es fácil tropezar a ciegas al hacer esto, ya que no permite que el desarrollador vea el alcance completo del problema. Estos desarrolladores confundirán el cambio y los resultados, con un progreso genuino.

Es mejor pasar unas horas pensando en qué patrones de diseño usar, y simularlos como un diagrama UML, en lugar de pasar unos minutos escribiendo código mal diseñado que tenga errores, sea difícil de mantener y se deseche.

A menudo hago y dibujo cosas en la pizarra. Me ayuda a pensar. Sin embargo, dibujar para resolver tiene poco que ver con dibujar para explicar.

Una vez que se realiza el desarrollo, a veces explico cómo funciona el sistema al equipo técnico o no técnico. A excepción de los diagramas de bloques de muy alto nivel, el lenguaje visual de explicación es muy diferente del lenguaje de pensamiento para mí.

Una de las mayores diferencias entre los programadores “10x” altamente productivos y los programadores normales es su capacidad de mantener en la cabeza modelos más grandes y complicados mientras codifican.

Mejoras en la práctica, al igual que cualquier habilidad, pero creo que algunas personas son innatamente mejores en eso. El primer obstáculo para aprender a codificar cualquier cosa menos la aplicación más trivial es la capacidad de construir ese modelo.

Sí, tanto el flujo de datos como la estructura.

Como programador, solo visualizo cada proceso ejecutado en un programa. Para mí, es más difícil visualizar un programa como un todo que visualizarlo parte por parte.