Katas de programación: buenas prácticas para transformar ejercicios repetidos en entrenamiento deliberado, aprendizaje técnico y mejora real del código

Imagina la escena: separas una noche para "practicar código". Eliges FizzBuzz, abres el editor, lo resuelves en pocos minutos, ejecutas las pruebas —cuando existen— y piensas: "bien, ya sé hacer esto". La semana siguiente pruebas otra kata, después otra y otra más. La lista crece, pero la sensación de evolución técnica no la acompaña.

Este es un signo común de que la práctica se convirtió en ejecución automática.

Las katas de programación no consisten en resolver un problema difícil una sola vez. Funcionan mejor cuando tratamos los ejercicios pequeños como entrenamiento deliberado: repetir con intención, observar decisiones, recibir feedback y ajustar la forma en que escribimos código.

El valor está menos en el "terminé" y más en el "¿qué noté sobre mis pruebas, nombres, refactorizaciones y decisiones de diseño?".

Esta guía es para quienes ya han oído hablar de las katas, pero quieren practicarlas de manera más consistente, productiva y conectada con una mejora real del código.

TL;DR

• Las katas son ejercicios cortos que se repiten con intención, no pruebas de inteligencia ni rankings de velocidad.
• El mejor entrenamiento comienza antes de abrir el editor: define una habilidad específica que quieras practicar.
• Los ejercicios simples ayudan porque reducen la carga del dominio y hacen más visibles las decisiones técnicas.
• TDD puede ser una excelente herramienta, pero no debe convertirse en un ritual vacío.
• Revisar el proceso es tan importante como hacer que todas las pruebas pasen.
• El pair programming, la revisión en grupo y la comunidad aumentan la calidad del feedback.
• Una kata bien practicada termina con una observación clara que orienta la próxima sesión.

Katas de programación: qué son y qué no son

Una kata de programación es un ejercicio corto, normalmente con reglas simples, que se repite con intención, observación y ajuste. La idea se acerca a la práctica deliberada: entrenas movimientos específicos en un entorno controlado para mejorar tu técnica.

Por eso, una kata no debe tratarse como un único intento para "acertar la solución". Si la resolviste una vez y nunca más volviste a mirarla, quizá hiciste un ejercicio útil, pero todavía no exploraste todo el potencial de la kata.

También conviene diferenciar las katas de otras prácticas:

• Desafíos de algoritmos y competencias: pueden ser buenos para el razonamiento lógico, pero con frecuencia priorizan el tiempo, el ranking o el rendimiento algorítmico. En este contexto, las katas priorizan la técnica de programación, el feedback y la evolución del código.
• Tareas de proyectos reales: los sistemas reales involucran dominio, código legado, integración, producto, comunicación y restricciones organizacionales. Las katas no sustituyen nada de eso.
• Tutoriales pasivos: ver a alguien resolver un problema puede ayudar, pero la práctica ocurre cuando tomas decisiones, te equivocas, pruebas hipótesis y revisas el resultado.
• Copiar código sin entenderlo: repetir la solución de otra persona sin reflexionar sobre los nombres, las pruebas, la estructura y los trade-offs se convierte en mecanografía guiada.

Los ejercicios simples son útiles precisamente porque reducen el ruido del dominio. En FizzBuzz, por ejemplo, no necesitas entender reglas fiscales, autenticación distribuida ni una cola asíncrona temperamental a las tres de la mañana. Eso deja espacio para observar detalles: ¿las pruebas son claras? ¿Los nombres ayudan? ¿La estructura facilita los cambios? ¿La refactorización preserva el comportamiento?

Si quieres un punto de partida sobre la idea de la práctica diaria, vale la pena leer el artículo Code Katas: practique programación diariamente. Para conectar esta práctica con el aprendizaje continuo y el cuidado del código, el texto Qué es Software Craftsmanship ofrece un contexto importante.

Una advertencia: una kata no es una certificación de seniority. Resolver Bowling Game de memoria no convierte automáticamente a nadie en una persona desarrolladora sénior, del mismo modo que saber tocar una escala no significa dominar un concierto entero.

Ayuda, pero es entrenamiento de fundamentos. Otra advertencia: la práctica aislada no sustituye el mantenimiento de sistemas reales. Lo complementa.

Qué debe desarrollar una buena sesión de kata

Antes de abrir el editor, define qué quieres entrenar. Parece sencillo, pero cambia por completo la sesión.

En lugar de decir:

"Voy a hacer FizzBuzz."

Es mejor decir algo como:

"Voy a practicar nombres expresivos y pasos pequeños de refactorización en FizzBuzz."

O:

"Voy a usar String Calculator para entrenar TDD incremental, escribiendo una prueba pequeña cada vez."

