Bebo Porque É Líquido Se Fosse Sólido Comê-lo-ia

Uma filosofia prática para lidar com o imprevisto

A ideia central é simples: você se adapta ao que está à sua frente. Se algo é líquido, você bebe. Se for sólido, você come. Não adianta reclamar que o formato não combina com a situação. A maioria das pessoas passa anos frustradas porque a realidade não obedece aos seus planos originais. O conceito de bebo porque é líquido se fosse sólido comê-lo-ia propõe exatamente o oposto. Aceita o que é, trata conforme a natureza da coisa, e segue em frente. Eu desenvolvi isso na prática depois de meses lidando com deploy de aplicação em produção. A aplicação era um serviço Node.js que dependia de uma variável de ambiente que às vezes vinha como string, às vezes como JSON parseado. No começo eu criava camadas de validação, depois mais camadas, depois wrappers. Nada resolvía. O problema era que eu estava tentando impor uma forma ao dado em vez de simplesmente deixar o código lidar com ambas as situações.

Como aplicar bebo porque é líquido se fosse sólido comê-lo-ia no dia a dia

O método tem três passos, na verdade. O primeiro é identificar a natureza do obstáculo. É algo concreto que pode ser manipulado diretamente? Trate como tal. É fluido, muda de forma, não se encaixa nas suas expectativas? Adapta-se. O segundo passo é eliminar a resistência emocional. Esse é o mais difícil e onde a maioria trava. O terceiro é agir sem esperar condições ideais. No exemplo do deploy, a solução foi criar uma função utilitária que aceitava tanto string quanto objeto e retornava o valor correto. Em vez de 12 linhas de try-catch aninhado, ficaram quatro. O tempo de resolução caiu de duas horas para cerca de oito minutos, dependendo da complexidade do campo. Você pode aplicar isso em outras áreas. Lidando com cliente que pede mudança de escopo no meio do projeto. Se ele fala claro e direto, cumpre. Se é vago e contraditório, documenta por escrito e pede confirmação. Não tenta adivinhar. Não se frustra. O formato da comunicação dita a resposta.

O lado prático que ninguém conta

A primeira coisa que preciso deixar claro é que esse conceito não funciona em todos os cenários. Se você está lidando com algo perigoso — um líquido corrosivo, um sólido tóxico — a regra se aplica literalmente, mas a conclusão é diferente. Você não bebe e não come. Você descarta. O princípio original pressupõe que o objeto é adequado ao consumo, apenas precisa ser tratado conforme sua forma. Um erro comum é aplicar essa filosofia de forma cega. Eu já vi desenvolvedores ignorarem validação de input porque "o usuário vai enviar o que for, e a gente trata depois". Isso não é adaptação. É negligência com desculpa filosófica. A diferença é sutil mas importante. Adaptação significa entender a natureza do dado e processá-lo corretamente. Negligência significa não se importar com o formato e torcer para não dar erro. Outra nuance que beginners frequentemente perdem: a filosofia não elimina a necessidade de planejamento. Pelo contrário. Quanto mais você entende a variabilidade do que vai encontrar, melhor consegue se preparar. Eu gasto cerca de 20 por cento do tempo de projeto mapeando os diferentes formatos possíveis de entrada. Isso reduz o tempo de debugging em produção em cerca de 60 por cento, comparado a quem não faz esse exercício.

Quando a abordagem falha

Existem situações onde não dá para simplesmente adaptar-se. Se o líquido é veneno, não bebe. Se o sólido é pedra, não come. O princípio só se aplica quando o objeto é passível de utilização, apenas precisa ser tratado de forma diferente do esperado. Tentar forçar essa lógica em contextos inadequados leva a decisões ruins. No desenvolvimento de software, um exemplo claro é quando você recebe um arquivo corrompido. Não adianta tentar ler como JSON válido, nem como CSV, nem como XML. O arquivo está danificado. A única ação sensata é notificar o usuário e pedir um novo envio. Adaptação tem limite. Conheça esses limites. Uma alternativa útil em casos onde a adaptação não funciona é criar um sistema de fallback em camadas. Primeiro tenta o formato esperado. Se falha, tenta o próximo. Se tudo falhar, registra o erro e notifica. Esse padrão reduz drasticamente crashes em produção e geralmente melhora a experiência do usuário final, mesmo quando algo dá errado.

A aplicação prática desse princípio mudou completamente minha abordagem de trabalho. Hoje, quando encontro um problema novo, a primeira pergunta que faço é: qual é a natureza disso? É fluido ou sólido? A resposta determina a ação. E eu para de gastar energia tentando fazer o problema se encaixar no que eu planejo, e começo a trabalhar com o que realmente tenho na frente.