A cobertura do código destaca métodos não utilizados - o que devo fazer?

Fui encarregado de aumentar a cobertura de código de um projeto Java existente.

Notei que a ferramenta de cobertura de código ( EclEmma ) destacou alguns métodos que nunca são chamados de qualquer lugar.

Minha reação inicial não é escrever testes de unidade para esses métodos, mas destacá-los para meu gerente / equipe de linha e perguntar por que essas funções existem para começar.

Qual seria a melhor abordagem? Escreva testes de unidade para eles ou pergunte por que eles estão lá?

1. Excluir.
2. Cometer, entregar.
3. Esqueço.

Fundamentação da petição:

1. Código morto está morto. Por sua própria descrição, não tem propósito. Pode ter um objetivo em um ponto, mas isso se foi e, portanto, o código deveria ter desaparecido.
2. O controle de versão garante que, no (na minha experiência) raro evento único, que alguém chegue mais tarde procurando esse código, ele possa ser recuperado.
3. Como efeito colateral, você melhora instantaneamente a cobertura do código sem fazer nada (a menos que o código morto seja testado, o que raramente é o caso).

Advertência a partir dos comentários: A resposta original supunha que você tinha verificado completamente que o código está, sem dúvida, morto. Os IDEs são falíveis e existem várias maneiras pelas quais o código que parece morto pode ser chamado. Traga um especialista, a menos que tenha certeza absoluta.

Todas as outras respostas são baseadas na suposição de que os métodos em questão são realmente não utilizados. No entanto, a pergunta não especificou se esse projeto é independente ou se é uma biblioteca de algum tipo.

Se o projeto em questão for uma biblioteca, os métodos aparentemente não utilizados podem ser usados ​​fora do projeto e removê-los quebraria esses outros projetos. Se a própria biblioteca for vendida aos clientes ou disponibilizada publicamente, pode ser impossível rastrear o uso desses métodos.

Nesse caso, existem quatro possibilidades:

• Se os métodos forem privados ou privados de pacotes, eles poderão ser removidos com segurança.
• Se os métodos forem públicos, sua presença poderá ser justificada mesmo sem uso real, para garantir a integridade dos recursos. Eles devem ser testados embora.
• Se os métodos forem públicos e desnecessários, removê-los será uma mudança significativa e se a biblioteca seguir o controle de versão semântico , isso será permitido apenas em uma nova versão principal.
• Como alternativa, os métodos públicos também podem ser preteridos e removidos posteriormente. Isso dá algum tempo para que os consumidores da API façam a transição das funções obsoletas antes de serem removidas na próxima versão principal.

Primeiro verifique se sua ferramenta de cobertura de código está correta.

Eu tive situações em que eles não perceberam os métodos chamados através de referências à interface ou se a classe é carregada dinamicamente em algum lugar.

Como o Java é compilado estaticamente, deve ser bastante seguro remover os métodos. A remoção de código morto é sempre boa. Há alguma probabilidade de que exista algum sistema de reflexão maluco que os execute em tempo de execução; portanto, verifique primeiro com outros desenvolvedores, mas remova-os.

Qual seria a melhor abordagem? Escreva testes de unidade para eles ou pergunte por que eles estão lá?

Excluir código é uma coisa boa.

Quando você não pode excluir o código, certamente pode marcá-lo como @ Deprecated , documentando qual versão principal você está direcionando para remover o método. Então você pode excluí-lo "mais tarde". Nesse meio tempo, ficará claro que nenhum novo código deve ser adicionado que depende dele.

Eu não recomendaria investir em métodos obsoletos - portanto, não há novos testes de unidade apenas para atingir as metas de cobertura.

A diferença entre os dois é principalmente se os métodos fazem ou não parte da interface publicada . A exclusão arbitrária de partes da interface publicada pode ser uma surpresa desagradável para os consumidores que dependiam da interface.

Não posso falar com EclEmma, ​​mas, pelas minhas experiências, uma das coisas com as quais você precisa tomar cuidado é a reflexão. Se, por exemplo, você usar arquivos de configuração de texto para escolher quais classes / métodos acessar, a distinção usada / não utilizada pode não ser óbvia (fui queimado por isso algumas vezes).

Se o seu projeto for uma folha no gráfico de dependência, o caso de descontinuação será enfraquecido. Se o seu projeto for uma biblioteca, o caso de descontinuação será mais forte.

Se sua empresa usa um mono-repo , a exclusão é um risco menor do que no caso de vários repo.

Conforme observado por l0b0 , se os métodos já estiverem disponíveis no controle de origem, recuperá-los após a exclusão é um exercício direto. Se você estava realmente preocupado com a necessidade de fazer isso, pense em como organizar seus commits para que você possa recuperar as alterações excluídas, se precisar delas.

Se a incerteza for alta o suficiente, considere comentar o código , em vez de excluí-lo. É um trabalho extra no caminho feliz (onde o código excluído nunca é restaurado), mas facilita a restauração. Meu palpite é que você deve preferir uma exclusão direta até que você se queime por isso algumas vezes, o que lhe dará algumas idéias sobre como avaliar a "incerteza" nesse contexto.

pergunta por que eles estão lá?

O tempo investido na captura do conhecimento não é necessariamente desperdiçado. Soube realizar uma remoção em duas etapas: primeiro, adicionando e enviando um comentário explicando o que aprendemos sobre o código e, em seguida, excluindo o código (e o comentário).

Você também pode usar algo análogo aos registros de decisão arquitetônicos como uma maneira de capturar o conhecimento com o código-fonte.

Uma ferramenta de cobertura de código não é onisciente, onisciente. Só porque sua ferramenta afirma que o método não é chamado, isso não significa que não é chamado. Há reflexão e, dependendo do idioma, pode haver outras maneiras de chamar o método. Em C ou C ++, pode haver macros que constroem nomes de função ou método, e a ferramenta pode não ver a chamada. Portanto, o primeiro passo seria: faça uma pesquisa textual pelo nome do método e pelos nomes relacionados. Pergunte a colegas experientes. Você pode achar que é realmente usado.

Se você não tiver certeza, coloque um assert () no início de cada método "não utilizado". Talvez seja chamado. Ou uma declaração de log.

Talvez o código seja realmente valioso. Pode ser um novo código no qual um colega esteja trabalhando há duas semanas e que ele ligará amanhã. Não é chamado hoje porque o pedido será adicionado amanhã.

Talvez o código seja realmente valioso, parte 2: o código pode estar executando alguns testes de tempo de execução muito caros, capazes de descobrir que as coisas estão dando errado. O código é ativado apenas se as coisas realmente derem errado. Você pode estar excluindo uma valiosa ferramenta de depuração.

Curiosamente, o pior conselho possível "Excluir. Confirmar. Esqueça". é o mais alto classificado. (Revisões de código? Você não faz revisões de código? O que você está fazendo de programação se não faz revisões de código?)

Dependendo do ambiente em que o software é executado, é possível efetuar logon se o método for chamado. Se não for chamado dentro de um período de tempo adequado, o método poderá ser removido com segurança.

Essa é uma abordagem mais cautelosa do que apenas excluir o método e pode ser útil se você estiver executando em um ambiente altamente sensível a falhas.

Registramos em um #unreachable-codecanal de folga dedicado com um identificador exclusivo para cada candidato a remoção, e provou ser bastante eficaz.