Este cambio desplaza el foco del ejercicio como "problema que hay que resolver" y lo coloca en la habilidad que quieres desarrollar.

Una buena sesión de kata suele tener algunos elementos de práctica deliberada:

• alcance limitado, para que quepa en una sesión corta;
• meta específica, como mejorar las pruebas, refactorizar mejor o comunicar decisiones;
• feedback rápido, mediante pruebas, revisión o pair programming;
• repetición con un cambio consciente, no repetición en piloto automático;
• revisión del resultado y del proceso, para decidir el próximo experimento.

En la práctica, las katas pueden ayudar a desarrollar habilidades como:

• escribir pruebas pequeñas y claras;
• descomponer el comportamiento en partes más pequeñas;
• identificar duplicación;
• refactorizar de forma segura;
• manejar casos límite;
• explicar decisiones técnicas;
• percibir cuándo una abstracción ayuda o estorba;
• mejorar los nombres de funciones, métodos, clases y variables.

Por otro lado, existe un límite. Los ejercicios muy simples facilitan el foco en la técnica, pero pueden dejar de desafiar ciertos aspectos del diseño después de varias repeticiones.

En ese momento, puede ser mejor cambiar la restricción, practicar con otro lenguaje, resolver la kata en pareja o elegir otra con reglas más complejas.

Cómo elegir una kata adecuada para tu objetivo de entrenamiento

Elegir una kata no debería comenzar con la pregunta "¿cuál es la más famosa?", sino con "¿qué habilidad quiero practicar ahora?".

Empieza por el tipo de habilidad que quieres practicar

Algunos criterios ayudan bastante:

• el problema debe ser lo suficientemente pequeño como para caber en una sesión;
• las reglas deben ser claras;
• debe existir la posibilidad de una evolución incremental;
• el ejercicio debe abrir espacio para pruebas y refactorización;
• la complejidad debe ser compatible con el objetivo de la práctica.

Por ejemplo:

• FizzBuzz es bueno para los primeros ciclos de pruebas, las reglas condicionales, los nombres simples y la refactorización de condicionales.
• String Calculator ayuda a practicar TDD incremental, validación, evolución de requisitos y casos de error.
• Roman Numerals trabaja reglas de conversión, pruebas de límites y decisiones sobre excepciones.
• Bowling Game es interesante para descomponer reglas y observar el diseño guiado por pruebas.
• Game of Life añade reglas de dominio, composición y evolución de una solución más allá del caso trivial.

Observa que el valor no está en crear un catálogo enorme. El valor está en elegir el ejercicio adecuado para el tipo de tensión técnica que quieres observar.

Si nunca has practicado TDD, quizá String Calculator sea mejor que Game of Life. Si ya conoces bien FizzBuzz, tal vez la sesión necesite una restricción nueva:

"No voy a dejar condicionales duplicados."

O:

"Voy a hacer ping-pong pairing."

O incluso:

"Voy a registrar cada refactorización que haga."

La kata es pequeña a propósito. La intención es utilizar este espacio controlado para observar mejor tus decisiones.

Elige pocos ejercicios y profundiza

Una trampa común es cambiar de kata cada vez que aparece una dificultad. La persona salta de FizzBuzz a Roman Numerals, después a Bowling Game y luego a Game of Life, siempre en busca de algo nuevo. Puede ser divertido, pero también puede ocultar el aprendizaje.

Repetir el mismo ejercicio forma parte del método. La primera ejecución revela el problema. Las siguientes revelan tus hábitos.

Puedes notar, por ejemplo, que:

• siempre escribes pruebas demasiado grandes;
• tardas en cambiar el nombre de algo cuya intención ya cambió;
• creas abstracciones demasiado pronto;
• evitas refactorizar cuando la suite de pruebas no te da confianza;
• resuelves la regla, pero dejas el código difícil de explicar.

Por otro lado, repetir demasiado sin un objetivo nuevo se convierte en automatismo. Si ya has resuelto FizzBuzz diez veces de la misma manera, quizá ya no estés entrenando; tal vez solo estés haciendo estiramiento de dedos sobre el teclado.

Para renovar el aprendizaje, varía una restricción, un lenguaje, un enfoque o la pareja de trabajo.

Un método práctico para realizar una kata en 30 a 60 minutos

Una sesión de kata no tiene por qué ocupar toda una tarde. En muchos casos, entre 30 y 60 minutos bien conducidos enseñan más que varias horas de intentos dispersos.

Antes de programar: define una intención y una restricción

Comienza eligiendo un objetivo observable. Algo que puedas evaluar al final.

Ejemplos:

