Você deve corrigir defeitos preexistentes enquanto trabalha em outra coisa?

Enigma: Durante o curso de um novo recurso ou a correção de um defeito, você encontra um problema legado no código. O que você deveria fazer? Corrija e arrisque alterar o comportamento do código. Ele está funcionando até agora por algum acaso, ou então o defeito não foi detectado ou não vale a pena ser relatado por ninguém. Você deve deixá-lo em paz e permitir que o problema torne o código mais difícil de trabalhar posteriormente? A correção do problema aumentará apenas o tempo da tarefa original e forçará você a testar a regressão. Poucos apreciarão o trabalho. Corrigir, no entanto, parece certo de alguma forma. É fácil refatorar e desenvolver códigos com menos problemas.

Eu tenho me encontrado nessa situação várias vezes enquanto trabalhamos para modernizar um aplicativo da web. Não sei dizer se estou sendo obsessivo ou honrado quando saio da tangente trabalhando nesses bugs antigos. Como você lida com essas situações?

Obrigado, Corey

Eu trabalho em uma equipe muito pequena, por isso depende de qual é a mudança:

Se é uma pequena e óbvia correção de bug, eu definitivamente vou em frente. Também faço comentários extras se precisar trabalhar com o código de outra pessoa e outras pequenas melhorias que se enquadram na "regra do escoteiro" para mim.

Se o código está tão entrelaçado que você precisa perguntar "Isso mudará alguma coisa e exigirá testes", então não, você não deve alterá-lo. Traga-o para o seu sistema de rastreamento de bugs, caso isso o preocupe.

Aliás, é por isso que eu tento codificar métodos menores com assinaturas de tipo mais óbvias também. Se você sabe que não há efeitos colaterais e pode fazer com que as entradas e saídas correspondam, você pode corrigir, reorganizar ou ajustar qualquer código interno sem risco.

Mas não pense que a falta de apreço seja uma razão para não corrigir os erros encontrados ou melhorar a base de código por qualquer motivo. Se nada mais, você está sendo gentil com o futuro, que certamente voltará lá para consertar outra coisa.

Edição: Você também precisa assistir o seu tempo no projeto. Obviamente, com prazos apertados, você precisa se concentrar em realizar o trabalho principal, mas se você estiver com "carga normal", acho que um pouco de limpeza aqui e ali deixa todo mundo mais feliz a longo prazo.

Como sempre, depende.

• Se for trivial e você tiver certeza de que pode consertá-lo, conserte-o.
• Se houver muitos testes de unidade, para ter certeza de que não quebrou nada, corrija-o.
• Caso contrário, adicione um // TODO, adicione-o ao rastreamento de erros, qualquer que seja

Basicamente, você está fazendo uma avaliação de risco: qual é o risco de mudar ou não mudar. Se você não tiver experiência suficiente (com programação em geral ou o sistema em particular), pergunte a outra pessoa da equipe.

O programador pragmático chama isso de 'Windows quebrado'.

Se você não consertar janelas quebradas, é provável que elas criem uma espiral descendente da qualidade do código. E quanto mais deles, maior é a tarefa de corrigi-los e, portanto, é menos provável que eles sejam corrigidos.

A decisão de corrigi-los agora ou mais tarde depende de julgamento. É uma correção simples? Você tem certeza de que o código está fazendo o que você pensa que é? É provável que distraia sua tarefa atual? Você está com restrições de tempo? É provável que apresente mais bugs?

No mínimo, marque o item no seu sistema de rastreamento e verifique se ele será corrigido mais tarde. É importante marcá-lo no sistema de rastreamento, mesmo se você decidir corrigi-lo agora, para garantir que ele também seja testado e para documentar as alterações.

Se for um bug óbvio, como algo que viola a segurança, corrompe dados ou gera uma exceção exibida ao usuário, corrija-o. Caso contrário, pergunte a alguém que conhece melhor a base de código que você.

Depende, se é um pequeno bug em que você tem certeza de que sua correção tem baixo impacto, pessoalmente, eu a corrigiria como parte do outro trabalho e depois informaria o PM.

Se houver algum risco para o cliente, usuários ou empresa, fale com o gerente de projeto e discuta um curso a seguir. O trabalho deles é avaliar o risco, de modo a chamar a atenção deles e o caso de corrigi-lo. Então honre sua decisão.

Nossos testadores odeiam isso. A menos que seja muito trivial, nós o registramos no banco de dados de bugs, depois o alocamos para uma liberação e escrevemos testes de regressão. Se os desenvolvedores estão apenas fazendo alterações que não estão dentro do cronograma, como você pode manter um prazo?

Estive em equipes nas quais defeitos não críticos ou violações-padrão são enviados como um defeito "Código Fraco". Eu diria que a pessoa que encontra um defeito crítico tem a responsabilidade de lançar algum tipo de bandeira

isso depende do bug. a principal preocupação é a introdução de novos bugs. Melhor lidar com um problema conhecido do que com um desconhecido. Se for simples, digamos, uma alteração de texto ou um simples erro lógico, nós o corrigimos, caso contrário, deixe-o em paz.

Uma coisa a notar, embora, nós somos uma pequena loja de 4 desenvolvedores e um estagiário, e o bug que eu conserto é provavelmente o bug que eu criei.

Se o código estiver obviamente errado, a correção é bastante simples e você acredita que o risco de impactar os usuários é baixo, então faça isso. Tudo se resume ao julgamento profissional.

Você deve se lembrar, no entanto, de que, se você o encontrou, presumivelmente os usuários não o encontraram, ou então eles o teriam denunciado. Em vez de gastar tempo corrigindo um problema que talvez nunca seja encontrado por um usuário, é melhor gastar esse tempo corrigindo problemas que estão causando problemas aos seus usuários agora.

Bem, documente as observações primeiro e decida se será corrigido mais tarde.

Converse formalmente (por exemplo, na reunião regular) ou informal (por exemplo, durante o almoço) com seus colegas e faça as alterações depois que você ganhar mais confiança no comportamento dos códigos que irá corrigir.

Embora pareça um bug / defeito para você, desta vez pode ser um "recurso". Pode ser uma solução mal implementada para contornar alguns casos extremos no último minuto da versão anterior, e sua "correção limpa" pode reviver alguns problemas resolvidos anteriormente.

Eu vou mudar a tendência aqui. A menos que você esteja na fase inicial de desenvolvimento do protótipo, você nunca deve corrigi-lo imediatamente, deve registrar um bug. Isso tem várias vantagens:

• a equipe começa a avaliar. É um bug real, quais são os riscos de corrigi-lo.
• a gerência decide se é importante o suficiente para assumir o impacto do cronograma de incluí-lo nesta versão
• um método para detectá-lo pode ser adicionado ao conjunto de testes, esperançosamente de uma maneira geral o suficiente para também encontrar erros semelhantes.
• fornece métricas valiosas sobre quantos bugs estão passando pelas fases anteriores