Como otimizar gastos sem comprometer performance em provedores cloud

Migrar para a nuvem trouxe enormes benefícios para empresas de todos os tamanhos. Escalabilidade, flexibilidade e velocidade de entrega são pontos fortes que transformaram a forma como arquitetamos sistemas. No entanto, junto com essas vantagens veio um desafio que se tornou central: como controlar e otimizar custos sem perder performance.

O dilema da nuvem

É comum que equipes iniciem projetos com entusiasmo, provisionem recursos generosos e, em pouco tempo, percebam que a fatura mensal está muito acima do esperado. O problema não é apenas financeiro, mas estratégico. Gastar além do necessário pode comprometer investimentos em inovação e até mesmo a sustentabilidade do negócio.

Estratégias para otimização

Existem práticas que ajudam a manter os custos sob controle:

• Dimensionar corretamente os recursos, evitando instâncias superdimensionadas.
• Adotar políticas de desligamento automático para ambientes de teste fora do horário comercial.
• Usar ferramentas de monitoramento de custos oferecidas pelos próprios provedores.
• Revisar periodicamente contratos e planos, aproveitando descontos por uso reservado ou instâncias spot.

Comparativo dos principais provedores

Cada provedor de nuvem tem suas particularidades. A tabela abaixo mostra uma visão geral dos mais populares:

Provedor	Pontos fortes	Desafios	Ferramentas de custo
AWS	Ampla gama de serviços, maturidade e ecossistema robusto	Complexidade na gestão e curva de aprendizado	AWS Cost Explorer, Trusted Advisor
Azure	Integração nativa com produtos Microsoft, forte presença corporativa	Estrutura de preços pode ser confusa	Azure Cost Management, Advisor
Google Cloud	Foco em dados e machine learning, preços competitivos	Menor variedade em alguns serviços	Cloud Billing, Recommender
Oracle Cloud	Forte em bancos de dados e workloads críticos	Ecossistema menor	Cost Analysis, Budget Tools

Qual escolher?

Recomendar o serviço de menor custo sem conhecer o projeto seria superficial. O melhor provedor depende de fatores específicos. Para ajudar na escolha, aqui estão algumas perguntas que você deve responder antes de decidir:

1) Qual é o perfil da aplicação? É intensivo em dados, processamento ou armazenamento?

2) Qual é o nível de integração necessário com ferramentas já utilizadas pela empresa?

3) Há requisitos de compliance ou regulamentações específicas que precisam ser atendidas?

4) O projeto exige escalabilidade global ou foco em uma região específica?

5) Qual é a previsão de crescimento da aplicação nos próximos dois anos?

6) O time já possui experiência com algum provedor de nuvem?

7) Qual é a tolerância a riscos de lock-in, ou seja, dependência de um único fornecedor?

Responder a essas perguntas ajuda a alinhar a escolha do provedor com os objetivos do negócio e evita decisões baseadas apenas em preço.

Considerações finais

Gerenciar custos em cloud é uma tarefa contínua que exige disciplina e visão estratégica. Mais do que escolher o provedor mais barato, é preciso entender o contexto do projeto e equilibrar custo, performance e flexibilidade. A nuvem é uma ferramenta poderosa, mas só entrega seu verdadeiro valor quando usada com consciência e planejamento.

Feito!

Entendendo Serverless Computing

Nos últimos anos, o conceito de serverless computing deixou de ser apenas uma tendência e passou a fazer parte do cotidiano de muitas equipes de engenharia de software. A ideia de executar código sem precisar se preocupar com servidores físicos ou virtuais mudou a forma como pensamos em arquitetura e escalabilidade.

O que é Serverless?

Serverless não significa ausência de servidores. Significa que o desenvolvedor não precisa gerenciar diretamente a infraestrutura. O provedor de nuvem cuida de toda a parte operacional, como escalabilidade, disponibilidade e manutenção. O engenheiro de software foca apenas na lógica da aplicação, escrevendo funções que são executadas sob demanda.

Vantagens

A principal vantagem é a simplicidade. Você escreve o código e a nuvem se encarrega de rodá-lo quando necessário. Isso reduz custos, já que você paga apenas pelo tempo de execução. Além disso, a escalabilidade é automática. Se sua aplicação recebe mil requisições em um minuto, o provedor ajusta os recursos sem que você precise intervir. Outro benefício é a velocidade de entrega. Equipes conseguem lançar novas funcionalidades rapidamente sem se preocupar com provisionamento de servidores.

Limitações

Nem tudo é perfeito. Serverless pode trazer desafios de latência, especialmente em funções que ficam inativas por longos períodos e precisam ser inicializadas novamente. Também há limitações em relação ao tempo máximo de execução de uma função, o que pode ser um problema para processos mais pesados. Outro ponto é a dependência do provedor de nuvem, que pode dificultar a portabilidade entre diferentes plataformas.

Exemplos práticos

Um caso comum é o uso de funções serverless para processar imagens enviadas por usuários. Assim que a imagem chega, uma função é disparada para redimensionar ou aplicar filtros e depois salvar o resultado em um bucket de armazenamento. Outro exemplo é o processamento de eventos em tempo real, como notificações de pagamento ou mensagens em um chat. Funções serverless entram em ação apenas quando o evento ocorre, garantindo eficiência e economia.

Considerações finais

Serverless computing representa uma mudança de paradigma. Ele simplifica a vida do engenheiro de software, permitindo que o foco esteja na lógica de negócio e não na infraestrutura. Ao mesmo tempo, exige atenção às limitações e ao planejamento arquitetural para evitar surpresas. Quando bem aplicado, serverless é uma poderosa ferramenta para construir sistemas modernos, escaláveis e econômicos.

Feito!

Habilidades mais valorizadas e como se preparar para o futuro na carreira em DevOps e Infraestrutura

A área de DevOps e infraestrutura deixou de ser apenas suporte técnico e se tornou estratégica para empresas que buscam inovação e velocidade. Hoje, engenheiros/arquitetos de software que atuam nesse campo são responsáveis por garantir que sistemas complexos funcionem de forma confiável, escalável e segura. Mas quais são as habilidades mais valorizadas e como se preparar para o futuro dessa carreira?

O papel do engenheiro de DevOps e infraestrutura

O engenheiro de DevOps é o elo entre desenvolvimento e operações. Ele cria pipelines de integração e entrega contínua, automatiza processos e garante que aplicações possam ser implantadas com rapidez e segurança. Já o profissional de infraestrutura desenha e mantém ambientes que suportam essas aplicações, seja em nuvem, on-premise ou em arquiteturas híbridas.

Habilidades técnicas essenciais

Para quem deseja se destacar, algumas competências são fundamentais. Conhecimento em cloud computing é indispensável, já que grande parte das empresas migrou para AWS, Azure ou Google Cloud.

Containers e orquestração com Kubernetes se tornaram padrão para aplicações modernas. Infraestrutura como Código com ferramentas como Terraform e Ansible é cada vez mais exigida. Além disso, dominar práticas de observabilidade e monitoramento garante que sistemas sejam confiáveis e fáceis de manter.

Habilidades humanas igualmente importantes

Não basta apenas saber configurar servidores ou escrever scripts. A carreira em DevOps exige colaboração, comunicação clara e capacidade de trabalhar em equipes multidisciplinares. O engenheiro/arquiteto de software precisa entender as necessidades do negócio e traduzir isso em soluções técnicas. Adaptabilidade e aprendizado contínuo também são cruciais, já que novas ferramentas e práticas surgem constantemente.

Como se preparar para o futuro

O caminho para se tornar um profissional competitivo envolve prática e estudo. Criar projetos pessoais em nuvem, participar de comunidades técnicas e contribuir para projetos open source são formas de ganhar experiência real. Certificações em cloud e Kubernetes podem abrir portas, mas o mais importante é demonstrar capacidade de resolver problemas de forma prática.

Considerações finais

A carreira em DevOps e infraestrutura é desafiadora e recompensadora. Ela exige equilíbrio entre habilidades técnicas e humanas, além de uma mentalidade voltada para automação e colaboração. O futuro pertence aos profissionais que conseguem unir conhecimento profundo em tecnologia com visão estratégica de negócio. Para quem está disposto a aprender e se adaptar, as oportunidades são vastas e promissoras.

Feito!

Impacto na infraestrutura e aplicações distribuídas

Nos últimos anos, a forma como lidamos com dados mudou radicalmente. A quantidade de informações geradas por dispositivos conectados cresce em ritmo acelerado e enviar tudo para a nuvem já não é suficiente. É nesse cenário que o Edge Computing ganha relevância, trazendo processamento e inteligência para mais perto da origem dos dados.

O que é Edge Computing

Edge Computing é a prática de executar processamento e análise de dados em dispositivos próximos à fonte, como sensores, gateways ou servidores locais. Em vez de depender exclusivamente da nuvem, parte da lógica acontece na borda da rede, reduzindo latência e aumentando eficiência.

Por que isso importa

Imagine um carro autônomo que precisa tomar decisões em milissegundos. Se cada comando dependesse de uma ida e volta até a nuvem, o risco seria enorme. Com Edge Computing, o veículo processa dados localmente e só envia informações relevantes para a nuvem. Esse modelo garante respostas rápidas e ainda mantém a centralização necessária para aprendizado e evolução dos sistemas.

Impacto na infraestrutura

A infraestrutura passa a ser híbrida. A nuvem continua essencial para armazenamento e análise em larga escala, mas o edge adiciona uma camada de proximidade. Isso exige arquiteturas distribuídas, com capacidade de sincronizar dados entre borda e nuvem, além de ferramentas de observabilidade que permitam acompanhar ambientes mais complexos.

Aplicações práticas

Indústria: sensores em fábricas analisam dados em tempo real para prever falhas em máquinas.

Saúde: dispositivos médicos monitoram pacientes e processam sinais vitais localmente, enviando alertas imediatos.

Varejo: câmeras inteligentes identificam padrões de comportamento de clientes sem depender de processamento remoto.

Telecomunicações: redes 5G utilizam edge para reduzir latência em aplicações críticas.

Desafios

Edge Computing traz benefícios, mas também desafios. É preciso lidar com segurança em dispositivos distribuídos, garantir atualizações consistentes e manter observabilidade em ambientes fragmentados. Além disso, arquitetos e engenheiros precisam pensar em estratégias de sincronização e consistência de dados.

Considerações finais

Edge Computing não substitui a nuvem, mas complementa. Ele representa uma evolução natural da infraestrutura, permitindo que aplicações distribuídas sejam mais rápidas, seguras e inteligentes. Para engenheiros de software, o desafio está em desenhar soluções que aproveitem o melhor dos dois mundos, equilibrando processamento local e centralizado.

