¿Consejos o técnicas para usar cuando no sabes cómo codificar algo? [cerrado]

Tengo experiencia como diseñador de UI. Y me di cuenta de que es un poco difícil para mí escribir una pieza de lógica. A veces lo hago bien, pero la mayoría de las veces, termino con algo obsceno (y generalmente lleva mucho tiempo). Y no es que no me guste la programación, de hecho, me está empezando a gustar tanto como el diseño. Es solo que a veces pienso que soy mejor tratando con colores y formas, en lugar de números y lógica (pero quiero cambiar eso).

Lo que suelo hacer es buscar la solución en Internet, copiar el ejemplo e insertarlo en mi aplicación (sé que esta no es una muy buena práctica).

Escuché que un consejo era escribir la lógica en inglés común como comentario antes de escribir el código real.

¿Qué otros consejos y técnicas puedo usar?

Pequeños pasos.

Divide un gran problema en problemas más pequeños. Luego resuelve los problemas más pequeños.

Puntos de bonificación si puede respaldar sus soluciones a los problemas más pequeños con las pruebas unitarias automatizadas.

Por lo general, escribo las cosas en papel mientras lo pienso bien. De esa manera puedo escribir pseudocódigo o hacer dibujos (generalmente ambos), y no tengo que preocuparme por las limitaciones del software de dibujo o lo que cabe en un comentario.

Me parece que si estoy haciendo algo al menos un poco complicado, realmente necesito poner las cosas en papel primero, o de lo contrario termino con algo raro, como usted mencionó.

Si termino con algo hacky, con frecuencia casi funciona. A veces puedo hackearlo hasta que finalmente funcione, a veces no. Si me tomo el tiempo para resolverlo en papel, a menudo funciona sin demasiados problemas.

Creo que has respondido tu propia pregunta, y no lo digo de mala manera: es un consejo común que la mejor manera de aprender a codificar es simplemente codificando. Personalmente, trataría de evitar copiar el código directamente de una fuente a menos que sea absolutamente claro lo que está sucediendo (es decir, que no hay necesariamente otra buena manera de hacer algo), aunque muchos de esos tipos de problemas son sintácticos Tomarse el tiempo para comprender lo que está sucediendo y cómo usted (u otra persona) lo está implementando es lo más importante.

En el tiempo que pasé aprendiendo a desarrollar, descubrí que trabajar con tecnologías MVC es una excelente manera de entender cómo hacer un diseño, como Rails (con lo que estoy trabajando ahora) o iOS / Cocoa Touch . Debido a que está trabajando en un entorno de diseño orientado a objetos, una vez que comienza a pensar en términos de modelos y su lógica se separa de la vista (con los controladores como el pegamento que los une), también comienza a pensar en términos de cómo puedes mantener tus objetos abstraídos de una manera lógica, pero (¡con suerte!) sin complicaciones.

Esto se basa en mis propias experiencias, por supuesto, pero espero que mis pensamientos sobre su pregunta puedan ser de alguna ayuda.

Además de las respuestas ya dadas, una de las mejores maneras de comenzar es aprender de una aplicación que sea simple y donde esté disponible el código fuente.

Aquí es donde brillan repositorios sociales como Github. Un lugar increíble para navegar por ejemplos. Y cuando encuentre uno, puede bifurcarlo de inmediato y hacer lo que quiera con la aplicación, así que una vez que lo tenga:

• puedes correrlo
• modifíquelo aquí y allá y vea cómo cambian las cosas
• a medida que te sientas más cómodo, haces cambios más grandes
• pronto descubrirás que realmente estás aprendiendo

Otra opción es utilizar las implementaciones de referencia de ejemplo clásicas que están documentadas en tantos lugares diferentes. Por ejemplo, el framework Spring de Java utiliza el venerable ejemplo "Pet Store". Creo que incluso puedes encontrar ese ejemplo en Github.

Otros marcos / tecnologías como el marco Groovy's Grail usan otros clásicos como una aplicación de libro para persistir y ver libros y autores, etc.

La última opción que he probado es seguir un buen libro de programación y comenzar a escribir los ejemplos a mano y ponerlos en un repositorio como Github; esto tiene al menos dos beneficios: 1) hay una referencia para usted con sus propias notas que lo ayudarán a recordar cosas interesantes de una manera que recordará y 2) si se encuentra en situaciones difíciles, puede conseguir amigos o colegas fácilmente vea su código y repita con consejos.

