Katas de programação: como praticar melhor sem transformar treino em repetição vazia

Imagine a cena: você separa uma noite para “praticar código”. Escolhe FizzBuzz, abre o editor, resolve em poucos minutos, roda os testes — quando existem — e pensa: “ok, já sei fazer isso”. Na semana seguinte, tenta outra kata, depois outra, depois outra. A lista cresce, mas a sensação de evolução técnica não acompanha.

Esse é um sinal comum de que a prática virou execução automática.

Katas de programação não são sobre resolver um problema difícil uma vez. Elas funcionam melhor quando tratamos exercícios pequenos como treino deliberado: repetir com intenção, observar decisões, receber feedback e ajustar a forma como escrevemos código.

O valor está menos no “terminei” e mais no “o que percebi sobre meus testes, nomes, refatorações e escolhas de design?”.

Este guia é para quem já ouviu falar de katas, mas quer praticar de forma mais consistente, produtiva e conectada com melhoria real de código.

TL;DR

Katas são exercícios curtos repetidos com intenção, não provas de inteligência nem ranking de velocidade.
O melhor treino começa antes do editor: defina uma habilidade específica para praticar.
Exercícios simples ajudam porque reduzem a carga do domínio e deixam decisões técnicas mais visíveis.
TDD pode ser uma ótima ferramenta, mas não deve virar ritual vazio.
Revisar o processo é tão importante quanto fazer todos os testes passarem.
Pair programming, revisão em grupo e comunidade aumentam a qualidade do feedback.
Uma kata bem praticada termina com uma observação clara para orientar a próxima sessão.

Katas de programação: o que são — e o que não são

Uma kata de programação é um exercício curto, normalmente com regras simples, repetido com intenção, observação e ajuste. A ideia se aproxima da prática deliberada: você treina movimentos específicos em um ambiente controlado para melhorar sua técnica.

Por isso, uma kata não deve ser tratada como uma tentativa única de “acertar a solução”. Se você resolveu uma vez e nunca mais olhou para aquilo, talvez tenha feito um exercício útil, mas ainda não explorou o potencial da kata.

Também vale separar katas de outras práticas:

Desafios de algoritmo e competição: podem ser bons para raciocínio lógico, mas frequentemente priorizam tempo, ranking ou performance algorítmica. Katas, neste contexto, priorizam técnica de programação, feedback e evolução do código.
Tarefas de projeto real: sistemas reais envolvem domínio, legado, integração, produto, comunicação e restrições organizacionais. Katas não substituem isso.
Tutoriais passivos: assistir alguém resolvendo pode ajudar, mas a prática acontece quando você toma decisões, erra, testa hipóteses e revisa.
Copiar código sem entender: repetir a solução de outra pessoa sem refletir sobre nomes, testes, estrutura e trade-offs vira digitação guiada.

Exercícios simples são úteis justamente porque diminuem o ruído do domínio. Em FizzBuzz, por exemplo, você não precisa entender regras fiscais, autenticação distribuída ou uma fila assíncrona temperamental às três da manhã. Isso abre espaço para observar detalhes: os testes estão claros? Os nomes ajudam? A estrutura facilita mudança? A refatoração preserva comportamento?

Se você quiser um ponto de partida sobre a ideia de prática diária, vale ler o artigo Code Katas: pratique programação diariamente. Para conectar essa prática com aprendizado contínuo e cuidado com o código, o texto O que é Software Craftsmanship traz um contexto importante.

Um cuidado: kata não é atestado de senioridade. Resolver Bowling Game de memória não transforma ninguém automaticamente em pessoa desenvolvedora sênior, do mesmo jeito que saber tocar uma escala não faz alguém dominar um show inteiro.

Ajuda, mas é treino de fundamentos. Outro cuidado: prática isolada não substitui manutenção de sistemas reais. Ela complementa.

O que uma boa sessão de kata deve desenvolver

Antes de abrir o editor, defina o que você quer treinar. Parece simples, mas muda completamente a sessão.

Em vez de dizer:

“Vou fazer FizzBuzz.”

Prefira algo como:

“Vou praticar nomes expressivos e passos pequenos de refatoração em FizzBuzz.”

Ou:

“Vou usar String Calculator para treinar TDD incremental, escrevendo um teste pequeno por vez.”

Essa mudança tira o foco do exercício como “problema a resolver” e coloca o foco na habilidade a desenvolver.