Feito!

Entendendo Observabilidade vs Monitoramento

No mundo da engenharia de software, termos como monitoramento e observabilidade são frequentemente usados como se fossem sinônimos. No entanto, eles representam conceitos distintos e complementares. Entender essa diferença é fundamental para construir sistemas resilientes e confiáveis.

O que é monitoramento

Monitoramento é a prática de coletar métricas e indicadores previamente definidos para acompanhar o estado de um sistema. É como ter um painel de controle que mostra CPU, memória, latência e disponibilidade. Ele responde à pergunta: “o sistema está funcionando dentro dos parâmetros esperados?”.

O que é observabilidade

Observabilidade vai além. É a capacidade de entender o comportamento interno de um sistema a partir dos dados que ele gera. Isso inclui métricas, logs e traces. Observabilidade responde a uma pergunta mais complexa: "por que o sistema está se comportando dessa forma?". É sobre ter visibilidade suficiente para investigar problemas que não foram previstos.

Diferença prática

Enquanto o monitoramento é reativo e baseado em alertas, a observabilidade é investigativa e exploratória. Monitoramento ajuda a detectar que algo está errado. Observabilidade ajuda a descobrir a causa raiz e entender o contexto.

Aplicando no dia a dia

Imagine um serviço de pagamentos que começa a apresentar falhas intermitentes. O monitoramento pode indicar que a taxa de erros aumentou. A observabilidade, por sua vez, permite correlacionar logs de autenticação, métricas de banco de dados e traces de chamadas entre microserviços para identificar que o problema está em uma dependência externa.

Ferramentas que apoiam essa prática

Hoje temos um ecossistema rico que facilita a adoção de observabilidade. Prometheus coleta métricas, Grafana cria dashboards interativos, Loki organiza logs e Jaeger ou Grafana Tempo permitem rastrear requisições ponta a ponta. Quando integrados, esses recursos oferecem uma visão completa do sistema.

Considerações finais

Monitoramento e observabilidade não competem, eles se complementam. Monitoramento garante que você saiba quando algo está errado. Observabilidade garante que você consiga entender o motivo. Em um ambiente moderno de DevOps e microsserviços, adotar ambos é essencial para manter sistemas confiáveis e preparados para lidar com a complexidade crescente.

Feito!

Entendendo Infraestrutura como Código (IaC)

A infraestrutura de TI deixou de ser apenas servidores físicos e configurações manuais. Hoje, arquitetos e engenheiros de software trabalham com ambientes altamente dinâmicos, distribuídos e escaláveis. Nesse cenário, Infraestrutura como Código (IaC) se tornou essencial para garantir consistência, automação e velocidade na entrega de soluções.

O que é Infraestrutura como Código

Infraestrutura como Código é a prática de definir e gerenciar recursos de TI por meio de arquivos de configuração versionados, em vez de processos manuais. Isso significa que servidores, redes, bancos de dados e permissões podem ser descritos em código, revisados em pull requests e aplicados automaticamente.

Benefícios da IaC

Consistência: ambientes de desenvolvimento, homologação e produção são idênticos.

Velocidade: provisionamento automatizado reduz tempo de entrega.

Escalabilidade: fácil replicação de ambientes.

Auditoria: histórico de mudanças versionado em Git.

Redução de erros humanos: menos configurações manuais.

Terraform: provisionamento de recursos

O Terraform é uma ferramenta declarativa que permite criar e gerenciar recursos em múltiplos provedores de nuvem.

Exemplo prático: provisionar uma instância EC2 na AWS com apenas algumas linhas de código.

Uso no dia a dia: definir VPCs, subnets, balanceadores e bancos de dados de forma repetível.

Diferencial: suporte multi-cloud, permitindo gerenciar AWS, Azure e GCP em um único fluxo.

Ansible: configuração e automação

O Ansible é voltado para configuração e gerenciamento de servidores.

Exemplo prático: instalar PostgreSQL em uma VM provisionada pelo Terraform.

Uso no dia a dia: aplicar patches, configurar serviços e gerenciar permissões.

Diferencial: simplicidade, já que não exige agentes instalados nos servidores.

Integração Terraform + Ansible

O fluxo ideal combina as duas ferramentas:

Terraform provisiona a infraestrutura (máquinas, redes, storage).

Ansible aplica configurações e instala softwares necessários.

Pipeline CI/CD garante que tudo seja executado automaticamente em cada mudança.

Caso prático: ambiente de microserviços

Imagine uma empresa que precisa subir um cluster Kubernetes para rodar microserviços:

Terraform cria o cluster e os recursos de rede.

Ansible instala pacotes, configura monitoramento e aplica políticas de segurança.

O resultado é um ambiente pronto para receber aplicações em minutos, com consistência e rastreabilidade.

Considerações finais

Infraestrutura como Código não é apenas uma tendência, é uma prática consolidada que redefine como engenheiros de software trabalham. Ao combinar Terraform para provisionamento e Ansible para configuração, equipes ganham agilidade, confiabilidade e controle sobre ambientes complexos.

O futuro da infraestrutura está no código, e quem domina essas ferramentas está preparado para enfrentar os desafios da engenharia moderna.

Feito!

Tendências de DevOps para 2026

O universo de DevOps continua evoluindo em ritmo acelerado e 2026 promete ser um ano de consolidação de práticas que já vinham ganhando espaço, além da chegada de novas abordagens impulsionadas pela Inteligência Artificial (IA) e pela necessidade de maior resiliência digital. O presente artigo apresenta esse cenário não apenas como uma lista de ferramentas, mas como uma transformação cultural e estratégica que redefine como equipes constroem e entregam soluções.

Automação inteligente

A automação deixa de ser apenas scripts e pipelines pré-configurados. Em 2026, vemos ferramentas que usam IA para prever falhas e sugerir correções.

Ferramentas: GitHub Copilot para automação de código, Jenkins com plugins de IA, ArgoCD para entrega contínua inteligente.

Caso prático: uma equipe de e-commerce que usa ArgoCD integrado ao Prometheus para detectar gargalos de performance e ajustar automaticamente a infraestrutura.

Observabilidade integrada

Não basta monitorar CPU e memória. Observabilidade significa entender o comportamento completo do sistema.

Ferramentas: Grafana Tempo para traces, Loki para logs, Prometheus para métricas, todos integrados em dashboards unificados.

Caso prático: uma fintech que correlaciona logs de autenticação com métricas de latência para identificar fraudes em tempo real.

Segurança como prioridade

DevSecOps se torna padrão. Segurança é incorporada desde o início do pipeline.

Ferramentas: Snyk para análise de vulnerabilidades em dependências, Trivy para imagens de containers, HashiCorp Vault para gestão de segredos.

Caso prático: uma startup de saúde que usa Trivy para validar imagens Docker antes de cada deploy, garantindo compliance com normas médicas.

Infraestrutura adaptativa

Infraestrutura como código evolui para ambientes que se autoajustam.

Ferramentas: Terraform com módulos dinâmicos, Pulumi com suporte a linguagens modernas, Kubernetes com Horizontal Pod Autoscaler.

Caso prático: uma empresa de streaming que ajusta automaticamente a quantidade de pods Kubernetes durante grandes eventos esportivos.

Cultura de colaboração ampliada

DevOps não é só técnico, é cultural. Em 2026, negócio e tecnologia trabalham juntos em ciclos curtos.

Ferramentas: Jira para gestão ágil, Slack com bots de integração, Confluence para documentação viva.

Caso prático: uma empresa de logística que conecta dashboards de entrega com o backlog de produto, permitindo decisões rápidas baseadas em dados.

Considerações finais

O futuro do DevOps em 2026 é marcado pela fusão entre IA, segurança, observabilidade e colaboração. Mais do que dominar ferramentas, o diferencial estará em arquitetar soluções resilientes e adaptativas, capazes de responder às demandas de negócio em tempo real.

Feito!

3 atitudes que fazem desenvolvedores experientes parecerem Júniors

Muitos desenvolvedores experientes podem, sem perceber, adotar comportamentos que os fazem parecer menos maduros profissionalmente, como se fossem desenvolvedores júniores. Essa percepção pode impactar negativamente a evolução da carreira, especialmente porque a gestão nota essas atitudes e pode duvidar da capacidade do profissional.

A diferença entre um dev júnior, pleno e sênior não reside apenas no domínio técnico, mas também na mentalidade, proatividade e na forma de lidar com os desafios e pessoas no ambiente de trabalho. Atitudes típicas de dev júnior incluem esperar ordens ao invés de buscar soluções, falta de iniciativa e dificuldade em assumir responsabilidades além do básico. Mesmo devs experientes podem acabar com esse tipo de comportamento se não desenvolverem autoconfiança e comunicação efetiva.

Para evitar essa impressão negativa, é fundamental trabalhar o mindset de crescimento contínuo, cultivar habilidades interpessoais e ser proativo na busca por melhorias e soluções. Uma liderança que sabe orientar o desenvolvimento dos profissionais também é crucial para que devs plenos e sêniores possam avançar na carreira com confiança e postura mais madura.

Reconhecer essas atitudes e implementar mudanças pode ser o diferencial para um desenvolvedor experiente se destacar verdadeiramente no mercado e em seu time, seja em projetos internos ou em oportunidades futuras.

Feito!

Dominar os fundamentos da Stack do jeito certo

O presente post destaca duas práticas essenciais baseadas na experiência pessoal: prática deliberada e participação em troubleshooting e load tests.

1. Prática deliberada

Foco em experimentação intencional: Não basta estudar teoria; é preciso colocar em prática de forma deliberada, como simular cenários reais (ex: sobrecarregar garbage collector para gerar concorrência e observar o impacto).

Evita testes superficiais; exige reproduzir problemas reais para entender mecanismos profundos da linguagem.

2. Participação em Troubleshooting e Load Tests

Exposição a crises reais: Ajuda a compreender gerenciamento de memória, runtime, queries de banco e performance em produção, identificando pontos de falha.

Benefícios em escala: Com alto volume de usuários, revela diferenças de performance evitáveis ao programar pensando nos fundamentos.

Dica prática: Peça para observar sessões na empresa; aprenda ouvindo experts, sem precisar intervir inicialmente.

Impacto Geral: Essas práticas transformam conhecimento teórico em confiança prática, melhorando fundamentos da stack de forma acelerada.

Feito!

Por que desenvolvedores se sentem sobrecarrados

É comum que desenvolvedores, mesmo os mais experientes, se sintam desatualizados ou desistam dos estudos devido à quantidade massiva de conteúdo disponível.

