¿Alguna vez te has preguntado cómo podrías aprender a programar más rápido en tu día a día? Pues si has respondido que si, esto quizás te interese.
Mira.
Mi nombre es Aitor Sánchez, soy desarrollador de apps desde 2014, y en este artículo vas a conocer 12 maneras de lograr el objetivo de absorber y aplicar conocimiento cómo la depuradora de una piscina absorbe y aplica cloro al agua.
Pero antes de continuar, esta es la Flutter Mafia. Es mi newsletter donde tu vas a aprender a hacer apps y a ganar dinero con ellas junto con otros genietes que ya están dentro. Y si te suscribes te regalo mi ebook "Duplica los ingreso de tus apps en 5 minutos" No es broma, quizás te interese.
Y ahora si, comenzamos.
Punto 1 – Más hacer y menos hablar
Cómo era de esperar, el primer paso consiste en eso mismo, en hacer más que hablar y leer.
Partamos de la base de que es una disciplina que se aprende a base de practicar. No es cómo muchas otras que tratan de memorizar toda la información necesaria cómo puede ser la geografía o la historia.
Digo esto, por que conozco a mucha gente, e incluso me incluyo dentro en el pasado, que nos gusta mucho leer y leer y ver video y ver más videos, pero no nos gusta nada ponernos manos a la obra a programar los ejemplos que se van dando en los cursos.
A ver, aprender viendo y leyendo, aprendes. Pero ni una centésima parte de lo que retendrías si fueses probado y escribiendo los ejemplos, e incluso inventando nuevos sobre la marcha, que se van dictando en el curso que vayas haciendo.
Pero no todo queda ahí, este punto no es solo para la programación. En cualquier disciplina, si aplicas este punto, aprenderás mucho más rápidamente que cualquier persona que solo se dedique a ver y leer los ejemplos y lo que explica la persona que está impartiendo el curso en cuestión.
Punto 2 – Presta más atención a la lógica y no al lenguaje en sí mismo
En este punto, me gusta mucho puntualizar, de que no es tan importante, sobre todo cuando estás comenzando, que aprendas a rajatabla la sintaxis del código. Es mucho más importante que aprendas lo que “significa” un bucle, una variable, un condicional, un array, etc…
¿Por qué digo esto? Sencillo, por que cualquiera de estas instrucciones de control de flujo, o lo que son los almacenes de memoria, son similares en TODOS los lenguajes de programación. Lo único que cambia es la manera de escribirlos.
Por este último motivo, es más importante que adquieras y entiendas los conceptos de una manera más profunda que cómo se tipean en sí.
Punto 3 – Elige sabiamente, y en base a tus preferencias
Para continuar con el artículo, es muy importante que selecciones aquello que quieres hacer. A ver, para aclarar esto, si lo que quieres programar son apps móviles no te pongas a aprender a programar en Python ¿entiendes?
Es de vital importancia este punto por que si no eliges lo que quieres hacer, lo vas a hacer con un pequeño punto de desgana que no te permite adquirir los conocimientos de manera que lo haces si de verdad quieres aprender a hacer, por ejemplo, aplicaciones móviles cómo estamos viendo en el ejemplo.
En conclusión, existen muchos tipos de tecnologías, y para muy variadas cosas. Cómo podrías ser las apps móviles, apps de escritorio, backend, frontend, inteligencia artificial, juegos, etc… Cada uno de ellos con un abanico enorme dentro de si mismo. Es más, diría que daría para toda una vida cualquiera de estas tecnologías.
Así que, por esto mismo es muy importante que aprendas lo que quieres hacer antes de ponerte. En mi caso, la programación móvil ha sido lo que he elegido, no se programar apps de escritorio, si apps de consola para automatizar procesos, pero no sabría programar, por ejemplo, un emule.
Bien, apps móviles y mi debilidad, los juegos tanto para móvil como para escritorio.
Punto 4 – Never stuck, learn forever
Este dicho, lo escuche de no se quien hace ya unos cuantos años, y básicamente lo que nos cuenta es que no nos atasquemos con lo primero que aprendamos. Considero un error garrafal quedarnos apalancados en el primer lenguaje/framework/sdk/etc… que aprendamos.
¿Por qué? Pues muy sencillo, el mundo del desarrollo de software, y el software en sí, avanza a pasos de gigante. Por lo que quedarte atascado una tecnología durante mucho tiempo te hace obsoleto muy pronto. No digo que no uses un único lenguaje top, cómo puede ser Phyton.
Pero si digo, que, si quieres programar en Web, no solo aprendas Django, dale un toque a PHP con Laravel o Symfony, o quizás una oportunidad a NodeJS.
O si solo quieres Python, no solo aprendas a programar, cómo hemos visto en el ejemplo, con Django. Dale un try a la inteligencia artificial, al IOT con Raspberry, etc… Ya me entiendes, sal de tu zona de confort constantemente y serás mucho mejor developer.
Punto 5 – Lee código de otras personas
Es muy importante “adoptar” un mentor en nuestras vidas. No necesariamente lo tiene que saber, que es nuestro mentor digo, pero si que puede hacer la función de uno. El simple hecho de que este, el mentor, suba código “open source” a Github y que nosotros lo podamos leer, hará le papel.
Bien, al leer código de otras personas podemos interiorizar prácticas de estas personas más avanzadas profesionalmente que nosotros. Mejoras cómo la implementación de patrones, código limpio y ordenador, principios de desarrollo ágil, etc…
Este tipo de “beneficios” nos vendrán genial, aunque no lo visualices ahora mismo. A largo plazo, el simple hecho de implementar una buena estructura de directorios hará que nuestro código sea mucho más legible y robusto a la hora de extenderlo en aplicaciones más grandes.
Punto 6 - El principal objetivo de la app por delante
Cuando trabajamos en una app, es normal que incurramos en añadir funcionalidad adicional cuando dicha app está "terminada" o a "medias". Me refiero a ese menú tan bonito, compartir en redes, fotos de perfil, perfil de usuarios, etc...
Esto está bien siempre cuando la app se dedique a eso, pero si es un chat, todo lo que escape a esta funcionalidad es incluir paja. Así que céntrate en el objetivo principal de la app y no pierdas el hilo de esta.
Punto 7 - Solo se programa la funcionalidad principal en el MVP
Antes de ponernos a programar la aplicación, tenemos que definir claramente cuales serán estas funcionalidades principales. Y una vez nos ponemos a programar, solo tendremos que programar esta funcionalidad. Muy relacionado con el punto anterior, todo lo adicional sobra para construir un MVP.
Punto 8 - El código, poco a poco
Tenemos por costumbre realizar una gran cantidad (o todo) el código de la app antes de probar nada. Esto, sobre el gasto de tiempo, es totalmente nefasto. Incluso, podemos gastar más del doble del tiempo al hacerlo así.
Por esta razón, es más que recomendable que las implementaciones de código se hagan poco a poco y probando dichas implementaciones una vez estén terminadas. Tanto es así, que es posible que por una fallo que se nos haya escapado al principio de la ejecución, tengamos que cambiar todo el código que ya teníamos escrito.
Punto 9 - Testea y testea antes de seguir
Muy en acuerdo con el punto anterior, es muy recomendable que se pruebe cada una de las mini implementaciones que hemos visto en el punto 8 y que posteriormente se pruebe el conjunto de jerarquía medio (me lo he inventado). Por jerarquía medio nos podemos referir a: Una funcionalidad completa totalmente individual del resto del código de la app. Para poner un ejemplo:
Tenemos una clase "coche" que tienes las funciones "arrancar", "parar", "acelerar" y "frenar".
Bien, las pruebas individuales son probar cada función por separado par que veamos que todo funcione "OK". Y las pruebas de jerarquía medio sería probar la clase en si misma usada en un entorno "real" para ver cómo funciona.
Punto 10 - Primero escribe, luego ordena (modularización)
Es más que probable que esto, en muchos casos, ya lo hagamos de manera implícita en nuestra manera de programar. Yo, en mi caso, lo hago y lo hacía antes de saberlo.
Básicamente se trata de escribir todo el código de, por ejemplo, una función y después modularizarlo. Dicho así suena raro, pero con un ejemplo lo vamos a ver mejor.
Supongamos que la función arrancar hace lo siguiente:
- Introducir la llave en la ranura.
- Girar la llave a la derecha.
- Esperar que el coche comience a sonar de X forma.
- Soltar la llave.
- Setear en true la variable que dice que el coche ha sido arrancado.
La función está cojonuda, pero claro, es una función que está implícita en el código del coche cómo es normal. Pero ¿qué pasaría si ahora la queremos usar en una moto? Tendríamos que implementar toda la función entera y, además, tenemos que modificar cosas por que una moto no es un coche. ¿Qué tal si modularizamos el código?
- Para el 1 y el 2: Creamos, por ejemplo, una clase que se llave "vehicleServices" que va a contener una función que se llame "insertarLlave" con la llave en si misma que estará en otra clase y la dirección a donde tiene que girar. (Ya la podemos usar en la moto y en el coche).
- Para el 3: Dentro de "vehicleServices" creamos una función que se llame "arrancarOk" que nos permitirá conocer, mediante un listener e independientemente del vehículo, si dicho vehículo a terminado de arrancar.
- El resto de queda cómo está.
Pero ahora, si te fijas correctamente, te ahorrarás el código que tendrás que poner en la clase Tractor, Quad, y todo lo que se pueda considerar un vehículo siempre que arranque y tenga llave porque ahora lo podrás hacer mediante la modularización. Espero que se haya entendido, si no, dímelo en los comentarios.
Aunque ahora es posible que no le veas el potencial que tiene, en proyecto grandes, es ahorro de tiempo es muchísimo. Pero cuando digo muchísimo, es muchísimo.
Punto 11 - Evita la recursividad cómo problema
A medida que vamos encontrando problemas a la resolución de nuestro problema principal, entramos en una espiral de búsqueda/aprendizaje que nos puede, cada vez más, alejarnos del problema principal y al que estamos intentando dar solución.
Es muy común, por ejemplo, que cuando hacemos la implementación de X nos hace falta Y y tenemos que aprender cómo se usa este Y. Nos damos cuenta de que para implementar Y nos hace falta W y así sucesivamente...
Ahora bien, llegados a N punto, nos damos cuenta de que el tiempo que hemos invertido aquí no ha servido de mucho para la resolución del problema principal. En ese momento es mejor parar, tomar un café y después seguir. No pierdas el tiempo de esta manera.
Punto 12 - Una breve documentación es mejor que ninguna
Aunque pienses que nunca vas a volver a tocar ese proyecto, es muy recomendable que, a medida que vas programando funcionalidad, la vayas comentando, aunque sea mínimamente.
Los motivos son más que obvios, solamente con definir en un comentario que se va a hacer con X variable que se le a pasado por parámetros a Y función, mañana cuando lo revises, que lo harás, créeme, estarás agradecido de esto y no tendrás que probar para que sirve con el sucesivo gasto de tiempo agregado.
Bueno socio, ¿crees que tienes alguna más que aportar? Déjamela en los comentario y estaré encantado de conocerla.
Punto adicional para los más ganduletes
Aquí te voy a dejar un par de videos de coseña propia en los que explico algunos de estos puntos de una manera mucho más cercana y fácil de consumir. Espero que te gusten, y si es así, pues ya sabes lo que tienes que hacer, suscribirte al canal aquí :)
Algo más que quizás te interese
Mira, en el momento que tu mejoras el logo de una app que tengas publicada en Google Play, las descargas y los ingresos que esta aplicación genera aumentan. Esto es así. Mejor logo es igual a más dinero.
Basándonos en esto, hemos creado esta herramienta que te permite evaluar, optimizar y mejorar los logos de tus apps para que reciban más descargas. No te quiero espoilear, dentro hay un video explicativo. Entra en el enlace.
Geniete, me despido ya. Espero que el contenido te haya ayudado y nos vemos en el siguiente artículo. Hasta entonces ¡que te vaya bien!