• "Quiero escribir pruebas con nombres que expliquen el comportamiento."
• "Quiero refactorizar sin romper la suite."
• "Quiero evitar los métodos largos."
• "Quiero practicar commits pequeños."
• "Quiero explicar cada decisión en voz alta durante el pair programming."
• "Quiero identificar la duplicación antes de crear abstracciones."

Después, elige una restricción productiva. Las restricciones no sirven para complicar las cosas por deporte; sirven para aumentar la atención sobre un aspecto específico.

Por ejemplo:

"Al final, quiero poder explicar por qué existe cada prueba y eliminar duplicaciones sin romper la suite."

Esta intención ya crea un criterio de calidad mejor que "terminar rápido".

Durante la implementación: usa ciclos cortos de feedback

Un flujo sencillo para conducir la sesión es:

1. entender una regla;
2. escribir una prueba pequeña;
3. implementar lo mínimo necesario;
4. refactorizar;
5. revisar la decisión;
6. repetir.

Este flujo combina bien con TDD, pero aquí TDD debe verse como una herramienta, no como una obligación religiosa. Es útil cuando te ayuda a avanzar en pasos pequeños, recibir feedback rápido y proteger las refactorizaciones.

Si TDD todavía es un tema nuevo para ti, el artículo Pruebas unitarias: desde cero hasta TDD puede servir como material de profundización antes de una sesión más centrada en esta técnica.

Algunos cuidados durante la implementación:

• Evita escribir todas las pruebas antes de implementar. Puede parecer organizado, pero pierdes parte del aprendizaje que generan los ciclos pequeños.
• Evita el "TDD de fachada": implementar todo primero y escribir las pruebas después únicamente para validar lo que ya se hizo.
• No anticipes toda la arquitectura solo porque ya conoces el ejercicio.

Este último punto es especialmente importante. En una kata muy conocida, es tentador comenzar por el diseño "final". Eso puede ahorrar tiempo, pero reduce el entrenamiento de descubrimiento incremental.

Si el objetivo de la sesión es practicar la evolución guiada por feedback, demasiados atajos interfieren.

Al terminar: revisa el proceso, no solo el resultado

Cuando todas las pruebas pasan, la sesión todavía no ha terminado.

Reserva los últimos minutos para responder preguntas como:

• ¿Qué decisión hizo que el código fuera más simple?
• ¿Dónde dudé?
• ¿Qué pruebas fueron difíciles de escribir?
• ¿Qué duplicación apareció?
• ¿Qué acoplamiento surgió?
• ¿Qué quedó más claro después de la refactorización?
• ¿Qué cambiaría en la próxima repetición?

Un registro breve ya ayuda. Puede ser algo sencillo:

"Hoy noté que mis pruebas comenzaron describiendo la implementación, no el comportamiento. En la próxima sesión, me enfocaré en nombres de pruebas más claros."

Esta observación vale mucho. Transforma una ejecución aislada en continuidad de aprendizaje.

Cómo usar TDD y la refactorización sin convertir la kata en un ritual

TDD y la refactorización combinan muy bien con las katas, pero existe una trampa: convertir la técnica en una coreografía.

El objetivo de TDD no es repetir "red, green, refactor" como si fuera una contraseña secreta de un club. El objetivo es obtener feedback, orientar decisiones y mantener el código evolutivo.

Del mismo modo, refactorizar no significa "cambiar algo porque se ve feo". Significa mejorar la estructura sin alterar el comportamiento.

La relación entre pruebas, diseño y refactorización puede pensarse así:

• las pruebas hacen que los cambios sean más seguros;
• la refactorización mejora la estructura preservando el comportamiento;
• los ciclos cortos revelan pronto los problemas de diseño;
• el diseño mejora cuando prestas atención a la fricción que aparece al añadir nuevas reglas.

En una String Calculator, por ejemplo, puedes comenzar devolviendo el resultado para una entrada vacía. Después, avanzar a un número. A continuación, a dos números. Solo entonces introducir separadores, múltiples valores o reglas adicionales. Esta evolución gradual te obliga a tomar decisiones con feedback frecuente.

En FizzBuzz, puedes observar cuándo las condiciones repetidas empiezan a incomodar. Tal vez el orden de las comprobaciones dificulte añadir una regla nueva. Quizá nombres como result o value sean demasiado genéricos para explicar la intención. Tal vez extraer una función ayude —o quizá sea exagerado en ese momento.

Aquí aparecen los trade-offs:

• Crear abstracciones demasiado pronto puede hacer que un problema simple se vuelva artificialmente complejo.
• Refactorizar solo por motivos estéticos puede empeorar la claridad.
• No refactorizar nada puede ocultar duplicaciones y decisiones frágiles.
• Usar TDD puede ayudar mucho, pero no todas las sesiones tienen que comenzar con TDD.