A área de Tecnologia da Informação avança muito mais rápido do que qualquer outra área de estudo, o que significa que há sempre algo novo para aprender.

Há um volume gigantesco de informações novas (tecnologias, hypes como IA e microsserviços) e mudanças constantes em processos (como a transição de Waterfall para Agile) e métodos de programação.

O excesso de material disponível (livros, cursos, vídeos, artigos) e o bombardeio de opiniões diferentes nas redes sociais, embora positivo em outras áreas, pode se tornar um fardo.

Essa sobrecarga massiva de informação gera FOMO (Fear of Missing Out) e ansiedade, consumindo o espaço mental necessário para focar no que realmente importa.

O problema afeta tanto iniciantes (que acham que precisam saber tudo) quanto seniors (que têm consciência do que está faltando).

A chave é aprender a se preparar com foco e tranquilidade, aproveitando a jornada.

• Dica 1: Foque nos seus objetivos de carreira

  A falta de um objetivo de carreira claro leva à falta de foco, fazendo com que o desenvolvedor estude tudo o que vê pela frente, sem filtro.

  O objetivo de carreira atua como um filtro essencial, fornecendo clareza sobre onde se deve ir, o que estudar, e, crucialmente, o que não se deve estudar.

  Estudar sem um objetivo leva ao desperdício de tempo com conhecimentos que não são usados ou aplicados no dia a dia, gerando a sensação de sobrecarga.

  Exemplo: Estudar Cloud (AWS/GCP) ou Data Science sem que isso seja um objetivo planejado pode apenas sobrecarregar, pois a maioria dos devs nem sequer mexe na infraestrutura de nuvem.

  Como definir e usar o foco

  Pare de trabalhar só por trabalhar: O desenvolvedor que faz ping-pong entre tecnologias e empresas (Java -> .Net -> Python) sem firmar base acaba estagnado, fazendo sempre as mesmas coisas.

  Entenda seu momento atual: Avalie sua posição, suas habilidades e se você prefere o trabalho operacional (campo de batalha) ou a liderança/gestão.

  Projete o futuro: Defina onde você quer chegar em alguns anos, ou, se for difícil, projete pelo menos dois passos à frente (o próximo passo e o seguinte).

  Ter um plano, mesmo que flexível e revisado anualmente, garante que você esteja virando na direção correta.

  A direção correta é o que filtra o que precisa ser estudado (e.g., se o objetivo é gestão, estude administração de budget e time; se é Tech Lead, desenvolva comunicação e liderança).

• Dica 2: Especialize-se no que importa

É fundamental se especializar naquilo que importa para seus objetivos de carreira.

Há uma ilusão do full stack: Desenvolvedores seniors defendem a especialização, mas iniciantes buscam ser junior full stack, algo que não existe, pois ser full stack exige ver muita coisa (Back End, Front End, UX, usabilidade, acessibilidade).

Não dá para ser bom em tudo, e é muito fácil você não ser bom em nada. O dev que quer ser bom em tudo acaba sendo um dev que não faz nada direito.

O Dev Especialista: Não é aquele que só sabe uma coisa, mas sim aquele que é muito bom em uma coisa e se vira muito bem no resto das atividades.

As empresas querem um dev que consegue se virar, e dão tarefas simples na especialidade do recém-chegado para evitar erros no software.

Alocação de tempo de estudo por especialidade

A especialização deve ser definida com base nos objetivos de carreira (e.g., Back End, linguagem, banco de dados) e o tempo de estudo deve ser alocado conforme o nível de maturidade:

Nível de carreira	Especialidade (foco fechado)	Diversificação (foco aberto)
Júnior	90%	10%
Pleno	70% Reforça a base	30% Começa a mexer com mais coisas
Sênior	50% Já desenvolveu base	50% Pode abrir o leque com vontade

É importante ter uma mentalidade flexível e não ser rígido com a especialização (e.g., um dev Back End não deve se recusar a mexer no Front End quando necessário).

• Dica 3: Pratique mais do que estude

O aprendizado é dividido em três dimensões hierárquicas: Informação, Conhecimento e Habilidade.



Figura 1. As Três Dimensões do Aprendizado

Informação: Conteúdo solto (artigos, posts) que entra e sai rapidamente. É o nível principal necessário para Diretores/CEOs (nível estratégico).

Conhecimento: Informação processada (pesquisa aprofundada, cursos teóricos). É o nível principal necessário para Gerentes/Gestores (nível tático).

Habilidade: Capacidade de aplicar o conhecimento na prática. É o nível crucial para Desenvolvedores (nível operacional), que precisam pôr a mão na massa.

O que ajuda o dev de verdade é a habilidade, e não apenas a informação ou o conhecimento.

Quanto mais você pratica o que estuda, mais rápido você erra e mais rápido você aprende. Errar é essencial; ninguém aprende sendo perfeito.

Como aplicar a prática

• Regra 80/20:

Dedique 80% do tempo à prática e apenas 20% ao estudo. Essa proporção garante que o estudo se transforme em habilidade e evita que o dev se perca na quantidade de conteúdo.

• Nunca estude nada sem praticar:

Se você está estudando algo, faça algo com esse conhecimento, ou ele permanecerá apenas como informação.

• Pratique no trabalho:

Praticar sob a pressão do trabalho gera um aprendizado muito mais valioso do que exemplos simples de cursos.

• Crie projetos pessoais:

Se não houver oportunidade no trabalho, crie projetos pessoais (lista de tarefas, livro de receitas, etc.) para aplicar o conhecimento no código.

Direção e Evolução

O que importa mesmo é ter direção. Estudar e acumular certificados sem ter um objetivo claro é inútil e pode levar à estagnação na carreira.

Ter um excesso de conteúdo na área é uma vantagem sobre a escassez do passado, pois a barreira de entrada é baixa; é preciso apenas aprender a aproveitar a jornada com foco.

Ter uma direção clara é o que permite ao desenvolvedor se divertir e aproveitar a longa jornada na tecnologia.

Feito!

O desafio do código legado e a importância para o negócio

Mexer em código legado é uma necessidade comum, mas é um trabalho que a maioria dos desenvolvedores não gosta de fazer.

Do ponto de vista do desenvolvedor, código legado é difícil de manter devido à alta complexidade, falta de uma boa arquitetura, nomes esquisitos, e a perda da ideia arquitetural original ao longo do tempo.

Sistemas legados geralmente possuem pouco conhecimento documentado na equipe, pois os desenvolvedores originais que fizeram as "gambiarra" (hacks) justificáveis não estão mais presentes para explicar as intenções.

É comum que o código legado utilize tecnologias mais antigas (versões de frameworks ou linguagens) ou estilos de programação que mudaram significativamente com o tempo, dificultando a compreensão por devs menos experientes.

O maior problema do código legado é a falta de testes ou a presença de testes quebrados, não rodados ou que não testam nada (e.g., sem asserts), o que torna a manutenção difícil.

Do ponto de vista da empresa, o software legado é muito importante e sustenta grande parte do faturamento, sendo a materialização do Retorno do Investimento (ROI) inicial.

Um software legado geralmente já cobriu seu custo de investimento e agora gera apenas retorno, com custos de manutenção menores do que o faturamento gerado.

Por gerar alto faturamento, o legado tem criticidade muito alta, e qualquer quebra gera estresse e transtorno para a empresa.

Na maioria das carreiras longas em tecnologia, o desenvolvedor passará muito mais tempo mantendo software legado do que criando software novo do zero.

Três erros que deixam o Dev surtado no legado

1. A pressa de arrumar o código

O Erro: Sentir a urgência e o desespero de alterar o código imediatamente ao notar algo esquisito, mesmo que com boa intenção.

O software não fica ruim da noite para o dia, mas sim através de uma sequência de decisões ruins ao longo de muito tempo; melhorar também é um processo demorado.

Fazer alterações na pressa invariavelmente leva a dois problemas:

• Quebrar o que não devia, mesmo tendo a melhor intenção.
• Deixar o código mais complexo do que já estava, muitas vezes criando patterns ou lógicas que o próprio dev não entenderá em uma semana.

Como evitar (Regra de Ouro):

Tenha paciência com consciência: Não significa ser conivente com os problemas, mas sim não tentar arrumar tudo de uma vez.

Melhorar não é reescrever tudo do zero, o que é caro e gera bugs; melhore as coisas aos poucos (refatorar e melhorar sempre, mas em pequenas doses).

Avalie o risco de alteração: O benefício de mexer deve ser maior do que o risco de quebrar algo crítico, e isso exige conhecimento do contexto do software.

Lembre-se que um é melhor do que zero (1 > 0); pequenas alterações geram valor e são um exercício de paciência.

2. Refatorar sem testes

O Erro: Alterar o código sem ter um gabarito de testes para garantir que o comportamento original não foi modificado.

Refatorar é mudar o código sem mudar o comportamento original. Se você muda o comportamento original do código, você não está refatorando, você está alterando.

Misturar alteração (mudança de comportamento) e refatoração (mudança de estrutura) sem testes é a "receita da treta" e gera grandes estragos.

O teste é o gabarito que diz o que é certo e o que é errado para o código, sendo impossível saber se algo quebrou sem ele.

Como Evitar:

Pare de testar debugando: Debugar é para diagnosticar um erro específico; não é uma rotina de teste consistente.

Faça Teste Unitário: Escrever código que testa o código é o melhor jeito, pois automatiza e versiona o gabarito. Teste é um investimento, não um custo.

Se for Teste Manual, Escreva-o: Documente os passos do teste (e.g., "preencher campo X e clicar Y, deve aparecer mensagem Z") para garantir consistência e evitar testes viciados.

Adote o Loop: Alterou e Testou: Ao refatorar, faça uma pequena alteração e execute os testes, repetindo o ciclo para garantir que o comportamento original seja mantido.

3. Refatorar sem um propósito

O Erro: Refatorar por incômodo pessoal (código feio ou ruim) e não por uma necessidade de negócio que justifique a alteração.

Código quebrado incomoda muito mais do que código ruim; era melhor deixar o código ruim funcionando do que quebrá-lo com uma alteração sem propósito.

Se você altera o código sem motivo e ele quebra, é difícil de explicar o problema ao gestor, gerando a percepção de um perfeccionismo inútil e arranhando sua imagem.

Boa intenção não é motivo suficiente para alterar o código; é necessário um processo que apoie a mudança.

Como Evitar:

1. Limite a refatoração ao escopo do seu trabalho: Só refatore aquilo que você vai mexer por uma demanda de negócio. Se não tem a ver com sua alteração, deixe quieto.
2. Anote em vez de Alterar: Se você vir um ponto esquisito fora do seu escopo, anote o problema (em um comentário no código, post-it ou caderno). Isso permite que o próximo desenvolvedor que passar por ali faça a refatoração.

