Como trabalho
Mais de três décadas de experiência deram forma a uma metodologia clara: design orientado ao propósito, arquitetura limpa e qualidade sustentável. São estes os princípios que orientam cada linha de código que escrevo.
Por acordos de confidencialidade não posso compartilhar o código da maioria dmeus projetos em produção. Convido-o, no entanto, a explorar meus repositórios públicos, onde compartilho ferramentas open source, experiências e contributos para a comunidade de desenvolvedores.
Ver no GitHubAntes de escrever uma única linha, defino o que significa sucesso — objetivos de negócio, riscos, usuárioes, métricas — e traduzo-o para linguagem de domínio: conceitos, invariantes, processos, exceções e regras. Em domínios complexos aplico DDD, para que o modelo seja uma ferramenta de comunicação e decisão, e não um diagrama decorativo.
A UX não serve para deixar as coisas bonitas: serve para reduzir carga cognitiva, antecipar erros, orientar decisões e ajudar as pessoas a avançar com confiança. Desenho fluxos, estados, estados vazios, permissões, latências, erros e caminhos felizes com o mesmo rigor de uma API. A experiência tem de ser previsível, acessível e consistente em todos os telas.
A interface constrói-se como um sistema: componentes reutilizáveis, tokens, variantes, estados e composição hierárquica. Com Atomic Design mantenho ordem, escalabilidade e coerência visual e funcional (átomos → moléculas → organismos → templates → páginas). Isto reduz o custo da mudança e evita uma UI à esparguete.
Separar responsabilidades não é dogma: é velocidade sustentável. Defino fronteiras (domínio, aplicação, infraestrutura, apresentação), contratos estáveis e dependências corretas. Quando faz sentido aplico arquitetura hexagonal para desacoplar o núcleo de bases de dados, mensageria, fornecedores externos e frameworks, permitindo que as peças mudem sem reescrever o sistema.
Uso princípios como SOLID e padrões (Repository, Strategy, Fatory, Adapter, Facade, CQRS quando necessário) para gerir a complexidade real: testabilidade, extensão segura, redução de acoplamento e compreensão do código. Os padrões são ferramentas; o objetivo é que o sistema seja legível, previsível e fácil de evoluir.
A segurança não se acrescenta no fim. Trato-a como requisito de arquitetura: autenticação, autorização, isolamento, rastreabilidade, criptografia, gestão de segredos, rate limiting, hardening e validação nas fronteiras. Apoio-me em normas e checklists para não deixar lacunas — por exemplo, verificações ao estilo ASVS e a abordagem Secure-by-Design da OWASP.
Não optimizo por intuição: meço, analiso o desempenho e volto a medir. Desenho a pensar em desempenho extremo quando é preciso: caching, filas e processamento assíncrono, paginação a sério, backpressure, uso correto de índices, minimização de payloads e estratégias de consistência. O objetivo: experiência fluida, estabilidade e custo controlado sob carga.
No frontend e no backend modelo o estado de forma explícita, sem o esconder em efeitos secundários. Distingo estado local de estado de aplicação, defino fontes de verdade e uso Facades para isolar frameworks e impedir que a UI conheça detalhes internos. Resultado: menos bugs fantasma, mais previsibilidade, refatorings mais baratos.
Sobre qualidade não se negoceia: automatiza-se. Aplico a pirâmide de testes (unitários, integração, E2E quando tem valor), contratos estáveis, linters, CI e uma definition of done a sério. Além disso incluo observabilidade: logs úteis, métricas, traces, correlação e alertas. E documento o mínimo essencial, mas sempre accionável e fácil de manter: ADRs, diagramas, READMEs operacionais, guias de deployment e runbooks.
Construo na vertical: peças pequenas e completas que chegam a produção com confiança. Trabalho com cadência, feedback e adaptação, alinhado com os princípios de Scrum: iteração, inspeção e adaptação para controlar o risco e maximizar o valor. A arquitetura acompanha o roadmap e evolui sem bloquear a equipe.
Notas sobre software empresarial, agentes de IA e a prática de engenharia por trás.
1 min de leitura
A inspeção robótica coleta mais dados, e mais precisos, do que nunca. Mas coletá-los é só metade do problema. A outra metade é transformá-los em algo que sustente uma decisão.
2 min de leitura
Não costumo recomendar software. Este caso é dos especiais: resolve um problema que vejo generalizado nas PMEs e também, o que é mais grave, em empresas realmente grandes.
3 min de leitura
«A IA vai tomar nosso emprego.» «A IA é consciente.» «A AGI já chegou.» Sério? Depois de 30 anos em engenharia de software, o hype está fugindo do controle.
Gostava de conhecer o seu projeto e explorar consigo como o posso ajudar a concretizá-lo com a qualidade e o profissionalismo que merece.
Fale comigo
