Rastreando refatorações em um banco de dados de bugs

Question

Digamos que você trabalhe em algum lugar onde cada alteração no código-fonte deve ser associada a um relatório de bug ou solicitação de recurso, e não há como reformar essa política.Nesse ambiente, qual é a melhor maneira de lidar com refatorações de código (ou seja, alterações que melhoram o código, mas não corrigem um bug ou adicionam um recurso)?

• Escreva um relatório de bug e associe a refatoração a ele.
• Escreva uma solicitação de recurso e associe a refatoração a ela.
• Mergulhe nas refatorações enquanto trabalha no código associado a um relatório de bug/solicitação de recurso.
• Apenas não faça nenhuma refatoração.
• Outro

Observe que todos os relatórios de bugs e descrições de recursos ficarão visíveis para gerentes e clientes.

Answer 1

Eu voto a favor da abordagem de "refatoração furtiva", que é, acredito, a forma como a refatoração deve ser feita em primeiro lugar.Provavelmente é uma má idéia refatorar apenas para "limpar o código". Isso significa que você está fazendo alterações sem motivo real.Refatorar é, por definição, modificar o sem a intenção de corrigir bugs ou adicionar recursos.Se você estiver seguindo o princípio do KISS, qualquer novo recurso precisará de pelo menos alguma refatoração, porque você não está realmente pensando em como tornar o sistema o mais extensível possível na primeira vez.

Answer 2

Se você estiver trabalhando em um bloco de código, na maioria dos casos é porque há uma correção de bug ou um novo recurso que exige a alteração desse bloco de código, e a refatoração é anterior à alteração para torná-la mais fácil, ou após a mudança para arrumar o resultado.Em ambos os casos, você pode associar a refatoração a essa correção de bug ou recurso.

Answer 3

A forma como trabalhamos é:Deve haver um bom motivo para refatorar o código, caso contrário, por quê?

Se o motivo for permitir que outro recurso use o mesmo código, associe as alterações à solicitação do outro recurso.

Se for para tornar algo mais rápido, crie uma solicitação de recurso para 'xyz' mais rápido e associe as alterações a isso - então os clientes verão que você está melhorando o produto.

Se for para criar um bug, registre-o.

Vale a pena notar que, no meu ambiente, a política não pode ser aplicada.Mas gerentes inteligentes podem obter relatórios de mudanças e se não tiverem uma referência de bug equest no texto do commit, ele será acompanhado.

Answer 4

Vamos dar uma olhada em cada opção:

• Escreva um relatório de bug e associe a refatoração a ele.

Se você acha que, na sua opinião, o código original representa um risco de segurança ou potencial de travamento ou instabilidade.Escreva um pequeno relatório de bug descrevendo o perigo e corrija-o.

• Escreva uma solicitação de recurso e associe a refatoração a ela.

Pode ser mais difícil reator o código com base em uma solicitação de recurso.Mas você poderia usar uma solicitação de recurso válida para fazer isso, o que me leva ao próximo ponto...

• Mergulhe nas refatorações enquanto trabalha no código associado a um relatório de bug/solicitação de recurso.

Se houver um bug ou recurso válido, indique que a função x teve que ser ligeiramente alterada para corrigir o bug ou adicionar o recurso.

• Apenas não faça nenhuma refatoração.

Isso parece sugerir que o autodesenvolvimento por meio do aprimoramento de um aplicativo não é permitido.Os desenvolvedores deveriam ser autorizados, caso contrário, encorajados a explorar novas técnicas e tecnologias.

• Outro

Talvez você possa discutir sua melhoria na reunião relevante, apresentando razões convincentes pelas quais as mudanças deveriam ser feitas.Então, pelo menos, você terá o suporte do gerenciamento para a mudança, sem precisar inserir o código por outro método.

Answer 5

• Outro

Se você trabalha em um local com esse tipo de política inflexível (e ridícula), a melhor solução é procurar outro emprego!