Tema 04 Experiência profissional · Regras de negócio · Testes · Produção
Engenharia de backend e qualidade
Tive contribuição central no desenvolvimento de APIs Rails, na modelagem de dados e nas regras de negócio, com testes, revisões e refatorações. Minha atuação também alcançou interfaces, mobile e produção: conectei o trabalho no backend ao comportamento do sistema que a equipe precisava manter e evoluir.
Contexto
Atuei no desenvolvimento e na manutenção de APIs, com contribuição central em backend e participação em outras etapas do ciclo de desenvolvimento.
O recorte aqui é a qualidade durante a evolução: entender uma regra, proteger seu comportamento e investigar o que acontece em operação.
Problema
Uma regra pode estar distribuída entre modelos, serviços e persistência. Mudar apenas o ponto mais visível pode deixar inconsistências em outros caminhos.
Um teste que apenas repete a implementação pode continuar passando mesmo quando a experiência de uso está errada.
Minha atuação
Desenvolvi e evoluí APIs REST em Ruby on Rails, modelei dados relacionais e implementei regras de negócio com testes automatizados. Minha contribuição foi central na API, dentro de um trabalho de equipe.
Participei de revisões, refatorações e definição de padrões técnicos, além da manutenção de interfaces legadas e da modernização para React.
Também contribuí em mobile, DevOps e acompanhamento em produção com observabilidade e rastreamento de erros, mantendo comunicação direta com clientes internacionais em inglês.
Critérios técnicos
Combinei implementação, revisão de código e refatoração na evolução do backend. Tratei validação, integridade dos dados e testes de comportamento como parte da funcionalidade, em vez de etapas desconectadas da entrega.
Esse trabalho orienta meus critérios atuais: localizar cada regra em uma responsabilidade compreensível, separar evidência de hipótese na investigação e proteger a correção com um teste de regressão.
Alternativas e trade-offs
Critérios gerais e análise técnica escritos para este portfólio.
- Testes muito acoplados à estrutura interna tornam refatorações caras. Testes amplos demais podem dificultar localizar a causa de uma falha.
- Refatorar e mudar comportamento ao mesmo tempo aumenta a superfície de revisão. Prefiro separar essas intenções quando isso facilita verificar a mudança.
Aplicação e exemplos
Exemplo didático: uma lista de tarefas aceita a conclusão de um item apenas quando seus campos obrigatórios são válidos.
Regra observável
Descrever o que a pessoa pode fazer e qual resposta recebe quando um dado está ausente.
Teste de comportamento
Verificar aceitação e rejeição pela interface pública da regra, sem depender de nomes de métodos auxiliares.
Revisão focada
Conferir validação, persistência e resposta de erro, procurando caminhos em que a regra possa ser ignorada.
Diagnóstico em operação
Usar evidências de erro e contexto suficiente para reproduzir o problema, sem registrar dados sensíveis desnecessários.
O que esta experiência demonstra
Minha participação conectou APIs, regras de negócio, testes e interfaces durante a evolução de sistemas em produção. Contribuí tanto com funcionalidades e correções quanto com revisão, refatoração e redução de débito técnico.
O exemplo representa validação, teste e revisão com dados fictícios. Não reproduz um fluxo de negócio profissional.