Devo registrar correções triviais?

Estou em uma loja de códigos de dois. E embora eu entenda que um rastreador de erros é útil quando o número de programadores é maior ou igual a um, não estou tão convencido de que registrar erros, alterações e correções valha o tempo em que são triviais. Quando encontro um bug simples, eu o entendo, corrijo e executo alguns testes. E então eu percebi que precisava registrá-lo.

Eu sei em teoria que o registro de erros deve ser feito em algum lugar entre encontrar o erro e corrigi-lo, mas se corrigi-lo é mais rápido que registrá-lo, parece uma chatice. Em lojas de códigos maiores, o chefe presta atenção em quem está fazendo o que e é bom saber para onde os outros estão mexendo.

Eu me pego descrevendo coisas que eu já consertei e depois as fecho instantaneamente. Eu tenho dúvidas de que alguém jamais veja esse bug fechado novamente. Está na hora de cortar a gordura do processo?

Você deve registrar todas as alterações feitas no seu sistema. Não há nada errado em registrá-lo após o evento - desde que você vincule o relatório de bug ao número da alteração.

Então, se alguma coisa der errado, você poderá rastrear o bug e descobrir por que você fez a alteração.

Na grande maioria dos casos, você está certo e ninguém nunca mais os examinará, mas em 1 em 100 quando algo der errado, essa informação será inestimável - especialmente se o problema surgir apenas 6 meses depois.

ATUALIZAR

Obviamente, se você ainda estiver desenvolvendo um novo recurso e descobrir um bug em parte do recurso que achou ter concluído, não é necessário registrá-lo como uma alteração separada. Nesses casos, eu o registrava no item que solicita o recurso principal.

Uma vez que o sistema com o recurso foi passado para QA ou o cliente, em seguida, é preciso fazer o que eu descrito acima.

Se você usar uma ferramenta de controle de origem, poderá descrever o bug corrigido na descrição do commit e isso geralmente é documentação suficiente para correções de bugs super pequenas e triviais.

Além disso, se você usar um rastreador de erros / recursos totalmente integrado ao seu controle e repositórios de fontes, como FogBugz e Kiln , poderá usar a ferramenta de pesquisa global para encontrar essas correções e ver quais alterações de código foram feitas. facilmente.

Além disso, você pode atribuir uma revisão de código ao seu parceiro de programação para que ele possa revisar a correção trivial que você fez, mas discordo ...

Do ponto de vista das métricas, ainda pode ser útil.

Esta informação pode ser usada para mostrar ao chefe várias coisas:

• precisamos de mais desenvolvedores
• outra coisa no processo está quebrada (por que tantos bugs? o outro cara gera a maioria dos bugs), talvez mostrando que você tem muitos bugs. Talvez haja algo causando isso? você está liberando muito cedo? testes suficientes estão sendo feitos?
• uma boa lista do que você tem trabalhado é o bônus.

Tudo dito, depende do tamanho do bug que você está falando. Os liners que você encontrar ao adicionar novo código provavelmente não teriam sentido em registrar, por exemplo.

Eu tento registrar todas as alterações que faço, independentemente do tamanho. Você nunca sabe quando você ou alguém (futuro ou presente) precisará voltar e ver se essa mudança é a possível causa de outra coisa.

O rastreamento é importante, mas considere também outro cenário: quando chegar a hora da sua revisão. Isso acontecerá formalmente pessoalmente ou informalmente sem você, por meio do seu chefe, recebendo relatórios do rastreador de erros.

Considere-os 'truques' que acabam aumentando seus números. Afinal, são os erros que você corrigiu e você deve ser reconhecido por corrigi-los, mesmo que sejam triviais.

Registre-os.

Para responder a isso, realmente depende de onde você está no processo.

Isso pode se aplicar a um novo projeto ou a um novo conjunto de recursos que está sendo projetado.

Design inicial Se você encontrar erros no código que criamos durante o design inicial, não será necessário criar uma faixa de erros. Eu sugeriria uma confirmação separada para a alteração, para que você possa desenrolá-la facilmente se encontrar um problema posteriormente.

Teste

Normalmente, o código ainda é considerado imaturo durante o teste de unidade; portanto, a menos que seja feito por um grupo diferente, eu diria que não. Se o teste de unidade for realizado por um grupo diferente de um rastreador de erros, é uma boa maneira de formalizar o procedimento de teste.

O teste CSCI depende. É feito por outro grupo? Se sim, então sim (veja acima). Esta é a última etapa do teste antes do lançamento? Então sim, porque neste momento seu software deve ser considerado maduro. Se você estiver interessado em métricas, também seria bom começar a rastrear bugs neste momento.

Para qualquer nível mais alto de teste, você deve usar o rastreamento de erros. Nesses pontos, seu software deve ser considerado maduro e o rastreamento de bugs é importante.

Lançamento

Você sempre deve rastrear bugs no código liberado. Isso é importante para a prestação de contas.

A racionalização de um processo para atender às suas necessidades também é importante. Você realmente precisa de um enorme sistema de rastreamento de bugs? Todos os campos são realmente importantes para uma equipe de 2 pessoas?

É possível que outra pessoa possa encontrar o bug, talvez em uma versão mais antiga do software lançada no mundo exterior? Nesse caso, o registro do bug e da correção pode ser útil.

Outros sugeriram que, se levar mais tempo para registrar o bug do que para corrigi-lo, não vale a pena registrar. Sugiro que o intervalo de tempo relevante não seja entre encontrar o bug e corrigi-lo, é entre o momento em que o bug foi introduzido e o momento em que a correção foi lançada.

Se o histórico de alterações e liberações indicar que o bug nunca viu a luz do dia, o registro da correção quando você a verifica no controle de origem deve ser suficiente.

Isso está bem próximo dessa pergunta , mas não tenho certeza de que seja uma duplicata, já que esta se concentra em correções triviais .

Por que você não deve rastrear bugs, por Jon Arid Torresdal - conserte-os.

1. Durante o desenvolvimento: você encontra um bug para um recurso; você adiciona um caso de teste que quebra a compilação e verifica a correção no recurso.

2. Após o lançamento: documente o comportamento . Se você planeja lançar uma atualização, vá para 1. Se você não é responsável por essa versão, mantenha o teste + a correção armazenados em uma ramificação particular.

Depois que o código é liberado, pode haver outras prioridades e, embora a correção do bug seja trivial, a distribuição da correção pode não ser econômica por si só, a menos que você esteja fazendo uma implantação contínua.

Depende de quão trivial, eu uso esta medida:

Se demorar mais tempo para registrá-lo do que levou para corrigir isso, ele não é vale a pena registrá-lo.