Você já sabe o que é um kata: um exercício de código pequeno que você repete pra treinar a técnica, não pra entregar. O problema é que muita sessão de kata vira só "resolver o exercício de novo" — e aí ela ensina pouco. A diferença entre um kata que rende e um que só passa o tempo quase nunca está no exercício. Está em como você conduz a sessão.
Timeboxe e apague tudo no fim
Defina o tempo antes de começar: 45 minutos, 1 hora, o que for. Quando o timer toca, acabou — mesmo que o código não esteja "pronto". A meta não é terminar, é praticar.
E no fim, apague. Delete o código, feche a branch sem commitar. Parece desperdício mas é o ponto todo: se você sabe que vai jogar fora, para de se apegar à solução e passa a prestar atenção no caminho.
Varie as restrições — é ali que mora o aprendizado
Repetir o mesmo kata do mesmo jeito te ensina a decorar a resposta. Repetir com uma restrição nova te força a pensar de novo. Algumas que funcionam bem:
- Só TDD, sem exceção: nenhuma linha de produção sem um teste vermelho antes.
- Sem
if: nada de condicional — te empurra pra polimorfismo, tabelas de lookup, null object. - Funções de no máximo 3 linhas: obriga a extrair e nomear cada passo.
- Sem mouse / só teclado: treina navegação e refactoring assistido pela IDE.
- Silêncio total em par: só o código e os testes comunicam.
Uma restrição por sessão. Duas ao mesmo tempo viram quebra-cabeça, não treino.
Ping-pong: pareamento que força foco
O formato ping-pong é o melhor jeito de fazer kata em dupla. A pessoa A escreve um teste que falha. A pessoa B faz o teste passar e escreve o próximo teste que falha. A pessoa A faz esse passar, e assim por diante.
O efeito é que ninguém fica assistindo de fora. Quem não está digitando está pensando no próximo teste. E como o teste vem de quem não vai implementá-lo, você para de escrever testes sob medida pra sua própria solução mental.
Dojo em grupo: rotação e plateia que participa
No coding dojo (formato Randori), uma dupla trabalha na frente de todo mundo, projetando a tela. A cada 5–7 minutos rotaciona: quem estava no teclado volta pra plateia, quem estava co-pilotando assume, e alguém da plateia entra.
Duas regras que salvam o dojo:
- A plateia só comenta quando os testes estão verdes. Debater design com teste vermelho na tela vira caos.
- Quem entra assume o código como está, sem reclamar. O objetivo é continuar o raciocínio do grupo, não impor o seu.
Um facilitador cuida do timer e das regras, sem tocar no código.
Escolha o kata certo pro objetivo
O exercício não é neutro — cada um treina uma coisa. Escolha pelo que você quer praticar hoje:
- FizzBuzz / Roman Numerals: ritmo de TDD e passos pequenos. Ótimo pra aquecer ou pra quem está começando.
- Bowling / Gilded Rose: refactoring de lógica bagunçada e cobertura antes de mexer.
- Mars Rover / Bank Account: design, separação de responsabilidades, modelagem.
Rodar Gilded Rose pra treinar "passos pequenos" ou FizzBuzz pra treinar arquitetura é desperdiçar a sessão. Combine o kata com a intenção.
Guarde os últimos 10 minutos pra refletir
Sem retrô, o kata vira ginástica sem propósito. Pare antes do fim e pergunte, em grupo ou pra você mesmo: o que a restrição de hoje forçou a gente a fazer diferente? Onde travamos? Qual passo repetiríamos e qual cortaríamos?
É nessa conversa que a prática vira aprendizado transferível — o que você leva pro código de verdade amanhã.
Kata bom não é o que você resolve mais rápido. É o que te deixa desconfortável na medida certa, com uma restrição clara, um formato que mantém todo mundo pensando e cinco minutos no fim pra entender o que mudou na sua cabeça. Escolha uma restrição pra próxima sessão e apague o código no fim. O aprendizado fica.