Uma boa sessão de kata costuma ter alguns elementos de prática deliberada:

escopo limitado, para caber em uma sessão curta;
meta específica, como melhorar testes, refatorar melhor ou comunicar decisões;
feedback rápido, por meio de testes, revisão ou pareamento;
repetição com mudança consciente, não repetição no piloto automático;
revisão do resultado e do processo, para decidir o próximo experimento.

Na prática, katas podem ajudar a desenvolver habilidades como:

escrever testes pequenos e claros;
decompor comportamento em partes menores;
identificar duplicação;
refatorar com segurança;
lidar com casos de borda;
explicar decisões técnicas;
perceber quando uma abstração ajuda ou atrapalha;
melhorar nomes de funções, métodos, classes e variáveis.

Por outro lado, existe um limite. Exercícios muito simples facilitam o foco na técnica, mas podem deixar de desafiar aspectos de design depois de algumas repetições.

Nesse momento, pode ser melhor mudar a restrição, praticar em outra linguagem, resolver em dupla ou escolher outra kata com regras mais ricas.

Como escolher uma kata adequada ao objetivo de treino

Escolher uma kata não deveria começar pela pergunta “qual é a mais famosa?”, mas sim por “qual habilidade quero praticar agora?”.

Comece pelo tipo de habilidade que você quer praticar

Alguns critérios ajudam bastante:

o problema deve ser pequeno o suficiente para caber em uma sessão;
as regras precisam ser claras;
deve haver possibilidade de evolução incremental;
o exercício deve abrir espaço para testes e refatoração;
a complexidade precisa combinar com o objetivo da prática.

Por exemplo:

FizzBuzz é bom para primeiros ciclos de teste, regras condicionais, nomes simples e refatoração de condicionais.
String Calculator ajuda a praticar TDD incremental, validação, evolução de requisitos e casos de erro.
Roman Numerals trabalha regras de conversão, testes de fronteira e decisões sobre exceções.
Bowling Game é interessante para decompor regras e observar design guiado por testes.
Game of Life adiciona regras de domínio, composição e evolução de uma solução além do caso trivial.

Perceba que o valor não está em montar um catálogo gigante. O valor está em escolher o exercício certo para o tipo de tensão técnica que você quer observar.

Se você nunca praticou TDD, talvez String Calculator seja melhor do que Game of Life. Se você já conhece bem FizzBuzz, talvez a sessão precise de uma restrição nova:

“Não vou deixar condicionais duplicadas.”

Ou:

“Vou fazer ping-pong pairing.”

Ou ainda:

“Vou registrar cada refatoração feita.”

A kata é pequena de propósito. A intenção é usar esse espaço controlado para enxergar melhor suas decisões.

Escolha poucos exercícios e aprofunde

Uma armadilha comum é trocar de kata sempre que surge dificuldade. A pessoa pula de FizzBuzz para Roman Numerals, depois para Bowling Game, depois para Game of Life, sempre buscando novidade. Isso pode ser divertido, mas também pode mascarar o aprendizado.

Repetir o mesmo exercício faz parte do método. A primeira execução revela o problema. As seguintes revelam seus hábitos.

Você pode perceber, por exemplo, que:

sempre escreve testes grandes demais;
demora para renomear algo que já mudou de intenção;
cria abstrações cedo demais;
evita refatorar quando a suíte de testes não dá confiança;
resolve a regra, mas deixa o código difícil de explicar.

Por outro lado, repetir demais sem um objetivo novo vira automatismo. Se você já resolveu FizzBuzz dez vezes da mesma forma, talvez não esteja mais treinando; talvez esteja só fazendo alongamento de dedo no teclado.

Para renovar o aprendizado, varie uma restrição, linguagem, abordagem ou parceria.

Um método prático para conduzir uma kata em 30 a 60 minutos

Uma sessão de kata não precisa ocupar uma tarde inteira. Em muitos casos, 30 a 60 minutos bem conduzidos ensinam mais do que várias horas de tentativa dispersa.

Antes de programar: defina uma intenção e uma restrição

Comece escolhendo um objetivo observável. Algo que você consiga avaliar ao final.

Exemplos:

