Te encuentras con el problema que muy pocos (si los hay) cursos / libros / tutoriales realmente te enseñan: cómo convertir un “problema” / idea en un conjunto de acciones lo suficientemente detalladas como para que una computadora pueda “entender” qué hacer .
Le han dado muestras y formas estándar de solucionar problemas estándar. Entonces se espera que extrapoles esos a su problema / idea específica, combinándolos a su gusto. Pero ahí es donde los cursos (et al) generalmente se detienen … porque esa parte es la parte difícil de la programación.
El lenguaje es casi inmaterial en comparación con esto. Incluso las estructuras de datos y los algoritmos son meros ejemplos de cómo otros han resuelto estos problemas antes. Afortunadamente, se han resuelto tantos problemas que la mayoría se puede terminar a través de ajustes menores a algoritmos de ejemplo utilizando estructuras de datos prediseñadas. Pero también, desafortunadamente, hay tantos que es posible que no veas el algoritmo (madera) para las teorías (árboles).
- ¿Los programadores experimentados 'visualizan' un programa y la ejecución de sus partes?
- ¿Se dirige al desastre si tiene demasiadas partes móviles en la arquitectura de su sistema de software?
- En el contexto de una aplicación Rails, ¿qué hacen los ayudantes y por qué son útiles?
- ¿Cuáles son los principales desafíos de las pruebas de carga?
- ¿Puede una computadora vencer a un GM de ajedrez usando la misma potencia?
Creo que el mejor curso de acción para la mayoría de los posibles programadores es tratar de comprender el problema perfectamente, es decir, asegurarse de saber qué entradas está tratando de convertir a qué resultados (eso es realmente cualquier programa). Luego, para comenzar a dividir ese problema en subproblemas (es decir, tratar de descubrir el “cómo” mediante la técnica de dividir y conquistar). Al principio, no se preocupe demasiado por cómo codificar, y mucho menos por lo que la computadora misma va a hacer. Solo piense en cómo le diría a otra persona (con habilidades similares a usted) los pasos para resolverlo. Luego, “atonta” a tu persona imaginaria y divide esos pasos en instrucciones aún más simples. Continúa por este camino hasta que veas algo familiar en uno de los algoritmos / estructuras de datos que has aprendido. Solo entonces comienza a codificar.
Pocos programadores comprenden este “proceso de diseño” desde el principio, y la mayoría solo se acostumbra después de una práctica seria (a veces incluso años antes de que puedan “idear” un gran programa por sí mismos). Descubrirá que cuanto más lo haga, más fácil será. Es más como aprender a surfear que aprender historia, al principio parece completamente imposible. Pero cuanto más intentas y fracasas, menos fallas, hasta que tienes éxito. Y cuanto más lo sigas, más trucos complejos podrás hacer en mares cada vez más agitados.
Solo he visto otro curso que lo hace de manera completamente opuesta. Busque algo llamado “De NAND a Tetris”. Te muestra de manera efectiva los detalles detrás (incluso) del hardware para que entiendas “por qué” una computadora es tan estúpida. Tenga en cuenta que también sigue hasta el último ejemplo de cómo construir un juego de tetris, solo que comienza por “construir” primero la computadora. Puede ser una buena manera de aprender para algunos, pero según mi experiencia, la mayoría se beneficiaría más de un proceso de diseño de arriba hacia abajo.