La ciencia y especialmente la programación se basa realmente en las experiencias de otros. Hablando figurativamente, copiar / pegar y luego ajustar hasta que entiendas es lo que ayuda a los desarrolladores a convertirse en ingenieros.

Imagine que tiene que hacer un informe sobre su problema a otra persona.
Analiza el problema. Intenta formularlo con la mayor claridad posible. Escribir pseudocódigo, dibujar diagramas.
Piense en lo que podría estar causando el problema y por qué su enfoque es incorrecto.
Pregúntese si hay otras perspectivas desde las que pueda ver su problema.
No lo haga solo en su mente, póngalo en papel (o un documento en su computadora).

Si nada de eso lo ayuda de inmediato, trate de no pensar en el problema por un tiempo. Ten una buena noche de descanso. ¿Todavía no hay solución? Intenta buscar en Google tu problema o busca SO para encontrar una solución.

Si todo lo demás falla, haga una pregunta sobre SO (o SE Programmers si es más apropiado para su pregunta en particular). Asegúrese de incluir realmente su "informe" (o las partes importantes del mismo) cuando haga la pregunta.
Cuando reciba una respuesta, pregúntese por qué su enfoque no funcionó y qué podría haberlo ayudado a llegar a la solución usted mismo. Puede ayudarlo a encontrar una solución para algún problema que encuentre en el futuro que requiera un enfoque similar.

Estoy de acuerdo con pensar en papel. Como regla, primero identifico cada elemento de información que necesitaré y de dónde vendrá. No tiene que ser elegante, solo preciso. Las preguntas de lógica de negocios y las estrategias de diseño generalmente vienen durante este proceso.

Con eso, como desarrollador de Java que trabaja de extremo a extremo en una aplicación, divido las cosas por niveles: presentación, web, lógica de negocios y la capa de acceso a datos. Cuando tengo tiempo, generalmente escribo los nombres de mis clases durante esta parte.

Por último, siempre me esfuerzo por ejecutar pruebas para el back-end, antes de escribir el código. Puede conectar todo con elegancia, pero si no puede acceder al back-end: base de datos o servicio web, por ejemplo, ¡no funcionará!

Algunos de los principios del desarrollo basado en pruebas ayudan mucho aquí.

Una de las mejores formas de resolver problemas complejos es resolverlo para casos de uso específicos y luego descubrir una generalización. Usar TDD promueve exactamente eso. Usted crea un caso de prueba simple y lo hace funcionar, luego crea otro caso de prueba y lo hace funcionar. Finalmente, verá si hay alguna generalización que pueda hacer que le permita manejar ambos casos de prueba con la misma lógica. Si puede, entonces probablemente también manejará muchos otros casos de prueba. Como puede ejecutar todos sus casos de prueba en cualquier momento, puede sentirse libre de mejorar su lógica sin preocuparse por romper algo. De esta manera, una solución hacky no tiene que seguir siendo hacky.

El desarrollo basado en pruebas también promueve

• dividir los problemas grandes en problemas más pequeños, para que sea más fácil obtener una buena cobertura de prueba.
• pensar por adelantado sobre lo que realmente quiere lograr antes de atascarse en los detalles de la implementación.
• evitando el exceso de ingeniería tratando de hacer que las pruebas pasen de la manera más simple posible, y las soluciones simples suelen ser las mejores.

En realidad, hay un libro que responde exactamente esa pregunta:

Cómo diseñar programas: una introducción a la programación y la computación por Matthias Felleisen, Robert Bruce Findler, Matthew Flatt y Shriram Krishnamurthi

Actualmente están trabajando en una segunda edición , y después de eso, un segundo volumen (Cómo diseñar componentes).

Lo realmente genial de este libro es que te ofrece un conjunto de recetas para diseñar programas. En otras palabras, le brinda instrucciones paso a paso que puede seguir (semi) sin pensar para diseñar un programa.

O, para decirlo de otra manera: contiene un conjunto de programas para escribir programas, para que no tenga que descubrir cómo escribir un programa: ¡los autores lo descubrieron por usted!

Además de las respuestas anteriores, a veces no se trata de conocer la lógica en sí, sino de conocer el marco y el lenguaje con el que está trabajando. Cada marco o lenguaje tiene sus propias características y es de gran ayuda familiarizarse con eso.