Ao trabalhar em projetos maiores, é crucial evitar situações em que vários desenvolvedores estejam abordando o mesmo problema sem saber. Isso pode levar a esforços desperdiçados e possíveis conflitos na base de código. Para evitar isso:
- Sempre registre bugs em seu sistema de rastreamento de problemas. Antes de começar a trabalhar em um bug, certifique-se de que ele esteja atribuído a você e marcado como ativo. Essa visibilidade permite que o gerente do projeto e demais membros da equipe fiquem atentos, reduzindo as chances de sobreposição de trabalhos.
- Fique atualizado sobre outros assuntos. Ao ficar de olho nos problemas que seus colegas de equipe estão enfrentando, você pode antecipar possíveis áreas de conflito e ajustar sua abordagem de acordo.
Supondo que você tenha uma sessão de sincronização diária ou mesmo semanal, é importante discutir os problemas. Isso evita colisão, onde um colega de equipe pode ouvir a descrição do bug e levantar uma ideia. Isso também ajuda a identificar a causa raiz do bug em algumas situações.
O valor do problema em relação às solicitações pull
Às vezes, escrevemos os comentários e as informações diretamente na solicitação pull, em vez de no rastreador de problemas. Isso pode funcionar para algumas situações, mas não é tão ideal para o caso geral.
Os problemas em um sistema de rastreamento costumam ser mais acessíveis do que solicitações pull ou commits específicos. Ao abordar uma regressão, é vital vincular a solicitação pull ao problema de origem. Isso garante que todas as discussões e decisões relacionadas ao bug sejam centralizadas e facilmente rastreáveis.
O papel das reuniões diárias
As reuniões diárias são inestimáveis para equipes com vários desenvolvedores trabalhando em tarefas relacionadas. Essas reuniões fornecem uma plataforma para:
- Compartilhando atualizações: informe a equipe sobre suas teorias e orientações atuais.
- Envolver-se em discussões: se a atualização de um colega lhe parecer familiar, é uma oportunidade para colaborar e evitar trabalho redundante.
No entanto, é essencial manter essas reuniões concisas. As discussões detalhadas devem ser transferidas para o rastreador de problemas para um registro abrangente.
O papel dos testes na depuração
Uma abordagem comum para depuração é começar criando um teste de unidade que reproduza o problema. No entanto, isso pode nem sempre ser viável antes de compreendê-lo. No entanto, uma vez compreendido o problema, devemos:
- Crie um teste antes de corrigir o problema. Este teste deve fazer parte da solicitação pull que aborda o bug.
- Mantenha um índice de cobertura. Procure uma taxa de cobertura de 60% ou superior por solicitação pull para garantir que as alterações sejam testadas adequadamente.
Um teste atua como uma proteção contra uma regressão. Se o bug reaparecer, será uma variante ligeiramente diferente do mesmo bug.
Testes de Unidade vs. Testes de Integração
Embora os testes unitários sejam rápidos e forneçam feedback imediato, eles evitam principalmente regressões. Eles podem não ser tão eficazes na verificação da qualidade geral. Por outro lado, os testes de integração, embora potencialmente mais lentos, oferecem uma verificação de qualidade abrangente. Às vezes, eles podem ser a única maneira de reproduzir certos problemas. A maioria dos bugs difíceis de encontrar estão na área de interconexão entre módulos. Esta é uma área que os testes unitários não cobrem muito bem. É por isso que os testes de integração são muito mais importantes que os testes unitários para a qualidade geral do aplicativo.
Para garantir a qualidade, concentre-se em testes de integração para cobertura. Depender apenas da cobertura de testes unitários pode ser enganoso. Isso pode levar a código morto e aumentar a complexidade do sistema. No entanto, como parte do processo de depuração, é muito valioso ter um teste de unidade, pois é muito mais fácil e rápido de depurar.