3. Pegue carona nas demandas: Use demandas de negócio que passem por um ponto problemático para realizar a refatoração. Isso diminui o risco, pois o teste da sua alteração cobrirá o código refatorado.

Considerações finais

A melhoria do software legado é uma construção constante e demorada; o processo deve ser sem pressa, mas sem pausa.

O tempo da empresa (que pode ter 40 ou 50 anos) é diferente do seu tempo; não julgue a urgência de resolver todos os problemas em um dia.

Aproveite o legado para aprender: Mexer em código legado é uma excelente oportunidade para aprender sobre a parte técnica (refatoração, testes) e, principalmente, sobre o negócio da empresa, absorvendo conhecimento durante o trabalho.

Feito!

O Papel Profissional do Analista de Negócios

No desenvolvimento ágil de software, a clareza na comunicação e a qualidade da documentação têm impacto direto no sucesso do produto. Entre os principais responsáveis por garantir esse alinhamento está o Analista de Negócios (Business Analyst).

No entanto, ainda é comum encontrar equipes em que o Analista de Negócios participa apenas de reuniões de refinamento, sem assumir integralmente uma de suas atividades mais importantes: a elaboração completa das estórias de usuário.

No presente artigo, discutimos por que essa tarefa é parte fundamental do papel do Analista de Negócios, melhores práticas e como isso colabora com a eficiência da equipe e com o Product Owner (PO).

É responsabilidade do Analista de Negócios escrever estórias de usuário

A escrita de estórias deve seguir um documento com versionamento e rastreabilidade, permitindo controle das alterações ao longo do tempo. Elementos como:

• Autor da criação
• Revisor(es)
• Datas de criação, revisão e ajustes
• Histórico de modificações e responsáveis por cada edição

Exemplo simples de versionamento dentro do documento:

Criado por: Nome Sobrenome – dd/mm/aaaa
Revisado por: Nome Sobrenome – dd/mm/aaaa
Ajustado por: Nome Sobrenome – dd/mm/aaaa

Ferramentas como Redmine, Jira, Azure DevOps, Trello, Confluence ou qualquer outra usada pela empresa devem conter esse histórico para garantir auditabilidade e transparência.

O PO valida, não escreve

O Product Owner possui uma agenda repleta de responsabilidades estratégicas, como:

• Definir e priorizar o backlog
• Analisar métricas do produto
• Engajar stakeholders
• Garantir alinhamento com a visão de negócio

Portanto, não é usual nem eficiente que o PO seja o responsável por redigir as estórias. Sua atuação é validar, complementar e aprovar as entregas do Analista de Negócios.

O Analista de Negócios coleta e estrutura as informações.

O PO garante que o conteúdo está alinhado ao produto.

Cada um no seu papel.

Participar do refinamento não é suficiente

Em muitas equipes, o Analista de Negócios participa de reuniões de refinamento duas vezes por semana e depois simplesmente, fica na moita. Esperando tudo cair pronto ou dependendo do PO para gerar conteúdo.

Isso é um desperdício de capacidade técnica e profissional.

O Analista de Negócios deve:

• Elaborar as estórias da Sprint
• Adicionar critérios de aceite
• Mapear regras de negócio
• Acompanhar dúvidas do time
• Buscar esclarecimento com stakeholders
• Manter documentação sempre atualizada

Ser apenas ouvinte em reunião não entrega valor.

Boas práticas do Analista de Negócios na escrita de estórias

Prática	Benefício
Documentar versionamento (criado/revisado/ajustado)	Controle total das alterações, auditabilidade e rastreabilidade de decisões.
Usar critérios de aceite claros (ex.: Gherkin)	Evita ambiguidades e retrabalho; facilita testes e validação pelo QA e PO.
Dividir funcionalidades em estórias pequenas e independentes	Entrega mais rápida, menor risco e ciclos de feedback mais curtos.
Conversar com usuários e stakeholders (coleta direta)	Informações reais e contexto de negócio, reduz hipóteses e suposições.
Validação contínua com o PO (comentários e aprovação)	Garante alinhamento com a visão do produto e priorização correta do backlog.

O Analista de Negócios precisa ser protagonista no processo, não um observador passivo.

Considerações finais

Quando o Analista de Negócios cumpre seu papel com excelência:

• O PO ganha tempo para atuar estrategicamente
• O time não trabalha com falta de informação
• A Sprint flui com mais eficiência
• A qualidade do software aumenta
• O cliente percebe mais valor entregue

Em resumo:

Escrever estórias de usuário é responsabilidade do Analista de Negócios.

Validar e priorizar é responsabilidade do PO.

Profissionalismo se traduz em atitude.

O Analista de Negócios que entra em ação é quem realmente contribui para o sucesso do produto.

Feito!

Como exportar e importar banco de dados no SGBD MySQL

Quando falamos em rotinas de backup de banco de dados, um dos comandos mais utilizados é o mysqldump, pois permite gerar um arquivo .sql com as instruções necessárias para recriar as tabelas e os dados do banco.

Neste guia prático, você aprenderá:

• Como exportar um banco de dados MySQL
• Como importar um backup .sql
• Como gerar a data no nome do backup automaticamente via variável

Pré-requisitos

• MySQL instalado e acessível no terminal
• Usuário com permissão de leitura/escrita no banco
• Terminal Linux/Mac (para Windows, utilize Git Bash ou WSL para compatibilidade)

Exportando o banco de dados (Backup)

Vamos usar uma variável chamada DATA que recebe a data atual no formato YYYY-MM-DD:

DATA=$(date +%F)

Agora rode o comando de exportação:

mysqldump -u usuario -p --default-character-set=utf8mb4 nome_do_banco > bkp-${DATA}.sql

O arquivo gerado será algo como:

bkp-2025-11-27.sql

A opção --default-character-set=utf8mb4 garante compatibilidade com emojis e caracteres especiais.

Importando o banco de dados (Restauração)

Caso o banco ainda não exista, crie-o antes:

mysql -u usuario -p -e "CREATE DATABASE nome_do_banco CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Para restaurar um backup .sql em outro banco (ou no mesmo):

mysql -u usuario -p --default-character-set=utf8mb4 nome_do_banco < bkp-${DATA}.sql

Dicas de Segurança

Nunca salve senhas diretamente no comando

Mantenha os arquivos .sql fora do repositório e GitHub

Automatize o backup com cron em produção

Agendamento de Backup

Exemplo de backup diário às 02:00 da manhã via cron:

0 2 * * * DATA=$(date +\%F) && mysqldump -u usuario -p'suaSenha' --default-character-set=utf8mb4 nome_do_banco > /backups/bkp-${DATA}.sql

OBS: Em cron a data precisa usar \%F com escape do %.

Considerações finais

Com poucos comandos é possível garantir a segurança e recuperação dos seus dados. Recomendo manter backups em local seguro e testar periodicamente a restauração.

Feito!

Como automatizar variáveis de ambiente em notebooks corporativos sem permissão de admin

Uma solução prática para Java, Maven, Node, Quarkus e integrações corporativas usando scripts .bat

Em ambientes corporativos é comum que os desenvolvedores utilizem notebooks bloqueados, sem permissões administrativas para instalar ferramentas ou alterar o PATH do sistema. Mesmo assim, muitos projetos dependem de um ambiente consistente que inclui versões específicas de Java, Maven, Node, NVM e variáveis de configuração relacionadas a APIs internas, integrações com SSO e conexões com bancos de dados.

Para resolver esse problema e manter a produtividade, uma abordagem eficiente é preparar um diretório tools-dev contendo todas as ferramentas necessárias em formato .zip, que o próprio desenvolvedor extrai para seu diretório de usuário sem precisar de privilégios elevados. Em seguida, um conjunto de scripts .bat automatiza a configuração das variáveis de ambiente apenas na sessão do terminal, sem alterar nada do sistema.

O presente post explica a estrutura recomendada, o motivo dessa prática e como implementar o processo.

Por que usar um diretório tools-dev com arquivos .zip das ferramentas?

Em um notebook corporativo o desenvolvedor geralmente não pode:

• Instalar Java no diretório Program Files
• Instalar Node.js globalmente
• Alterar PATH do sistema
• Usar instaladores .msi
• Criar diretórios em locais protegidos

Por outro lado, ele pode:

Extrair arquivos .zip dentro de C:\Users\usuario\

Configurar variáveis apenas na sessão atual

Executar scripts .bat

Montar seu ambiente local isolado

Por isso, a estratégia recomendada é:

Criar um diretório tools-dev contendo:

• java17.zip
• maven3.9.zip
• node18.zip
• nvm.zip
• configurações auxiliares (scripts .bat)

Estrutura recomendada:

C:\Users\usuario\tools-dev\
 ├─ java17.zip
 ├─ maven.zip
 ├─ node18.zip
 ├─ nvm.zip
 ├─ npm18.zip
 ├─ env-projeto.bat
 ├─ terminal.bat
 └─ desenvolvimento\
      ├─ java\
      ├─ maven\
      ├─ node\
      ├─ nvm\
      └─ etc...

O desenvolvedor baixa o pacote com os .zip, extrai tudo dentro do tools-dev uma vez e a estrutura fica pronta permanentemente.

Essa abordagem garante:

• padronização entre todos os membros da equipe
• independência de permissões administrativas
• isolamento total entre projetos
• zero impacto no ambiente global do Windows

Script 1: env-projeto.bat

Arquivo responsável por carregar todas as variáveis do projeto:

@echo off
echo Carregando variáveis do projeto...

rem ==== Caminhos das ferramentas descompactadas ====
set JAVA_HOME=C:\Users\usuario\tools-dev\desenvolvimento\java
set MAVEN_HOME=C:\Users\usuario\tools-dev\desenvolvimento\maven
set NODE_HOME=C:\Users\usuario\tools-dev\desenvolvimento\node
set NVM_HOME=C:\Users\usuario\tools-dev\desenvolvimento\nvm

rem ==== Variáveis específicas do projeto ====
set REALM_NTRANET=realm_intranet
set REALM_INTERNET=realm_internet
set SSO_CLIENT_ID=cliente-sso
set SSO_URI_INTERNET=https://auth-externo.empresa.com
set SSO_URI_INTRANET=https://auth-interno.empresa.local
set API_KEY=SUA_API_KEY_AQUI

