¿Cómo piensa un programador? [cerrado]

Question

Esta puede ser una pregunta irremediablemente vaga. Pero estoy interesado en escuchar cualquier proceso de pensamiento lógico que las personas atraviesen cuando aprenden un nuevo concepto o intentan comprender el código que tal vez nunca antes hayan visto.

Básicamente, ¿qué pasos generales se deben seguir para resolver los problemas y qué se necesita para obtenerlos? Si tuviera que diagramar un diagrama de flujo de cómo funciona su proceso mental cuando mira el código o intenta resolver un problema, ¿cómo podría ser?

¿Qué referencias, consejos y suposiciones mentales comunes encuentra útiles para resolver problemas?

¿Cómo es esto diferente entre diferentes dominios? Por ejemplo, ¿de qué manera el proceso de pensamiento de un programador web es similar o diferente al proceso de un desarrollador de aplicaciones de escritorio tradicional?

Answer 1

Creo firmemente que no importa qué tipo de aplicación esté buscando por primera vez, ya sea una aplicación web, una aplicación de escritorio, un controlador de dispositivo o cualquier otra cosa, hay tres pasos uno el desarrollador generalmente sigue para entender cómo funciona:

Obtenga una visión general:

• ¿Qué tipo de aplicación es esta (web, escritorio, ...)?
• ¿Cómo está en capas (independiente, cliente-servidor, n-tier, ...)?
• ¿Cuál es el propósito de la aplicación? ¿Qué se supone que debe hacer?
• ¿Para quién está hecha la aplicación?

Vea cómo funciona:

• ¿Qué idioma (s) se utilizan (s)?
• ¿Cómo se estructura el código?
• ¿Cómo se estructuran los datos?

Comprenda (o al menos intente) la forma en que se ha pensado la aplicación:

• ¿Se ha pensado en absoluto?
• ¿La aplicación está claramente optimizada? (¿Para actuaciones? ¿Para legibilidad?)
• ¿Ha terminado la aplicación? ¿O hay espacio para las evoluciones?
• ¿Hay signos de lanzamientos múltiples?
• etc ...

Los pasos primero y segundo son puramente técnicos, mientras que el tercero DEBE ser tan poco técnico como sea posible ... se trata más de psicología y entender cómo se ha creado la aplicación. Obviamente requiere experiencia, pero siempre que piense lo suficiente y no pierda el tiempo de su cerebro con detalles técnicos, eventualmente lo obtendrá.

Todo este proceso no debería requerir el uso de un teclado. Solo se supone que debes leer, pensar y tomar notas en un papel (no estoy bromeando: ¡lápiz y papel!).

Answer 2

Ho ho, buena suerte con este. Es una gran pregunta y estoy seguro de que obtendrás un montón de respuestas. Aunque tengo que decir que no puedo dar una respuesta satisfactoria a esto, lo último que describiría mis procesos de pensamiento como un diagrama de flujo, no creo que haya una fórmula dorada para esto.

El único consejo para resolver problemas que puedo recomendar es discutirlo con alguien más. En esos momentos en que golpeas una pared de ladrillos, atravesarla con un colega es invaluable. Muy a menudo, también, en realidad ni siquiera agregarán mucho a la discusión: en el proceso de expresar todos sus pensamientos, la solución puede quedar clara.

Answer 3

Las personas son notoriamente malas examinando sus propios procesos de pensamiento, pero le daré un giro. Pruebo muy alto para la capacidad visoespacial en las pruebas de coeficiente intelectual, de medio a alto para las habilidades verbales y moderado para las habilidades matemáticas (supongo que explica mi grado de matemáticas de nivel A). Cuando empiezo a diseñar software, pienso en términos de formas y las conexiones entre ellos. Cuando se trata de describir estos pensamientos a otros (o aclararlos por mí mismo), uso diagramas de bloques simples o los diagramas de objetos tomados del método Objetory de Jacobson, NO las cosas demasiado complejas que sugiere UML. A veces escribo descripciones textuales de cosas complejas, principalmente como recordatorios para mí mismo, pero nunca uso números o matemáticas.

Por supuesto, esto soy solo yo: he trabajado con genios de las matemáticas que eran tan buenos o incluso mejores programadores que yo.

Answer 4

No creo ... que proceso.

Esto es realmente menos volteador de lo que parece. Siempre divido las tareas en sus componentes y luego las desgloso aún más, ¡y eso no solo se aplica a la escritura de software! Al igual que @Mark Pim U, pasa por las cosas de forma secuencial.

Mi esposa se molesta mucho cuando preparo la cena porque me toma mucho tiempo comenzar.

Answer 5

Divide & amp; Conquistar

Comienzo tratando de comprender todo el problema tal como es, y luego empiezo a encontrar patrones que puedo reconocer, y hago lo mismo por ellos en una especie de proceso recursivo, hasta que tengo una solución desglosada que puedo implementar y seguir. más fácilmente.

Answer 6

Esta es una de las raras veces que respondería con "simplemente funciona". Aprendo cosas rodando a través de ellos. No tengo trucos o dispositivos para ayudarme. Me tomó algo de tiempo aprender PHP, pero después de eso Javascript fue mucho más fácil. Una vez que abordas una cosa, los siguientes elementos se vuelven acumulativamente más fáciles.

Answer 7

Personalmente, llevo a cabo un diálogo interno conmigo mismo 'OK, así que necesitamos recorrer esta lista de enteros'. "Pero podemos romper cuando encontramos el valor que queremos". 'OK, ¿la lista se inicializará definitivamente cuando empecemos?'

Me interesaría ver si se ha realizado alguna investigación psicológica sobre técnicas de resolución de problemas.

Answer 8

Similar a Jonathan Sampson, simplemente funciona.

Cuando estoy atacando un problema real, trato de pensar en la forma más lógica de resolverlo. Luego, cuando todo sale mal (como suele suceder), tengo que dar cientos de pasos para hacer las cosas. Solo manténgase enfocado en ese objetivo final, esa forma lógica y llegará allí.

Eventualmente, sin embargo, decide funcionar para mí y termino con un producto terminado que generalmente no es como lo planeé. Mientras los clientes estén contentos, ¡lo estoy!

Answer 9

Personalmente, veo código en mi cabeza pictoralmente en lugar de textualmente (como Neil Butterworth), es un poco difícil de describir ya que (citando STIV) "no hay un marco de referencia común".

Answer 10

Mi habilidad principal es identificar similitudes entre modelos o sistemas que ya conozco y la tarea en cuestión. Las conexiones entre algunos de estos pueden parecer bastante abstractas; La clave es detectar las conexiones. Esto lleva a la abstracción de patrones y enfoques comunes que son ampliamente aplicables. En relación con esto, lo más importante que aprendí sobre los algoritmos fue que el problema nunca es "inventar un algoritmo inteligente para resolver X". Es el 'problema modelo X de tal manera que puede resolverse mediante el algoritmo inteligente existente Y'.