“Quero escrever testes com nomes que expliquem comportamento.”
“Quero refatorar sem quebrar a suíte.”
“Quero evitar métodos longos.”
“Quero praticar commits pequenos.”
“Quero explicar cada decisão em voz alta durante o pareamento.”
“Quero identificar duplicação antes de criar abstrações.”

Depois, escolha uma restrição produtiva. Restrições não servem para complicar por esporte; servem para aumentar atenção em um aspecto específico.

Por exemplo:

“Ao final, quero conseguir explicar por que cada teste existe e remover duplicações sem quebrar a suíte.”

Essa intenção já cria um critério de qualidade melhor do que “terminar rápido”.

Durante a implementação: use ciclos curtos de feedback

Um fluxo simples para conduzir a sessão é:

entender uma regra;
escrever um teste pequeno;
implementar o mínimo necessário;
refatorar;
revisar a decisão;
repetir.

Esse fluxo combina bem com TDD, mas TDD aqui deve ser visto como ferramenta, não como obrigação religiosa. Ele é útil quando ajuda você a avançar em passos pequenos, receber feedback rápido e proteger refatorações.

Se TDD ainda é um tema novo para você, o artigo Teste Unitário: do zero ao TDD pode servir como aprofundamento antes de uma sessão mais focada nessa técnica.

Alguns cuidados durante a implementação:

Evite escrever todos os testes antes de implementar. Isso pode parecer organizado, mas você perde parte do aprendizado gerado pelos ciclos pequenos.
Evite “TDD de fachada”: implementar tudo primeiro e escrever testes depois apenas para validar o que já foi feito.
Não antecipe a arquitetura inteira só porque você já conhece o exercício.

Esse último ponto é especialmente importante. Em uma kata muito conhecida, dá vontade de começar pelo design “final”. Isso pode economizar tempo, mas reduz o treino de descoberta incremental.

Se o objetivo da sessão é praticar evolução guiada por feedback, atalhos demais atrapalham.

Ao terminar: revise o processo, não só o resultado

Quando todos os testes passam, a sessão ainda não acabou.

Reserve os últimos minutos para responder perguntas como:

Qual decisão deixou o código mais simples?
Onde houve hesitação?
Quais testes foram difíceis de escrever?
Que duplicação apareceu?
Que acoplamento surgiu?
O que ficou mais claro depois da refatoração?
O que eu mudaria na próxima repetição?

Um registro curto já ajuda. Pode ser algo simples:

“Hoje percebi que meus testes começaram descrevendo implementação, não comportamento. Na próxima sessão, vou focar em nomes de testes mais claros.”

Essa observação vale muito. Ela transforma uma execução isolada em continuidade de aprendizado.

Como usar TDD e refatoração sem transformar a kata em ritual

TDD e refatoração combinam muito bem com katas, mas existe uma pegadinha: transformar técnica em coreografia.

O objetivo do TDD não é repetir “red, green, refactor” como se fosse senha secreta de clube. O objetivo é obter feedback, orientar decisões e manter o código evolutivo.

Da mesma forma, refatoração não é “mexer porque ficou feio”. É melhorar a estrutura sem alterar comportamento.

A relação entre testes, design e refatoração pode ser pensada assim:

testes tornam mudanças mais seguras;
refatoração melhora a estrutura preservando comportamento;
ciclos curtos revelam problemas de design cedo;
design melhora quando você presta atenção ao atrito para adicionar novas regras.

Em uma String Calculator, por exemplo, você pode começar com o retorno para entrada vazia. Depois, avançar para um número. Em seguida, dois números. Só então introduzir separadores, múltiplos valores ou regras adicionais. Essa evolução pequena força você a tomar decisões com feedback frequente.

Em FizzBuzz, você pode observar quando condições repetidas começam a incomodar. Talvez a ordem das verificações dificulte adicionar uma nova regra. Talvez nomes como result ou value estejam genéricos demais para explicar intenção. Talvez uma extração de função ajude — ou talvez seja exagero naquele momento.

Aqui entram os trade-offs:

Criar abstrações cedo demais pode deixar um problema simples artificialmente complexo.
Refatorar apenas por estética pode piorar clareza.
Não refatorar nada pode esconder duplicações e decisões frágeis.
Usar TDD pode ajudar muito, mas nem toda sessão precisa começar por TDD.

Uma alternativa válida é fazer uma solução inicial exploratória e, depois, escrever testes para caracterizar o comportamento antes de refatorar. Isso pode ser útil quando seu objetivo é comparar estilos de design ou entender o problema primeiro.