rem ==== Datasource ====
set DS_KIND=mssql
set QUARKUS_DEFAULT_SCHEMA=dbo
set DS_DIALECT=org.hibernate.dialect.SQLServerLDialect
set DS_URL=jdbc:sqlserver://IPSERVIDORDB:1433;databaseName=bancoNome;integratedSecurity=true;encrypt=false;trustServerCertificate=true
set DS_GENERATION=none
#set QUARKUS_DATASOURCE_USERNAME=usuario
#set QUARKUS_DATASOURCE_PASSWORD=senha
set QUARKUS_DATASOURCE_JDBC_URL=%DS_URL%

rem ==== Serviços internos ====
set API_SISGF=http://localhost:8081/sisgf
set API_SIICO=http://localhost:8082/siico
set API_SISRH=http://localhost:8083/sisrh

rem ==== PATH desta sessão ====
set PATH=%JAVA_HOME%\bin;%MAVEN_HOME%\bin;%NODE_HOME%;%NVM_HOME%;%PATH%

echo Ambiente carregado.

OBS: A configuração na variável QUARKUS_DATASOURCE_JDBC_URL é com MS SQL Server configurado com autenticação de usuário do Windows

Por isso as linhas das variáveis QUARKUS_DATASOURCE_USERNAME e QUARKUS_DATASOURCE_PASSWORD estão comentadas.

Tudo é aplicado apenas no terminal atual, sem alterar o PATH global.

Script 2: terminal.bat

Ele simplesmente abre o CMD já carregando o ambiente configurado:

cmd.exe /k "C:\Users\usuario\tools-dev\env-projeto.bat"

Assim, ao clicar no terminal.bat, o desenvolvedor já entra no terminal com:

• Java configurado
• Maven configurado
• Node e NPM configurados
• NVM funcionando
• Todas as variáveis corporativas carregadas

Por que essa automação é tão útil?

1. Elimina configurações manuais e erros

O script garante que todo mundo tenha exatamente o mesmo ambiente.

2. Permite múltiplos projetos com versões diferentes

Exemplo:

• Projeto A -> Java 17, Quarkus 3.15, Maven 3.9
• Projeto B -> Java 21, Quarkus 3.27, Maven 4.x

Cada projeto terá seu próprio env-projeto.bat.

3. Não exige direitos administrativos

Nada vai para o PATH do sistema.

Tudo roda no escopo do usuário.

4. Fácil de versionar e distribuir

O diretório tools-dev pode ser:

• compartilhado no Teams
• versionado no Git (sem binários, apenas instruções)
• disponibilizado em pacote zip para novos devs
5. Facilita onboarding de novos desenvolvedores

O dev novo só faz:

• -extrair o pacote tools-dev
• configurar os diretórios internos
• executar terminal.bat

Em menos de 2 minutos ele está pronto para programar.

Considerações finais

A criação de um diretório tools-dev com os .zip das ferramentas e scripts .bat que configuram as variáveis de ambiente apenas na sessão do usuário é uma estratégia altamente eficiente para ambientes corporativos com restrições administrativas. Isso cria um fluxo de trabalho organizado, reprodutível, seguro e 100 por cento alinhado às boas práticas de equipes de desenvolvimento profissional.

Feito!

5 dicas para entregar código mais rápido sem quebrar a produção

Todo desenvolvedor quer entregar tarefas rapidamente, mas sem comprometer a qualidade em produção.

Velocidade no desenvolvimento não se resume ao tempo gasto, mas à percepção de velocidade. Ferramentas ajudam, mas o verdadeiro ganho vem de otimizar o trabalho diário.

Muitos culpam burocracia, falta de conhecimento ou ferramentas ruins, mas os vilões principais são:

• Bugs e retrabalho:

Consomem tempo ao normalizar entregas com erros.

• Preciosismo técnico:

Foco excessivo em detalhes desnecessários.

• Estimativas erradas:

Criam percepção de lentidão.

Melhorar esses pontos faz você parecer mais rápido e confiável.

Dica 1: Entenda o problema antes de programar

Não corra na direção errada.

Faça análise de requisitos: Converse com o usuário para explorar o problema real, sem documentações gigantes.

Evite resolver o problema errado, que gera bugs, retrabalho e perda de confiança.

Resolver o problema errado gera muito mais transtorno.

Dica 2: Monte um planejamento claro

Organização não é burocracia, é investimento.

Crie lista de tarefas: Tire tudo da cabeça (Excel, Word, Trello).

Defina orçamentos: Estimativas por tarefa para saber o prazo total.

Ganhe foco: Saiba o que fazer agora, sem distrações.

Planejamento mostra a luz no fim do túnel.

Dica 3: Priorize a solução, não os detalhes

Resolva o problema primeiro, melhore depois.

Evite:

• Perfeccionismo técnico e overengineering.
• Priorizar como dev: Foque em regras de negócio, não em telas ou banco logo de cara.

Entregue resultado cedo para aumentar a percepção de velocidade, como nos métodos ágeis.

Dica 4: Faça testes consistentes

Teste contra requisitos, não contra sua memória.

Crie roteiros de teste: Descreva ações e resultados esperados.

Use testes unitários: Rápidos, repetíveis e rede de proteção.

Evite teste viciado (debugando apenas o que lembra), que cria falsa segurança.

Dica 5: Refatore sem dó (com jogo ganho)

Melhore o código após resolver o problema.

No início, priorize funcionalidade; no final, clareza e performance.

Testes protegem: Quebre e reconstrua com segurança.

Exemplos: Como time de futebol com placar favorável ou compras no mercado sem fome.

Passo a Passo para aplicar

Os ajustes a seguir são um passo a passo para melhorar a entrega sem depender de ferramentas ou IA

Siga na sequência para máximo impacto:

Dica extra: Vá devagar e sempre. Ferramentas e IAs potencializam, mas não substituem maturidade.

Considerações finais

Vá devagar e sempre: Resultados pequenos não desanimem; dificuldades não parem o progresso.

Ferramentas potencializam, não substituem: Sem base sólida, IAs e ferramentas entregam "esgoto".

Maturidade é o segredo: Velocidade real vem de prática e processo, não de fórmulas mágicas.

Aplique em uma demanda e veja a diferença na percepção de velocidade!

Feito!

3 dicas essenciais para resolver bugs como um Dev Sênior

Já parou para pensar por que alguns colegas sênior resolvem bugs em minutos, enquanto você fica horas (ou dias) preso no mesmo problema? A experiência conta, mas há estratégias simples que fazem toda a diferença. No presente artigo, vou compartilhar essas abordagens práticas para você elevar seu jogo. Não precisa ser expert em testes unitários para aplicar isso, vamos focar no essencial.

Por que resolver bugs é um desafio comum?

Muitas empresas priorizam velocidade sobre qualidade, resultando em testes superficiais ou inexistentes. Isso forma devs que não dominam testes, mesmo pedindo testes unitários nas vagas. Testes unitários são cruciais para sênior, mas se você ainda não os usa, há maneiras de ser eficiente sem eles.

O problema? Devs correm para alterar código no palpite, sem simular ou entender o erro, o que leva a correções superficiais e novos bugs. Vamos mudar isso com três dicas acionáveis.

• Dica 1: Simule o erro antes de mexer no código

Parece óbvio, mas a maioria ignora: antes de alterar qualquer linha, reproduza o bug exatamente como o usuário relatou. Isso direciona você à causa raiz, não ao sintoma.

Por que isso funciona?

Logs ou debugs mostram sintomas (ex.: "null reference"), mas o problema pode estar upstream, como uma consulta retornando dados errados.

Simulando, você cria um "gabarito" para validar a correção: repita os passos e veja se o erro some. Se persistir, você alterou o lugar errado.

Como aplicar no dia a dia?

Colete evidências concretas: Peça screenshots de tela, logs ou dados do usuário. Sem acesso a produção? Insista, é essencial.

Rastreie o caminho inverso: Comece pelo erro (ex.: busque a mensagem no código via Ctrl+Shift+F) e volte até a origem.

Simule como usuário: Imitar ações com os dados problemáticos revela o fluxo real, evitando desculpas como "não tenho permissão".

• Dica 2: Divida o erro em partes menores

Bugs grandes assustam (ex.: impacto em 350 mil registros), mas lembre: a maioria é pequena na correção, mesmo que demore para diagnosticar. Divida para conquistar.

O Erro comum dos iniciantes

Olhar o "tudão" (ex.: rotina que faz 350 coisas) causa paralisia e alterações aleatórias, corrigindo sintomas e criando novos problemas. Respire e fatiar: problemas pequenos são fáceis de resolver.

Estratégias práticas

Mapeie fluxos principais: Liste fluxos do sistema (em wiki ou Excel, não na cabeça). Elimine os irrelevantes para focar.

Encontre o ponto exato: Use evidências da simulação para isolar (ex.: um if errado em lógica de data pode levar horas para achar, mas 5 minutos para fixar).

Crie lista de tarefas: Anote candidatos a correção (ex.: "analisar ponto X"). Divida análises grandes, não confie na memória.

Exemplo real: Um bug de validação de data (período >1 ano) veio de contagem errada no componente (meses zerando dias). Demorou para achar, mas corrigiu rápido com teste unitário. s s Bugs tendem a ser "pequenos", foque nisso para calma e velocidade.

• Dica 3: Aprenda a mexer no software que você trabalha

Conhecer o software além do código (regras de negócio, fluxos de uso) é subestimado, mas valorizado pelas empresas, mais que tecnologia em alguns casos.

Benefícios para resolver bugs

Levante hipóteses: Saiba perfis de uso para prever problemas (ex.: loop em pedidos grandes causando performance).

Ganhe autonomia: Decida se uma alteração faz sentido sem pedir aprovação constante, acelerando correções.

Valor no mercado: Devs "dinossauros" ficam sênior por conhecer legados; some isso a tecnologia e você brilha.

Como desenvolver esse conhecimento

Ponto de Vista do Usuário: Pergunte "por quê?" e "para quê?" em demandas, revela regras e negócio. Observe uso real (não só seus testes repetitivos).

Ponto de vista do Dev: Altere com atenção, note fluxos críticos (ex.: áreas com bugs recorrentes). Questione motivadores do código ("por que essa regra?").

Aproveite análises tranquilas: Em requisitos ou features novas, estude código e regras sem pressão de produção.

Isso enriquece seu currículo com conhecimento de negócio prático.

Considerações finais

Essas dicas, simular erros, dividir problemas e conhecer o software, são ajustes simples no seu processo, inspirados em análise de requisitos. Elas te levam à maestria sênior, mesmo sem testes avançados.

Dica Extra: Testes unitários aceleram tudo, crie um para validar correções e evite regressões. Comece devagar; os benefícios vêm com a prática.

Aplique isso no próximo bug e veja a diferença.

Feito!

O papel essencial do QA

Em muitos times de desenvolvimento, ainda é comum observar QAs que, ao encontrar um bug, simplesmente enviam uma mensagem rápida no Teams ou no WhatsApp: "Está com bug".

