Como determinar a prioridade e a gravidade de um "aprimoramento de código"?

Temos campos "prioridade" e "gravidade" em nosso sistema de rastreamento de bugs. Definimos gravidade como "como isso afeta o usuário" e prioridade como "como isso afeta o produto".

Minha pergunta é sobre como categorizar uma tarefa de "aprimoramento de código" em gravidade e prioridade. Suponha que a melhoria não mude nenhum comportamento, mas a torne um "código melhor". Prevemos uma melhoria geral da manutenção a longo prazo, mas é difícil quantificá-la.

Quando usamos nossas definições de prioridade e gravidade, uma melhoria de código obtém os valores mais baixos para ambos, a menos que você introduza alguns benefícios difíceis de prever a longo prazo. Portanto, implica que o aprimoramento do código é uma tarefa privilegiada e nunca deve ser tentada.

No entanto, acredito que é crucial melhorar e refatorar constantemente o código, porque:

• O desenvolvimento de software é, por si só, um processo contínuo de aprendizado e, sem melhorar o código, você não pode melhorar.
• Uma equipe deve se orgulhar de seu código.
• A manutenção futura levará menos tempo e, a longo prazo, a economia será significativa.

Ou você acha que essas tarefas nunca devem ser criadas e que essas melhorias são executadas apenas "sob demanda", "quando associadas a um bug"? Mesmo se estiver associado a um bug, isso não seria um ponto de discussão em uma revisão de código, por exemplo, "por que você fez essa mudança drástica na estrutura?".

Normalmente, eu não gosto de ver as atividades de "aprimoramento de código" como uma tarefa atribuível separada porque a melhoria de código nunca o aproxima diretamente da conclusão de requisitos ou histórias de usuários. É por isso que as tarefas de aprimoramento de código sempre serão de baixa prioridade e nunca são atribuídas.

Vejo o aprimoramento de código como uma constante, algo que todo desenvolvedor deve fazer tão naturalmente quanto digitar em um teclado. Eu o levo em minhas estimativas para qualquer tarefa. Se minha tarefa me envolver tocando em uma classe ou em algum código-fonte que não seja analisado há muito tempo, assumirei que algum trabalho de zeladoria provavelmente está em ordem e aumentarei minha estimativa de acordo.

Na melhor das hipóteses, concluo a tarefa mais cedo e posso usar o tempo restante para aprimorar o código ou até o design. No pior cenário, a tarefa leva muito mais tempo do que o esperado, mas eu tenho esse tempo extra como buffer.

Se você deseja refatorar seu código, defina a prioridade da tarefa de acordo com sua definição (por exemplo, "como isso afeta o produto"). Algumas refatorações não afetam muito o produto e outras, dependendo do escopo do trabalho necessário. Definir uma prioridade mais alta indicará que mais testes serão necessários após a refatoração ser concluída para garantir que nada inesperado ocorra.

Você também pode querer introduzir uma nova categoria no seu sistema de rastreamento de bugs para categorizar esses tipos de tarefas como tarefas de "Refatoração". Dessa forma, você saberá como interpretar o valor da prioridade; isto é, maior prioridade significa maior impacto e, portanto, é necessário mais teste.

O que está faltando é verificar suas suposições sobre o código existente: menos tempo e economia significativa podem ser alcançados se melhorarmos o código. É cosmético ou há problemas sérios?

Verifique suas estimativas de depuração e aprimoramento. Se eles estiverem demorando mais e houver comentários contínuos sobre a necessidade de refatorar o código primeiro ou limpá-lo, essa pode ser sua melhor medida. Em seguida, você pode identificar sua base de códigos como: Bom, precisa de um pequeno retrabalho ou de uma refatoração séria.

Tudo isso é relativo. É difícil dar essa alta prioridade quando há clientes que desejam mais recursos e desejam pagar imediatamente pelas horas faturáveis.

Pergunta interessante.

Eu acho que você teria que estimar quantas linhas de código e quantos módulos essa alteração pode afetar.

Talvez você possa ver quantos testes de unidade, se os tiver, serão quebrados ao fazer a alteração. Provavelmente, isso significaria tentar primeiro a alteração em um ramo para ter uma ideia.

Em seguida, tenha limites para esses níveis correspondentes prioridade e gravidade.

Você também deve levar em consideração que muitos testes de testador precisarão estar envolvidos. Se a alteração tocar em uma grande área de superfície do aplicativo, poderá ser necessário revisar muitos testes do sistema.

Vamos começar com duas suposições aqui.

1. Para cada nova história, você escreve seu código da melhor maneira possível, possivelmente reforçado com o conhecimento ambiental de sua equipe.
2. Sempre que houver uma história que altere a funcionalidade do código existente, use seu novo conhecimento do sistema e melhores habilidades para melhorar o código no processo de implementação da nova história.

Dadas essas duas suposições, nunca há necessidade de um esforço explícito de "aprimoramento de código". Seu código melhora à medida que você escreve o sistema. Isso significa que nem todo o código está de acordo com os melhores e mais recentes padrões de manutenção, mas "Se não estiver quebrado, não conserte". Considero que o código de refatoração que não precisa ser alterado para ser "banhado a ouro", além de adicionar funcionalidades visíveis desnecessárias. Se o código estiver quebrado de alguma forma, escreva um teste válido que falhe; registrar um bug; e refatorar para resolver esse bug.

Eu roubaria a votação do movimento Agile:

Digite o bug, faça palpites sobre severidade e prioridade,

Em seguida, revise diariamente, semanalmente ou mensalmente todos os novos bugs e vote nas classificações. Idealmente, você faz isso durante uma reunião de planejamento de sprint com os usuários finais. Você também pode falar sobre os próximos recursos naquele momento e ser positivo,