O importante é deixar a intenção explícita.

Aprenda mais com revisão, pair programming e comunidade

Katas ficam mais ricas quando deixam de ser uma prática solitária. Comparar soluções não deveria ser uma disputa para decidir “quem fez melhor”. O objetivo é enxergar decisões, alternativas e custos que passaram despercebidos.

Dois códigos podem resolver Roman Numerals corretamente e, ainda assim, revelar estratégias muito diferentes:

uma solução pode priorizar tabelas de conversão;
outra pode usar decomposição por casas decimais;
uma pode ter testes de fronteira mais claros;
outra pode facilitar melhor a adição de novas regras;
uma pode ser mais simples de ler, mas menos flexível;
outra pode ser mais extensível, mas complexa demais para o problema atual.

Formatos úteis de prática em dupla ou grupo incluem:

driver-navigator: uma pessoa digita, a outra observa direção, riscos e próximos passos; depois elas trocam;
ping-pong pairing: uma pessoa escreve um teste, a outra faz passar, e os papéis alternam;
code review pós-kata: pessoas resolvem individualmente e depois revisam as soluções juntas.

Por exemplo: duas pessoas resolvem Roman Numerals separadamente por 30 minutos. Depois, discutem nomes, testes de limites, estrutura e facilidade para adicionar regras. A conversa provavelmente ensinará mais do que apenas olhar para a própria solução pronta.

Uma retrospectiva curta também ajuda:

O que aprendemos?
Onde discordamos?
Que decisão teve custo escondido?
Que alternativa queremos experimentar na próxima sessão?

O cuidado aqui é evitar que revisão vire defesa de ego. Não é tribunal, ranking nem prova de velocidade. É treino técnico. O código é o material de estudo, não uma extensão da identidade da pessoa autora.

Parear também tem trade-off: o feedback costuma ser mais rico, mas o tempo de teclado individual diminui. Por isso, alternar sessões solo e colaborativas pode atender objetivos diferentes.

Se você quer praticar com outras pessoas, participe da comunidade SCCB e acompanhe encontros, conversas e atividades técnicas.

Evite a repetição mecânica: crie uma rotina de evolução

Uma rotina sustentável é melhor do que um pico de empolgação seguido de abandono. Uma sessão semanal curta, ou duas sessões de 30 minutos, já pode criar continuidade — desde que cada sessão tenha um objetivo.

Um ciclo simples de progressão pode ser:

resolver uma kata conhecida com foco em entendimento;
repeti-la com uma técnica específica;
revisá-la com outra pessoa;
mudar uma restrição ou linguagem;
registrar o que foi transferido para o trabalho real.

Essa última etapa é importante. Katas não substituem projetos reais, mas podem melhorar movimentos que você usa neles.

Por exemplo: depois de praticar testes de borda em Roman Numerals, você pode levar o mesmo cuidado para uma regra de validação em um sistema real. Depois de treinar refatoração em String Calculator, talvez fique mais fácil fazer uma pequena melhoria em código legado com segurança. Depois de praticar explicação em pair programming, talvez sua próxima code review fique mais objetiva.

Ainda assim, mantenha os contextos separados:

katas treinam movimentos técnicos em ambiente controlado;
projetos reais envolvem domínio, integração, manutenção, comunicação, produto e restrições de negócio.

Outro erro comum é medir evolução apenas pelo tempo de execução ou pela quantidade de exercícios concluídos. “Resolvi 20 katas” diz pouco se você não sabe o que mudou na sua forma de pensar e escrever código.

Uma pergunta melhor seria:

“O que eu faço hoje com mais clareza, segurança ou intenção do que fazia antes?”

Uma kata bem praticada não termina quando todos os testes passam. Ela termina quando você consegue sair com uma observação clara para orientar a próxima sessão.

Próximos Passos

Para começar sem complicar:

Escolha uma kata simples, como FizzBuzz ou String Calculator.
Defina uma intenção específica: testes, nomes, refatoração, casos de borda ou comunicação.
Pratique por 30 a 60 minutos.
Reserve os últimos minutos para revisar o processo.
Registre uma observação e uma hipótese para a próxima repetição.
Quando possível, revise a solução com outra pessoa.

Se quiser praticar em comunidade, veja os próximos eventos da SCCB e participe das conversas técnicas.