image

Access unlimited bootcamps and 650+ courses forever

75
%OFF
Article image
Igor Silva
Igor Silva18/10/2025 13:16
Share

Rubber Duck Debugging: O poder da conversa com um pato de borracha

    Se você programa há algum tempo, já deve ter passado por isso: o código não funciona, o erro não faz sentido e o desespero começa a bater. Então, do nada, você explica o problema em voz alta e "bam!" percebe o erro sozinho. Parabéns, você acabou de praticar Rubber Duck Debugging, o famoso “debug com o pato de borracha”.

    O que é Rubber Duck Debugging?

    O termo vem de uma história popular entre programadores. Conta-se que um desenvolvedor carregava um pato de borracha em sua mesa e explicava linha por linha do código para ele quando algo dava errado. O simples ato de explicar o problema em voz alta o ajudava a enxergar o bug com clareza.

    Parece bobo, mas funciona! Quando você fala o código em voz alta (mesmo que seja para um pato), seu cérebro muda o foco, em vez de apenas ver o problema, você passa a entendê-lo de verdade.

    Por que isso funciona?

    O Rubber Duck Debugging é eficaz porque força você a:

    • Organizar o raciocínio: ao explicar, você precisa colocar em ordem o que o código faz.
    • Identificar inconsistências: ao verbalizar, percebe trechos que “não fazem tanto sentido assim”.
    • Reduzir distrações: o foco muda do erro em si para o funcionamento lógico do código.

    Em resumo você sai do modo “caçador de bugs” e entra no modo “contador de histórias do código”.

    Exemplo prático

    Imagine que seu código não imprime o resultado esperado:

    public class Main {
      public static void main(String[] args) {
          int a = 5;
          int b = 0;
          int resultado = dividir(a, b);
          System.out.println("Resultado: " + resultado);
      }
    
      public static int dividir(int x, int y) {
          return x / y;
      }
    }
    

    Você está vendo uma exceção, mas não entende o motivo. Agora, pegue seu pato de borracha (ou qualquer coisa que sirva de ouvinte) e diga:

    “Ok, pato, estou dividindo 5 por 0... espera... dividir por zero?!”

    E pronto. O erro estava bem na sua frente o tempo todo, você só precisava explicar pra alguém (ou pra algo).

    Moral da história

    Você não precisa de um debugger sofisticado o tempo todo. Às vezes, tudo o que precisa é um momento de diálogo honesto com seu pato imaginário.

    Conclusão

    O Rubber Duck Debugging é simples, divertido e incrivelmente útil, da próxima vez que travar em um problema, não hesite, explique seu código para um pato, um copo, um boneco ou até para o ventilador, porque, no fim das contas, o melhor ouvinte de um programador é aquele que nunca interrompe.

    Share
    Recommended for you
    Bradesco - GenAI & Dados
    GitHub Copilot - Código na Prática
    CI&T - Backend com Java & AWS
    Comments (2)
    Igor Silva
    Igor Silva - 22/10/2025 18:27

    O maior desafio para um desenvolvedor ao trabalhar com o padrão MVC (Model-View-Controller) não está em compreender sua teoria, mas em manter a disciplina arquitetural na prática, especialmente à medida que o projeto cresce.

    No início, tudo parece simples:

    • Model: representa os dados e a lógica de negócio.
    • View: exibe as informações ao usuário.
    • Controller: recebe as ações e coordena o fluxo entre Model e View.


    Com o tempo, porém, as fronteiras entre essas camadas tendem a se confundir.

    Na pressa de “fazer funcionar”, o desenvolvedor pode acabar inserindo lógica de negócio no Controller ou misturando regras de exibição na View.

    Esse tipo de desvio gera acoplamento, e o MVC deixa de cumprir seu propósito.

    O código até “funciona”, mas se transforma em uma armadilha técnica, difícil de evoluir e refatorar.

    Quando a separação de responsabilidades é negligenciada, o projeto perde sua estrutura.

    As consequências incluem:

    • Aumento do acoplamento.
    • Dificuldade de manutenção.
    • Baixa testabilidade.
    • Menor reutilização.
    • Efeito cascata.


    Para manter o baixo acoplamento e garantir a saúde do projeto ao longo do tempo, é essencial respeitar a função de cada camada e adotar práticas que reforcem a independência entre elas.

    Algumas abordagens fundamentais incluem:

    • Definir responsabilidades claras.
    • Evitar dependências diretas.
    • Aplicar o princípio da inversão de dependência.
    • Automatizar testes e revisões de código.


    Em geral, a separação de responsabilidades e o baixo acoplamento não são apenas boas práticas de organização, mas investimentos na longevidade e na qualidade do software.

    São esses princípios que garantem que o projeto permaneça escalável, legível e sustentável.

    DIO Community
    DIO Community - 20/10/2025 09:04

    Excelente, Igor! Que artigo incrível e super divertido sobre Rubber Duck Debugging! É fascinante ver como você aborda o tema, mostrando que a solução para um bug complexo muitas vezes não está na ferramenta, mas no processo mental de verbalizar o problema.

    Você demonstrou que o "debug com o pato de borracha" é eficaz porque força você a organizar o raciocínio, identificar inconsistências e reduzir distrações. Sua análise de que você sai do modo “caçador de bugs” e entra no modo “contador de histórias do código” é um insight valioso para a comunidade.

    Qual você diria que é o maior desafio para um desenvolvedor ao trabalhar com um projeto que usa o padrão MVC, em termos de manter a separação de responsabilidades e de evitar o acoplamento entre as três camadas, em vez de apenas focar em fazer a aplicação funcionar?