Mas esse tipo de comunicação, apesar de aparentemente ágil, causa retrabalho, atrasos, tensões desnecessárias entre Dev e QA e afeta diretamente a qualidade da entrega final.

Posso afirmar com segurança: achar o bug é apenas metade do trabalho. A outra metade é documentá-lo corretamente.

E é exatamente isso que diferencia um QA júnior de um QA profissional, maduro e reconhecido pelo time.

No presente artigo explica por que a documentação clara dos passos para reprodução do bug é essencial, como isso melhora a eficiência do time e como construir essa prática na rotina.

Por que só avisar que "tem bug" não funciona?

Quando o QA apenas informa verbalmente que encontrou um defeito, sem detalhar:

• O desenvolvedor não sabe exatamente como reproduzir o problema.
• O Dev tenta adivinhar o cenário ou pergunta várias vezes, gerando atrasos.
• A correção pode ser feita de forma errada ou incompleta.
• O time perde confiança nos resultados.
• O QA perde credibilidade e passa a ser visto como alguém que "só aponta erros", e não como alguém que aumenta qualidade.

Do ponto de vista técnico, isso quebra um dos pilares fundamentais da qualidade:

Rastreabilidade e repetibilidade do defeito.

Um bug sem passo a passo não é um bug: é uma suspeita.

O papel verdadeiro do QA: garantir que o bug seja 100% reproduzível

O QA especialista não entrega apenas um defeito.

Ele entrega uma evidência clara, passo a passo, ambiente, dados utilizados, resultado atual e resultado esperado.

Assim, quando o Dev pega a tarefa, ele consegue:

1. Reproduzir exatamente o mesmo comportamento.
2. Entender o contexto em que ocorre o problema.
3. Verificar o código enquanto compara com o cenário reproduzido.
4. Ajustar e testar novamente antes de enviar para revalidação.

Essa cadeia reduz drasticamente o tempo de correção.

Por que o Dev precisa dos passos de reprodução antes de ir para o código?

Porque nem todo bug é logicamente óbvio.

Alguns dependem de:

• condições específicas
• dados particulares
• combinações de ações
• tempos de resposta
• estados anteriores da aplicação
• permissões de usuário
• ambiente (homologação, dev, staging)

Sem isso, o Dev pode até olhar o código, mas não verá o problema.

E quando não vê o problema, surgem falas assim:

• "Aqui está funcionando normal."
• "Não consegui reproduzir."
• "Pode testar de novo?"

E o ciclo vicioso continua.

Documentar bem um bug acelera o trabalho do Dev

Muitos QAs acham que escrever passos é perda de tempo.

Na verdade, é o contrário.

Quando o QA registra o defeito de forma clara em ferramentas como:

• Jira
• Trello
• Redmine
• Ou qualquer plataforma definida pela empresa

ele está:

• economizando horas de retrabalho,
• reduzindo conversas paralelas desnecessárias,
• aumentando a assertividade,
• e tornando o time mais maduro.

Esse é o comportamento reconhecido em QAs certificados e seniores.

Como um QA especialista descreve um bug corretamente

Abertura profissional de bug inclui os itens abaixo:

1. Título claro

Exemplo:

"[Checkout] Sistema não aplica cupom de desconto válido"

2. Ambiente

Homologação

Develop

Staging

Navegador

Versão do app

3. Pré-condições

Usuário logado

Produto X no carrinho

Cupom ABC123 ativo

4. Passos para reproduzir

Acessar o carrinho.

Inserir o cupom “ABC123”.

Clicar em aplicar.

5. Resultado atual

O cupom não é aplicado e nenhuma mensagem é exibida.

6. Resultado esperado

O cupom deve ser aplicado e exibir o valor atualizado.

7. Evidências

Screenshots

Vídeo da execução

Logs (se houver)

A visão do QA profissional: qualidade é processo, não improviso

Um QA que deseja crescer na carreira, chegar a especialista, líder, analista sênior ou até automação, precisa demonstrar profissionalismo na forma como registra defeitos.

Qualidade não é só testar.

Qualidade é garantir que o time consiga reproduzir, corrigir e validar corretamente.

Se você quer trabalhar em empresas mais maduras, com cultura ágil e engenharia avançada, saiba:

reportar bug com qualidade é pré-requisito básico.

Nenhum QA certificado ou sênior abre bugs sem:

• passos de reprodução
• contexto
• evidência
• resultado atual x esperado

Considerações finais

QA não aponta problemas, QA resolve problemas junto com o time.

A real eficiência entre Devs e QAs acontece quando:

• QA documenta com clareza
• Dev consegue reproduzir sem dificuldade
• Correção é feita rapidamente
• Retrabalho é reduzido
• O time entrega com mais previsibilidade

Se você é QA e hoje apenas encontra bugs e avisa em grupos de chat, sem detalhar, saiba:

Essa prática pode estar prejudicando não apenas o time, mas sua evolução como profissional.

Adotar essa mudança coloca você em outro nível.

E o time inteiro sente a diferença.

Feito!

Guia completo das cerimônias Scrum

O Scrum é um dos frameworks ágeis mais adotados no mundo, mas muitos times ainda enfrentam dúvidas sobre como integrar corretamente as cerimônias da Sprint ao fluxo de preparação das estórias , especialmente no Backlog, no uso da Definition of Ready (DoR), Definition of Done (DoD) e na ordem certa dos status até chegar ao Refinamento e Planning.

No presente artigo você verá:

• Como funcionam todas as cerimônias do Scrum
• Como organizar o Backlog da forma correta
• Quais são os status ideais das estórias antes da Planning
• Como aplicar DoR e DoD

Fluxo de Backlog e status das estórias antes da Sprint

Para garantir uma Sprint eficiente, o fluxo das estórias deve seguir uma linha clara antes de chegar ao Refinamento e, posteriormente, à Sprint Planning. Isso evita dúvidas, retrabalho e reuniões demoradas.

1. Product Backlog (Backlog Inicial)

Aqui ficam as estórias ainda não refinadas, recém-criadas pelo PO ou pelo time.

Status comuns:

- Novo Item / Ideia

- Rascunho

- Aguardando Detalhamento

- Aguardando Critérios de Aceite

Neste estado, a estória não deve ser estimada nem levada para Planning.

2. Pré-Refinamento

O PO estrutura a estória para apresentá-la ao time.

Status comuns:

-Em Pré-Refinamento

-Aguardando alinhamento com PO

-Aguardando estimativa

A estória já tem descrição e direção, mas ainda não está “pronta” para o time.

3. Definition of Ready (DoR): Pronta para Refinamento

Antes do Refinamento técnico, a estória deve cumprir a DoR (Definition of Ready).

Uma estória está Preparada para Refinamento quando:

- Tem descrição clara

- Possui critérios de aceite completos

- Possui regras de negócio definidas

- Tem protótipos ou telas (quando aplicável)

- Não há dúvidas básicas sobre o contexto

- O PO está disponível para tirar dúvidas

Esse passo evita Refinamentos improdutivos.

4. Refinada e Estimada: Pronta para Planning

Após o encontro de Refinamento com Devs, QA e PO, a estória ganha mais maturidade.

Status ideais:

-Refinada

-Estimada

Pronta para Sprint Planning

Ready for Sprint

Aqui ela já:

- Tem Story Points definidos

- Devs entendem como implementar

- QAs sabem como testar

- Dependências estão mapeadas

- Impacto e riscos estão claros

- Só depois disso a estória pode entrar na Sprint.

5. Definition of Done (DoD): Conclusão de estória

Quando implementada, testada e entregue, a estória precisa atender a DoD.

A Definition of Done pode incluir:

- Código revisado

- Testes unitários implementados

- QA validado

- Critérios de aceite cumpridos

- Deploy em ambiente de homologação

- Documentação atualizada

Esse checklist garante qualidade e previsibilidade no final da Sprint.

Cerimônias do Scrum com o fluxo de Backlog integrado

Agora que entendemos o ciclo completo das estórias, vamos para as cerimônias e onde cada etapa se encaixa.

1. Daily Scrum (Daily Stand-up)

A Daily mantém o time sincronizado diariamente.

Objetivo:

- Alinhar o andamento da Sprint

- Identificar impedimentos rapidamente

Ajustar o plano da Sprint

Responder as perguntas clássicas:

O que fiz ontem?

O que farei hoje?

Tenho impedimentos?

Duração: 15 minutos

Participantes: Devs, QA, Scrum Master, Coordenador de Projetos, PO (opcional), Gestor (opcional)

A Daily não é momento para debater soluções técnicas. Esses alinhamentos devem acontecer depois da reunião, entre quem realmente precisa participar.

2. Sprint Review

A Review é realizada no final da Sprint e serve para mostrar ao PO e stakeholders tudo o que foi concluído.

O que acontece na Review?

Os Desenvolvedores apresentam screenshots e/ou demonstrações reais das estórias que foram validadas pelos QAs

O Product Owner avalia, comenta e confirma a entrega

Caso sejam identificados ajustes, eles viram novas estórias para Sprints futuras

Por que é importante?

A Review comprova transparência e garante que todos estão alinhados sobre o incremento entregue.

Participantes: Devs, QAs, Scrum Master, Coordenador de Projeto, Gestor, PO

3. Sprint Retrospective

A Retrospectiva é uma das cerimônias mais importantes do Scrum, pois é nela que o time melhora o processo.

Estrutura recomendada:

O que não deu certo? 10 minutos

Time lista falhas, gargalos e dificuldades.

Geram-se pontos de ação para serem aplicados na próxima Sprint.

O que deu certo? 10 minutos

Celebrar conquistas

Valorização do trabalho

Reforço das boas práticas

Fechamento

Revisão dos pontos de ação

Compromisso de aplicar as melhorias na próxima Sprint

Participantes: Devs,QA, Scrum Master, Coordenador de Projetos, Gestor, PO

4. Refinamento (Grooming)

O Refinamento é essencial para que a Planning seja rápida, eficiente e objetiva.

Objetivos do Refinamento

Devs e QAs tiram dúvidas com o PO

Ajustes nos critérios de aceite

Estórias são estimadas antecipadamente

Identificação de riscos, dependências e complexidades

Por que isso é importante?

Quando as estórias já estão prontas, claras e estimadas, a Planning flui muito melhor e economiza tempo do time.

Participantes: Devs, QAs, Scrum Master, Coordenador de Projeto (opcional)

5. Sprint Planning

A Planning marca o início da Sprint e define o que o time vai entregar.

Etapas principais:

Revisar estórias refinadas

