A menudo cuando alguien quiere empezar a programar, suele pensar que es bastante complejo e incluso puede resultar abrumador y no saber por dónde comenzar. Este learning path trata de ayudarte a que inicies con buen pie.
Como los deportistas profesionales para poder aprender como hacer algo bien de manera profesional necesitamos ejercitarnos, con ejercicios concretos que nos ayuden a mejorar nuestras habilidades y nuestra técnica.
El objetivo de este learning path es aprender mediante el uso de katas, con las que podrás practicar conceptos de programación diferentes con el fin de que puedas focalizarte en trabajar algo concreto en cada kata.
Seguro que tienes muchas preguntas, es normal, todos las hemos tenido al empezar. Vamos a tratar de responderlas una a una.
Para recorrer este camino en el aprendizaje de desarrollo de software a través de katas te proponemos que sigas nuestras recomendaciones para iniciarte en las buenas prácticas de programación.
Publicado en 2009, el Manifiesto del Software Craftsmanship surgió en un contexto en el que los principales desarrolladores del sector debatían y daban forma a sus filosofías y enfoques del desarrollo de software. El Manifiesto hace hincapié en el viaje continuo del individuo hacia la excelencia técnica, más allá de los procesos y las herramientas, un viaje hacia la excelencia que promueve poner en práctica un enfoque profesional y sobre todo pragmático. Es importante preocuparse por el trabajo que se desempeña y aportar valor constantemente, así como mantener la curiosidad y el compromiso de mejora continua. Este va a ser el hilo conductor de este circuito.
Habitualmente se aprende a programar siguiendo esta secuencia: empezaríamos con los Condicionales que nos van a ayudar a discernir entre diferentes casos dentro de nuestro código y que conjuntamente con los Bucles sentarían las bases de nuestro código. Desde aquí empieza nuestra ruta hacia estructurar nuestro código de una forma más correcta con las Estructuras de Datos, la Orientación a Objetos, las técnicas de Refactorización y los Patrones de diseño tanto Creacionales, Estructurales y de Comportamiento.
Tras asentar las bases de la programación y siguiendo con ese camino hacia la excelencia técnica entraremos en el terreno de las técnicas de testing que nos ayudan a saber si nuestro código es correcto o no, y no sólo eso, serán esos tests los que nos ayudarán a escribir nuestro código de una forma más exploratoria y extrayendo información poco a poco para que nuestra solución sea más robusta y ordenada. TDD es una de ellas, y como veremos a continuación es una de las técnicas fundamentales en el diseño de software de calidad.
¿Qué es Test-Driven Development?
Test-Driven Development (TDD) es una práctica de desarrollo de software de extreme programming creada por Kent Beck y explicada en su libro Test-Driven Development. Se trata de una técnica basada en crear un test que falla por una razón correcta, hacerlo pasar y evaluar si la implementación o los test pueden ser mejorados de alguna forma.
En este enfoque, los tests o pruebas se escriben antes que el propio código, guiando así el proceso de desarrollo.
Pensamos que es un hábito, que nos ayuda en varios puntos:
Proponemos seguir la taxonomía de Bloom y realizar cada uno de los bloques de katas como mínimo 3 veces. En la siguiente sección tendrás una selección de katas según niveles y temáticas.
Cada vez que trabajes un bloque sigue las instrucciones necesarias para su iteración. La idea es que en cada momento que hagas el ejercicio trates de aplicar un acercamiento distinto. Haz todas las katas que aparecen en cada bloque, y ten en cuenta sus posibles restricciones en cada iteración.
Sería bueno que para completar el proceso y sacarle el mayor partido posible sigas estas pautas que ahora te compartimos a la hora de enfrentarte a cada una de las katas.
1. Identifica qué quieres trabajar en cada kata, es decir, qué conceptos podrías aprender con esta kata y cuáles quieres aprender.
2. Te invitamos a leer y ver vídeos sobre los conceptos que estas tratando de aprender. Te dejamos una sección con un montón de recursos útiles para ello.
3. Unirte a un club de lectura o crear uno puede ayudarte.
4. Participar en comunidades de software crafters donde se trabajen este tipo de conceptos también es muy útil.
5. Haz resúmenes de lo que aprendes, y comprártelo con tus compañeros/as.
6. Trabaja en la kata, varias veces.
7. Pide feedback a otras personas que puedan ayudarte.
8. Vuelve a trabajar en la kata aplicando el feedback que has recibido.
9. Revisa tu resumen y aplica el feedback y lo que has aprendido en la kata.
10. Propón una charla en una comunidad o en tu grupo de trabajo.
11. Crear una kata distinta donde se trabaje alguno de los conceptos aprendidos.
12. Publicar tu kata para que otros puedan aprender de ella.
Aquí tienes acceso a una serie de katas clasificadas por nivel de dificultad y recuerda:
Tienes ganas de ampliar tus conocimientos y eso es fantástico. Hay varios temas que están directamente relacionados con las katas y que pueden interesarte.
Te dejamos una propuesta de libros, videos y charlas con los que vas a poder ampliar tus conocimientos a medida que avances en el programa.
Para introducirme en el programa
Me interesa la programación orientada a objetos
Quiero profundizar en refactorización
Me gustaría saber más sobre patrones
Me siento en un nivel avanzado. ¡Quiero más!
Esperamos que sean de utilidad para profundizar en aquellos temas que te resulten más interesantes.
1. Asegúrate de conocer el lenguaje con el que quieres trabajar.
Buena noticia! Ya estás contagiado con el magnífico virus de ir en busca de la maestría. Ya sabes, practicar es la mejor forma de aprender, y el desarrollo de código no escapa a esa máxima. Las katas son ejercicios que van a servirte para practicar, y si quieres añadir un plus de dificultad/diversión te proponemos una lista de restricciones con las que ir aumentando tu nivel de experiencia a la hora de resolverlas.
Te planteamos las siguientes:
Test-and-Commit-or-Revert (TCR):
Técnica para ganar consciencia del ciclo del TDD, si tras escribir el test no conseguimos llegar a tener una solución en 2', se hace revert (usando un control de versiones) y si lo conseguimos hacemos commit.
Baby steps:
Siempre vamos a intentar escribir el mínimo código posible para que nuestros tests pasen a verde.
Para ampliar conocimientos sobre antipatrones te sugerimos que te descargues nuestro ebook sobre antipatrones que seguro que puede serte de utilidad y eches un vistazo a la playlist sobre TDD que tenemos en español.
Sin declaraciones condicionales:
Eliminar por completo los if/else dentro de nuestro código nos puede llevar a repensar nuestra implementación por completo.
Ninguna otra declaración:
Una de las premisas de Object Calisthenics, no usar la expresión "else" para reducir el número de ramas dentro de nuestro código.
Sin primitivos:
Otra de las premisas del Object Calisthenics, encapsular todos los primitivos en objetos que tengan un significado de dominio.
Sin mouse:
Tendemos a dar un uso intensivo del ratón por desconocimiento de los Atajos de Teclado, con esta restricción podemos aprender mucho sobre nuestro IDE.
Solo editor de texto:
Saliendo de todas las ayudas que nos pueda dar el IDE y de las herramientas que nos proporciona, usando el editor de texto podemos trabajar en ser más conscientes de lo que escribimos y porqué.
Conductor y navegante (Driver-Navigator):
Como si de una carrera de rally se tratara el Conductor seguirá todas las instrucciones que el navegante le vaya dando. La comunicación va a ser muy importante en este momento.
Pomodoro:
Una vez ya tenemos la base del pairing con el driver-navigator ahora buscaremos formas de intercambiar roles para ganar más conocimiento de nuestro dominio, la técnica Pomodoro nos ayudará a ello. Se suele cambiar cada 15'-20', pero queda a decisión de la pareja decidir ese rango de tiempo.
Ping-Pong:
Siguiendo con los roles de driver-navigator acordaremos en qué momentos se hará el cambio de rol, por ejemplo al escribir el test, al escribir el código de producción o quizás tras cada bloqueo.
Mob programming:
En este caso el rol del navigator pasa a ser el de un conjunto de personas, ahora no somos una pareja si no 3,4 o incluso más personas que vamos a estar discutiendo y tomando decisiones sobre el código y los tests.
Mute Ping-Pong:
Cómo en el ping-pong iremos cambiando el rol de dirver-navigator cada vez que se escriba un test o trozo de código de producción, pero en este caso no se puede hablar, sólo el código es el que puede hablar.
Evil Coder:
En esta versión del ping-pong pairing, lo que vamos a buscar es escribir el test más complicado que se nos ocurra (a nivel de premisa, no de código) y la otra parte tendrá que intentar escribir el código de producción que ponga en verde ese test.
Te dejamos este enlace con más restricciones diseñadas para ayudarte a pensar en escribir código de manera diferente a como lo harías habitualmente de otra manera.