Purismo e Pragmatismo
5 min · 05 Out, 2025
Encantado por conceitos como SOLID, DDD, Design Patterns caímos facilmente na tentação de encaixar o problema dentro da solução, quando na verdade deve ser o contrário: a solução precisa se dobrar ao problema.
Antes de tudo, algumas recomendações de leitura
Antes de escrever esta postagem, mergulhei em diversas leituras sobre desenvolvimento. Foram esses livros e autores que me inspiraram a refletir e escrever sobre o tema de hoje. Se você quiser se aprofundar, recomendo:
- Programador Pragmático – Andrew Hunt e David Thomas
- Arquitetura Limpa – Robert C. Martin
- Código Limpo – Robert C. Martin
- Refatoração – Kent Beck e Martin Fowler
Cada um deles trouxe insights sobre quando seguir à risca os princípios e quando adaptar o código às necessidades reais do projeto.
Já se sentiu travado ao escrever um código novo?
Bom, eu já, e mais vezes do que gostaria de admitir. A pressão é real: queremos que o código saia perfeito já na primeira tentativa. Usar aquele Design Pattern bonito, escrever algo limpo, elegante, de fácil manutenção… e, de quebra, entregar dentro da sprint (ninguém falou que seria fácil).
O problema é que a leitura dos grandes livros como Clean Code, Refactoring, Arquitetura Limpa e outros pode nos colocar em uma armadilha: tentar aplicar todos os princípios logo de cara. Parece nobre, mas na prática isso costuma virar receita para frustração.
Purismo demais paralisa. O código inicial ainda é incerto, não sabemos como ele vai evoluir. Forçar essa perfeição cedo demais pode matar a produtividade.
O Purismo em sua forma absoluta
Encantado por conceitos como SOLID, DDD, Design Patterns caímos facilmente na tentação de encaixar o problema dentro da solução, quando na verdade deve ser o contrário: a solução precisa se dobrar ao problema. Isso fica ainda mais evidente no código legado. Aí o jogo é mais duro: sistemas antigos carregam cicatrizes, decisões arquiteturais duvidosas e gambiarras históricas. O dev purista olha para esse cenário e sente o chamado heroico: "vou salvar esse sistema, custe o que custar!". Mas a verdade é dura: na ânsia de ser herói, ele pode virar vilão. Ao tentar "consertar o mundo", acaba travando toda uma linha de produção.
Você não precisa ser perfeito, basta ser pragmático
No mundo ideal, teríamos todo o tempo do planeta para lapidar software como um artesão lapida sua obra-prima. Mas a vida real é menos romântica: precisamos entregar novas funcionalidades, corrigir bugs e ainda lidar com aquele backlog infinito. Tempo para polir até brilhar? Quase nunca.
Ser pragmático é pesar contexto e momento. Se o sistema é novo e ainda incerto, vale investir em uma base organizada e flexível, mas sem exageros: jogar patterns e camadas demais pode transformar o código em um labirinto desnecessário.
Se o sistema é antigo, a lógica é outra: esqueça a reforma total. O que dá resultado é a melhoria incremental, mexeu numa parte do código? Aproveita e deixa um pouco melhor do que encontrou, sem comprometer o cronograma. Pequenos passos, grande evolução.
Comece pequeno
Sim, comece pequeno. Não tente abraçar mais do que suas mãos alcançam. Apoie-se na sua equipe, discuta ideias, e sejam pragmáticos quando for preciso. Mas não jogue o purismo fora: um padrão bem aplicado, uma arquitetura pensada no momento certo podem transformar o sistema.
Se for necessário, comece até com algo simples, desde que seja melhorável de verdade. Nada daquele clássico "depois eu melhoro", porque sabemos bem: esse "depois" nunca chega.
Pragmatismo não é preguiça. É construir o hoje deixando espaço para que o amanhã seja melhor. É adiar certas decisões, sim, mas com propósito, para que, quando chegar a hora, você as tome com mais clareza e propriedade.
Em resumo
Purismo é direção e pragmatismo é movimento. Se travamos por tentar um código perfeito, podemos usar do pragmatismo para não se perder nessa busca da perfeição. Se estamos regendo o desenvolvimento sem uma direção podemos dosar um pouco do purismo para acabar não correndo o risco de construir castelos de areia. O desafio está no equilíbrio. É saber quando aplicar aquele princípio, quando refatorar, quando segurar a ansiedade de "consertar tudo agora" e simplesmente entregar valor. É transformar teoria em prática, mas sem se tornar refém dela.
No fim, desenvolver software não é sobre escolher entre ser purista ou pragmático. É sobre ser consciente.
A perfeição não existe, mas a evolução contínua sempre está ao nosso alcance.