Selecionar o que cabe na Sprint usando a capacidade (velocidade) do time

Definir a Meta da Sprint

Quebrar em tasks técnicas, se necessário

Parcipantes: Devs,QA,Scrum Master, PO, Gestor, Coordenador de Projetos

A Sprint começa oficialmente após o término da Planning.

Duração: 15 dias

Considerações finais

Integrar o fluxo do Backlog, as definições de DoR e DoD e as cerimônias oficiais do Scrum garante organização, previsibilidade e qualidade contínua. Times que seguem esse fluxo:

• Entregam as estórias mais assertivas
• Evitam retrabalho
• Diminuem dúvidas
• Aumentam a qualidade do produto
• Alcançam maturidade ágil real

Feito!

3 dicas essenciais para fazer entregas mais previsíveis

A previsibilidade nas entregas é um fator crucial que separa um desenvolvedor júnior de um sênior, e um dev que apenas programa de um profissional que gera confiança na gestão. Se você é um dev que cumpre o que promete, você demonstra comprometimento e maturidade profissional, qualidades que o colocam em posição de subir de nível na carreira.

Mas o que é uma entrega previsível?

Uma entrega previsível é aquela que gera previsibilidade para a gestão, permitindo que eles façam um planejamento baseado naquilo que você informa.

Um dev que não tem essa noção de previsibilidade atrapalha o planejamento da equipe e o andamento do todo, o que é um sinal de imaturidade profissional. Para evitar isso e se tornar um profissional mais confiável, siga estas três dicas fundamentais:

1. Aprenda a planejar o seu trabalho

O planejamento é a base de tudo. Muitos devs, especialmente os iniciantes e plenos, cometem o erro de negligenciar essa etapa, muitas vezes por uma interpretação equivocada de metodologias ágeis.

Planejar não é burocracia inútil é uma etapa essencial (o próprio Scrum tem a reunião de Planning). Sem planejamento, tudo o que você faz é baseado em um eu acho ou em um sentimento (feeling).

Riscos da falta de planejamento

Esquecimento: Você foca em um ponto e esquece de outras coisas importantes que estavam "só na sua cabeça".

Acúmulo de trabalho: O trabalho que faltou se acumula para o final do prazo, resultando em trabalho mal feito ou gambiarra.

Como planejar de forma eficaz

Um planejamento bem feito permite que você entenda o tamanho das encrencas e tenha uma visão geral do que precisa ser feito.

1. Defina um tempo fixo (time box):

Estabeleça um limite de tempo (ex: um dia) para o planejamento. Isso é crucial para evitar que você se afogue em planejamento e esqueça de trabalhar.

2. Entenda o problema e o requisito:

Antes de escrever código, pare para entender o porquê da alteração e a necessidade do usuário. Entender o problema é o primeiro passo antes de discutir esforço ou tempo.

3. Divida o problema em etapas:

Toda solução pode ser dividida em partes menores. Essa divisão ajuda a enxergar o trabalho, identificar o que pode ser feito em paralelo e o que é pré-requisito.

4. Crie uma lista de tarefas:

Transforme as etapas divididas em pequenas tarefas de desenvolvimento (ex: falar com o arquiteto, alterar sistema de cadastro, fazer cálculo no relatório).

Ter uma lista de tarefas é essencial; sem ela, você vai esquecer alguma coisa e terá retrabalho no final.

2. Aprenda a orçar o esforço

O orçamento de esforço é uma cobrança que acompanhará o dev por toda a carreira. A empresa precisa dessa previsibilidade para Time to Marketing (não perder o bonde da venda), questões regulatórias e para o gestor administrar o budget (gerenciar o pagamento da equipe).

Orçamento é palpite, não premonição

É fundamental entender que o orçamento sempre será um palpite (chute), independentemente da metodologia (pontos, Fibonacci, etc.).

Previsão é diferente de premonição. Você não está adivinhando o futuro, mas sim dando uma expectativa baseada nas informações que possui.

Orçar é uma habilidade que exige treino e prática constante, como chutar no futebol.

Como orçar com mais precisão

1. Tenha um planejamento:

Não existe orçamento sem planejamento e sem uma lista de tarefas. Tentar orçar uma "coisona" (tarefa gigante) é como chutar em um gol pequeno, a chance de erro é altíssima.

2. Garanta a granularidade:

Quanto mais detalhe e mais granular forem as tarefas, maior será a chance de acertar e, geralmente, maior será o orçamento (podendo ser 2x ou mais que o chute inicial).

3. Orce em grupo (sempre que possível):

Fazer orçamentos em grupo (como na Planning do Scrum) é muito mais eficiente do que fazer sozinho, pois permite um duplo check e a comparação de diferentes pontos de vista.

4. Conheça sua capacidade atual:

O autoconhecimento é vital. Se você não tem noção do quanto consegue produzir, você sempre errará o orçamento, superestimando ou subestimando o esforço necessário.

3. Comunique o status sempre que puder

Este é um erro comum de iniciantes: o medo de incomodar o gestor ou de dar a má notícia de um atraso.

O verdadeiro problema não é o atraso em si (a empresa tem tolerância), mas sim não avisar sobre o atraso com antecedência.

Se você avisa com dias ou semanas de antecedência, o gestor consegue negociar e tomar uma atitude. Se você avisa na véspera, não há mais tempo para nada.

A maior força de um profissional é conseguir assumir os seus erros e enxergar onde errou. Esconder a informação é agir como criança, não como adulto.

Comunicação em tarefas críticas

Quanto mais crítico é o que você faz, maior é a pressão e mais necessária se torna a sua comunicação. Sumir com uma tarefa crítica pode levar à sua substituição ou demissão. Se você não sabe se algo é crítico, pergunte; é sua obrigação buscar essa informação.

Estrutura da comunicação de status

Crie um ritual de comunicação, seja uma daily de 10-15 minutos ou um e-mail/mensagem diário, para manter o alinhamento e evitar surpresas.

A pauta da sua comunicação deve incluir:

• Visão Geral do andamento do trabalho.
• Progresso da atividade (o que avançou ou não).
• Possíveis atrasos (comunique com antecedência).
• Previsões novas (quanto tempo mais você precisa?).
• Bloqueios/Impedimentos (coisas que estão impedindo seu trabalho, como falta de acesso ou resposta), o gestor pode ajudar a resolver.

Considerações finais

Para colocar tudo isso em prática, comece a planejar e orçar suas atividades hoje, mesmo que a empresa não exija. Isso é um conhecimento que melhora sua empregabilidade e afeta diretamente sua carreira.

Além disso, facilite a vida do seu chefe ao invés de levar apenas um problema, leve o problema junto com uma solução proposta. Isso demonstra maturidade e comprometimento.

Todas essas habilidades de previsibilidade estão ligadas à Análise de Requisitos, que é tão fundamental para o dev quanto programar ou fazer testes unitários. Ao juntar a análise com a programação na sequência correta, você se torna um dev imparável que entrega qualidade e cumpre prazos na maioria das vezes.

Feito!

Workflow de branches em projetos ágeis: Boas práticas com Git Flow

Gerenciar branches de forma organizada é uma das práticas mais importantes em qualquer equipe de desenvolvimento. Um bom fluxo de versionamento garante rastreabilidade, previsibilidade nas entregas e reduz conflitos durante o ciclo de vida de cada Sprint.

Baseado no modelo Git Flow, o workflow que apresento aqui é uma adaptação moderna e prática, utilizada amplamente no mercado em equipes que trabalham com metodologias ágeis e ferramentas como Redmine, Jira, Trello ou GitHub/GitLab Issues.

1. Estrutura principal do repositório

O repositório segue duas principais linhas de desenvolvimento:

• master ou main:

contém o código estável e homologado, pronto para produção.

• develop:

linha de integração onde as novas funcionalidades e correções de Sprint são validadas antes da liberação.

A partir dessas duas branches centrais, todo o ciclo de desenvolvimento é organizado.

2. Criando branches de task (feature)

Cada nova task atribuída no sistema de gestão deve originar uma branch seguindo um padrão de nomenclatura padronizado. Isso facilita a rastreabilidade da entrega, especialmente quando o time é grande ou o projeto possui várias sprints paralelas.

O padrão recomendado é:

feature/sprintX/RTCY/TituloDaTask

Essa branch deve sempre ser criada a partir da branch develop atualizada, garantindo que a task comece sobre a base mais recente do projeto:

git checkout develop
git pull origin develop
git checkout -b feature/sprint5/RTC102/ImplementarAutenticacaoOAuth

Isso cria a branch da task a partir da develop atualizada.

3. Commits e Pull Request (PR)

Durante o desenvolvimento da task, os commits devem ser claros e objetivos, refletindo o progresso da implementação e dos testes unitários.

Ao concluir a task, realize o commit e o push final:

git add .
git commit -m "Finaliza implementação e testes unitários da autenticação OAuth"
git push origin feature/sprint5/RTC102/ImplementarAutenticacaoOAuth

Em seguida, abra um Pull Request (PR) para a branch develop e utilize o seguinte padrão de comentário:

[SPRINT5][RTC102][ImplementarAutenticacaoOAuth][feature]

Isso ajuda o time de revisão e o QA a identificar rapidamente o contexto da entrega.

4. Correção de bugs encontrados pelo QA

Caso o QA identifique algum bug durante os testes da Sprint, o desenvolvedor deve corrigir o problema na mesma branch da feature, mantendo o histórico da entrega.

Ao abrir um novo Pull Request ou atualizar o existente, utilize o seguinte padrão de comentário:

[SPRINT5][RTC102][ImplementarAutenticacaoOAuth][bug] Correção na validação do token

Esse formato indica que a PR refere-se a uma correção derivada da mesma task principal, mantendo o controle e a rastreabilidade no fluxo da Sprint.

5. Correções de bugs em produção

Para bugs que ocorrem em produção, a abordagem é diferente.

Essas correções devem ser baseadas diretamente na branch master ou main, garantindo que a correção seja aplicada sobre o código em execução.

A nomenclatura segue o padrão:

feature/bugfix/RTCX

Por exemplo:

feature/bugfix/RTC240

Crie a branch, aplique a correção, teste e envie o Pull Request de volta para a branch principal (master ou main).

Após aprovação e merge, é possível gerar uma tag de hotfix, caso necessário.

6. Encerramento da Sprint e versionamento

Ao final de cada Sprint, com todas as tasks revisadas e integradas à develop, é hora de gerar uma tag de versão.

A tag identifica o encerramento formal da Sprint e serve como ponto de referência no histórico do repositório.

O padrão sugerido é:

git tag -a v1.5 -m "Sprint 5 concluída"
git push origin v1.5

