A «Depuração do Patinho de Borracha», ou como corrigir problemas falando com um brinquedo

Estresse, cansaço, problemas externos... todo programador precisa lidar com erros ou falhas em seu código, e há razões de sobra para que o debugging se torne um pesadelo. No entanto, existe uma técnica muito curiosa que remonta ao final dos anos 90 e envolve um patinho de borracha. Qual é a ideia exata? Que o programador seja obrigado a explicar ao pato, linha por linha, seu código, e por meio desse processo de desconstrução, encontrar a solução.

A origem da técnica

A história de hoje remonta a 1999, ano em que Andrew Hunt e David Thomas escreveram The Pragmatic Programmer, um livro para programadores que rapidamente se tornou texto universitário. Com a ajuda de contos curtos e outros truques, Hunt e Thomas entregam ao programador em potencial ferramentas destinadas a otimizar seu processo de desenvolvimento, começando pela necessidade de ser um "early adopter", adaptar-se em alta velocidade, nunca perder o pensamento crítico nem o realismo, e funcionar como um curinga.

Infelizmente, não é um título totalmente acessível, digamos. Sua última edição não custa menos de 45 euros (a menos que busquemos sua versão digital), e se a memória não me falha, jamais foi traduzido para o espanhol. Mas há um pequeno detalhe nesse livro que se destacou acima dos demais em tempo recorde, e sobre o qual muitos programadores juram.

Como funciona

A chave é colocar um patinho de borracha na mesa de trabalho. Quando o programador não consegue encontrar um erro ou fica "travado" em certo ponto, o pato se transforma em uma espécie de ouvinte e estudante passivo. O desenvolvedor passa a explicar o problema passo a passo e, por meio dessa mesma explicação, encontra a solução. Isso é bastante comum entre colegas e companheiros de trabalho (ou programadores falando com seus animais de estimação), mas o pato carrega duas vantagens importantes: não interrompe e evita que incomodemos outra pessoa.

Por que isso funciona

O mais valioso é que obriga o programador a começar do início e, ao avançar, ele apenas "reanalisa" o código em sua mente. Essa visualização atualizada do projeto geralmente traz clareza suficiente para detectar o problema, a ponto de que, às vezes, basta descrever um ou dois detalhes do inconveniente. Parece brincadeira, mas não é. Enquanto algumas tarefas exigem foco total, outras precisam ser "desmontadas" de algum modo, mesmo quando a única plateia é um patinho de borracha.