Quando descontinuar e quando excluir em Java

Como parte de um esforço de refatoração ou apenas um desenvolvimento contínuo, um método específico ou talvez uma classe inteira pode se tornar obsoleta em algum sentido. Java suporta a @Deprecatedanotação para indicar que provavelmente existe uma maneira melhor de lidar com a funcionalidade em questão. Eu imagino que isso seja particularmente útil em APIs públicas, onde os efeitos da remoção de partes de uma API podem não ser conhecidos. Para uma API não pública e um projeto que usa sistemas de controle de revisão (para que a exclusão possa ser desfeita em algum sentido), quando é apropriado reprovar em vez de excluir o (s) elemento (s) obsoleto (s)?

Sua API é voltada para o público? Isso determina se você deve ou não descontinuar ou remover. Se a API for estritamente para seu benefício (ou seja, usada apenas dentro da sua empresa), é melhor simplesmente remover o código incorreto. É muito mais limpo e causará menos dores de cabeça de manutenção a longo prazo.

No entanto, se a API estiver voltada para o público, a simples remoção de um método pode fazer com que o código que costumava trabalhar com versões mais antigas da sua biblioteca pare de funcionar. É aí que as coisas ficam confusas. A seguir estão algumas diretrizes:

• API interna: remova em vez de descontinuar. Se algum cliente estiver usando uma classe ou método interno, a culpa será deles se a ferramenta quebrar.
• API externa: descontinue primeiro, remova depois. A descontinuação é uma sinalização de que algo será removido posteriormente. Mais tarde depende do que você acredita ser razoável. No mínimo, forneça 2-3 versões antes de realmente remover o código obsoleto.

Provavelmente, é uma boa ideia configurar um lembrete quando você reprovar uma classe ou método. Você está fazendo isso para promover sua obsolescência. Portanto, adivinhe quanto tempo levará, como um tempo livre, para o que você precisar, para eliminar todas as referências. Marque-o como @ obsoleto e coloque um lembrete no seu calendário. Quando receber o lembrete, verifique. Se não for mais usado, exclua-o. Se ainda houver algumas referências que possam ser atualizadas rapidamente, faça isso e exclua o item. Se um trabalho mais significativo persistir, envie um pouco de lembrete para a frente.

Faça isso o suficiente e você sentirá quanto tempo leva para se livrar de uma classe ou método em seus projetos.

IMHO se você pode garantir que ninguém o esteja usando e nunca usará, basta removê-lo. (Isso pode ser complicado na presença de reflexão, ou componentes externos, como macros Velocity - IDEs modernos, como o IntelliJ, podem encontrar referências em, por exemplo, JSP, mas não por meio de reflexão ou no Velocity.)

Se existe uma alternativa melhor, mas a antiga ainda é usada em muitos lugares, e atualmente você não tem tempo para refatorar todo o código do cliente, é adequado @ reprovar a classe / método obsoleto (com um comentário adequado sobre a alternativa preferida).