Esse versionamento facilita auditorias, rollback e acompanhamento de evolução entre as versões.

7. Benefícios desse workflow

Seguir esse modelo de workflow traz diversas vantagens:

• Clareza e rastreabilidade das entregas por Sprint.
• Redução de conflitos de merge.
• Facilidade na revisão de Pull Requests.
• Histórico limpo e versionamento controlado.
• Organização entre desenvolvimento, QA e deploy.

Bugfix Branch: Deve ir apenas para main ou também para develop?

Na maioria dos fluxos Git profissionais, incluindo Git Flow, GitHub Flow e variações híbridas bastante usadas em equipes Java/Spring/Quarkus, existe uma regra importante:

Todo bugfix criado a partir da main deve ser incorporado também à develop, caso ela exista.

Por quê?

Porque a branch develop geralmente contém novas features ainda não liberadas.

Se você corrigir o bug apenas na main, o problema voltará a aparecer quando a develop for integrada no futuro release, causando regressão.

Isso significa:

Criar a branch de bugfix a partir da main atualizada

Porque o bug ocorre na versão em produção.

Porque main representa o código estável.

Abrir Pull Request para main

A hotfix corrige imediatamente a versão produtiva.

Depois da aprovação, fazer merge dessa correção também para develop

Existem duas formas comuns:

PR automático do GitHub (bot cria PR de main -> develop)

Ou o desenvolvedor abre manualmente um PR de sincronização

Isso é opcional?

Não, é considerado convencional e altamente recomendado sempre que o time utiliza uma branch develop.

Ignorar isso pode gerar os seguintes problemas:

Reintrodução do bug ao fazer merge de develop em release futuro.

Divergência de código entre main e develop.

Dificuldade de rastreamento, pois hotfixes não aparecem no histórico da release em desenvolvimento.

Considerações finais

Um bom gerenciamento de branches é mais do que uma convenção, é parte essencial da cultura de engenharia de software madura.

Trabalhar com um workflow bem definido baseado no Git Flow permite que o time mantenha consistência, colabore com eficiência e entregue software de qualidade em ciclos ágeis.

Ao aplicar esse processo com disciplina, cada Sprint se torna mais previsível, e o código entregue ganha estabilidade e confiabilidade, o que é o verdadeiro objetivo de um ciclo de desenvolvimento profissional.

Feito!

Sincronizando o seu projeto backend Java (Spring/Quarkus) com JUnit e Mockito no SonarQube

Manter a qualidade de código e medir a cobertura de testes é uma prática essencial em projetos backend modernos. O SonarQube é uma ferramenta robusta para essa finalidade, oferecendo relatórios de bugs, vulnerabilidades, code smells e cobertura de testes unitários.

No presente artigo, vamos configurar o SonarQube para um projeto Java (Spring ou Quarkus) que utiliza JUnit e Mockito, e entender como ignorar pacotes que não envolvem regras de negócio, como Entity, Dto e Repository.

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

1. Subindo o SonarQube com Docker

O primeiro passo é subir o SonarQube localmente com o container oficial:

docker run -d --name sonarqube-backend -p 9000:9000 sonarqube:latest

Após iniciar, acesse o painel em: http://localhost:9000

O login padrão é admin / admin.

Altere a senha e gere um token de autenticação em:

My Account → Security → Generate Tokens

Copie e guarde o token, pois ele será utilizado na integração do projeto.

2. Configurando o projeto backend

   O projeto backend pode ser utilizando o framework Spring Boot ou Quarkus, ambos utilizando Maven como ferramenta de build.

   Certifique-se de que o projeto possui testes unitários configurados com JUnit 5 e Mockito, caso ainda não implementou os testes unitários utilizando JUnit e Mockito (InjectMocks e Mock), implemente para poder continuar com os demais procedimentos a seguir.

3. Configuração no application.properties

Para que o SonarQube consiga autenticar e se comunicar com o projeto, adicione as propriedades de configuração no application.properties:

sonar.host.url=http://localhost:9000 sonar.login=TOKEN_AQUI

Essas configurações permitem que o Maven utilize o token de autenticação diretamente.

4. Arquivo sonar-project.properties

Crie o arquivo sonar-project.properties na raiz do projeto com o seguinte conteúdo:

sonar.projectKey=Projeto-Backend
sonar.projectName=Projeto-Backend
sonar.projectVersion=1.0
sonar.sources=src/main/java
sonar.tests=src/test/java
sonar.language=java
sonar.sourceEncoding=UTF-8
sonar.host.url=http://localhost:9000
sonar.login=TOKEN_AQUI
sonar.branch.name=develop

# Caminho do relatório de cobertura
sonar.junit.reportPaths=target/surefire-reports
sonar.jacoco.reportPaths=target/jacoco.exec
sonar.java.binaries=target/classes

# Ignorar pacotes que não envolvem regra de negócio
sonar.exclusions=**/entity/**,**/model/**,**/dto/**,**/repository/**

A propriedade sonar.exclusions é fundamental para manter o foco da análise nos pacotes de serviços, regras de negócio e controladores, evitando que o SonarQube penalize a cobertura de testes em classes de domínio simples.

5. Configurando o plugin Sonar no Maven

Adicione o plugin SonarQube no arquivo pom.xml caso ainda não esteja presente:

<build>
  <plugins>
    <plugin>
      <groupId>org.sonarsource.scanner.maven</groupId>
      <artifactId>sonar-maven-plugin</artifactId>
      <version>3.10.0.2594</version>
    </plugin>
  </plugins>
</build>

6. Executando os testes e análise

Com tudo configurado, o fluxo para rodar os testes e enviar os resultados ao SonarQube é simples:

Execute os testes unitários:

mvn clean test

Se todos os testes passarem, execute a análise do Sonar:

mvn sonar:sonar

O Maven irá coletar os resultados de cobertura gerados pelo JUnit/Mockito e enviar para o servidor SonarQube, usando o token informado.

7. Visualizando os resultados

Acesse novamente o painel do SonarQube (http://localhost:9000) e verifique seu projeto.

Você verá:

Cobertura de testes unitários (Jacoco)

Code smells e bugs

Duplicações

Segurança e manutenibilidade do código

Os pacotes Entity, Dto e Repository estarão excluídos da cobertura, mantendo o foco nas classes com lógica de negócio.

Considerações finais

Integrar o JUnit + Mockito com o SonarQube é uma das práticas mais eficazes para manter um backend saudável e bem testado.

Ao utilizar o SonarQube em container Docker, a análise fica portátil e fácil de reproduzir em qualquer ambiente.

Essa configuração também é compatível com pipelines CI/CD, permitindo que a análise de qualidade seja automatizada em cada push, garantindo métricas consistentes e rastreabilidade da evolução do código.

Feito!

Sincronizando seu projeto frontend (Angular) com testes unitários (Jest) no SonarQube

Em ambientes corporativos, a análise de qualidade de código e cobertura de testes é essencial para garantir a confiabilidade das aplicações. O SonarQube é uma das ferramentas mais usadas para isso, e pode ser facilmente integrado a projetos Angular com Jest.

No presente artigo, vamos ver o passo a passo para configurar essa integração, incluindo o uso do SonarQube em container Docker, a execução dos testes unitários e a geração de relatórios de cobertura.

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

1. Subindo o SonarQube com Docker

Primeiro, vamos utilizar a imagem oficial do SonarQube. Execute o comando abaixo:

docker run -d --name sonarqube-frontend -p 9000:9000 sonarqube:latest

O SonarQube estará acessível em http://localhost:9000.

No primeiro acesso, o login padrão é admin / admin.

Após logar, altere a senha e gere um token de autenticação no menu:

My Account → Security → Generate Tokens

Guarde esse token, pois ele será utilizado no arquivo de configuração do scanner.

2. Instalando o Jest e o Sonar Scanner

No seu projeto Angular, instale o Jest e o Sonar Scanner globalmente e localmente para garantir compatibilidade:

Instalar o sonar-scanner globalmente

npm install -g sonar-scanner

Instalar o sonar-scanner como dependência de desenvolvimento

npm install --save-dev sonar-scanner

Se o Jest ainda não estiver configurado no projeto Angular:

npm install --save-dev jest @types/jest jest-preset-angular

Em seguida, adicione o script de testes no package.json:

"scripts": {
  "test": "jest --silent",
  "test:coverage": "jest --coverage",
  "sonar": "sonar-scanner"
}

3. Configurando o arquivo sonar-project.properties

   Crie o arquivo sonar-project.properties na raiz do projeto Angular com o seguinte conteúdo:

   
   sonar.projectKey=Nome-Projeto-Frontend
   sonar.projectName=Nome-Projeto-Frontend
   sonar.projectVersion=1.0
   sonar.sources=src
   sonar.language=ts
   sonar.sourceEncoding=UTF-8
   sonar.host.url=http://localhost:9000
   sonar.login=TOKEN_AQUI
   sonar.branch.name=develop
   
   # Diretório de relatórios do Jest
   sonar.javascript.lcov.reportPaths=coverage/lcov.info
   
   

   O campo sonar.javascript.lcov.reportPaths é essencial para que o SonarQube consiga ler a cobertura de testes gerada pelo Jest.

4. Executando os testes e enviando o relatório

Antes de executar o SonarQube, é necessário garantir que os testes unitários estão passando e que o relatório de cobertura foi gerado corretamente.

Execute os testes normalmente:

npx jest --silent

Se todos os testes passarem, gere o relatório de cobertura:

Isso criará uma pasta coverage na raiz do projeto com o arquivo lcov.info dentro de coverage/lcov-report.

5. Enviando os resultados ao SonarQube

Com os testes e cobertura prontos, execute o comando abaixo:

npm run sonar

O sonar-scanner lerá as configurações do arquivo sonar-project.properties e enviará o relatório para o servidor do SonarQube.

Ao finalizar, acesse o painel do SonarQube e verifique as métricas do seu projeto, incluindo:

Qualidade do código TypeScript

Cobertura de testes Jest

Bugs, vulnerabilidades e code smells

Dica: executando no Git Bash (Windows)

Se você estiver no Windows, use o Git Bash para simular um ambiente Linux.

O comando sonar-scanner funciona normalmente nesse terminal, o que facilita a integração em ambientes de desenvolvimento heterogêneos.

Considerações finais

Integrar o Jest com o SonarQube é uma prática que eleva o nível de qualidade do seu projeto Angular.

Essa integração permite visualizar métricas detalhadas, acompanhar a evolução da cobertura de testes e identificar pontos críticos no código.

Com essa configuração, seu pipeline local ou CI/CD estará preparado para medir qualidade de forma contínua, garantindo um código mais limpo, seguro e sustentável.

Feito!