Una alternativa válida es crear primero una solución exploratoria y, después, escribir pruebas para caracterizar el comportamiento antes de refactorizar. Esto puede ser útil cuando tu objetivo es comparar estilos de diseño o entender primero el problema.

Lo importante es dejar clara la intención.

Aprende más con revisión, pair programming y comunidad

Las katas se vuelven más ricas cuando dejan de ser una práctica solitaria. Comparar soluciones no debería ser una competencia para decidir "quién lo hizo mejor". El objetivo es observar decisiones, alternativas y costos que pasaron desapercibidos.

Dos códigos pueden resolver Roman Numerals correctamente y, aun así, revelar estrategias muy diferentes:

• una solución puede priorizar tablas de conversión;
• otra puede utilizar la descomposición por posiciones decimales;
• una puede tener pruebas de límites más claras;
• otra puede facilitar más la incorporación de nuevas reglas;
• una puede ser más fácil de leer, pero menos flexible;
• otra puede ser más extensible, pero demasiado compleja para el problema actual.

Algunos formatos útiles para practicar en pareja o en grupo incluyen:

• driver-navigator: una persona escribe y la otra observa la dirección, los riesgos y los próximos pasos; después intercambian los roles;
• ping-pong pairing: una persona escribe una prueba, la otra hace que pase y los roles se alternan;
• code review posterior a la kata: cada persona resuelve de manera individual y después revisan juntas las soluciones.

Por ejemplo: dos personas resuelven Roman Numerals por separado durante 30 minutos. Después, conversan sobre los nombres, las pruebas de límites, la estructura y la facilidad para añadir reglas. Probablemente, la conversación enseñará más que simplemente mirar la propia solución terminada.

Una retrospectiva breve también ayuda:

• ¿Qué aprendimos?
• ¿En qué estuvimos en desacuerdo?
• ¿Qué decisión tuvo un costo oculto?
• ¿Qué alternativa queremos probar en la próxima sesión?

El cuidado aquí consiste en evitar que la revisión se convierta en una defensa del ego. No es un tribunal, un ranking ni una prueba de velocidad. Es entrenamiento técnico. El código es el material de estudio, no una extensión de la identidad de quien lo escribió.

El pair programming también tiene trade-offs: el feedback suele ser más rico, pero disminuye el tiempo individual frente al teclado. Por eso, alternar sesiones individuales y colaborativas puede atender objetivos diferentes.

Si quieres practicar con otras personas, participa en la comunidad SCCB y acompaña encuentros, conversaciones y actividades técnicas.

Evita la repetición mecánica: crea una rutina de evolución

Una rutina sostenible es mejor que un pico de entusiasmo seguido del abandono. Una sesión semanal corta, o dos sesiones de 30 minutos, ya pueden crear continuidad, siempre que cada sesión tenga un objetivo.

Un ciclo sencillo de progresión puede ser:

1. resolver una kata conocida con foco en la comprensión;
2. repetirla con una técnica específica;
3. revisarla con otra persona;
4. cambiar una restricción o un lenguaje;
5. registrar qué se transfirió al trabajo real.

Este último paso es importante. Las katas no sustituyen los proyectos reales, pero pueden mejorar movimientos que utilizas en ellos.

Por ejemplo: después de practicar pruebas de límites en Roman Numerals, puedes aplicar el mismo cuidado a una regla de validación en un sistema real. Después de entrenar la refactorización en String Calculator, quizá sea más fácil hacer una pequeña mejora de forma segura en código legado. Después de practicar cómo explicar decisiones durante el pair programming, tal vez tu próxima code review sea más objetiva.

Aun así, mantén separados los contextos:

• las katas entrenan movimientos técnicos en un entorno controlado;
• los proyectos reales involucran dominio, integración, mantenimiento, comunicación, producto y restricciones de negocio.

Otro error común es medir la evolución únicamente por el tiempo de ejecución o por la cantidad de ejercicios completados. "Resolví 20 katas" dice poco si no sabes qué cambió en tu forma de pensar y escribir código.

Una pregunta mejor sería:

"¿Qué hago hoy con más claridad, seguridad o intención que antes?"

Una kata bien practicada no termina cuando todas las pruebas pasan. Termina cuando puedes salir con una observación clara que oriente la próxima sesión.

Próximos pasos

Para empezar sin complicarte:

1. Elige una kata sencilla, como FizzBuzz o String Calculator.
2. Define una intención específica: pruebas, nombres, refactorización, casos límite o comunicación.
3. Practica durante 30 a 60 minutos.
4. Reserva los últimos minutos para revisar el proceso.
5. Registra una observación y una hipótesis para la próxima repetición.
6. Cuando sea posible, revisa la solución con otra persona.

Si quieres practicar en comunidad, consulta los próximos eventos de SCCB y participa en las conversaciones técnicas.