Devo remover código não referenciado?

Estou trabalhando em uma base de código de tamanho médio (100k linhas), é tudo relativamente recente (menos de um ano) e tem uma boa cobertura de teste de unidade.

Eu continuo encontrando métodos que não são mais usados ​​em lugar nenhum ou apenas são referenciados em testes de unidade que apenas testam esse método específico.

Devo remover esse código se tiver certeza de que não é mais necessário?

Razões para removê-lo:

• Menos código, menos bugs
• Menos código é mais fácil para outros digerirem
• Ainda está sob controle de origem

Razões para mantê-lo:

• Pode ser usado como referência
• Pode ser útil em algum momento
• Pode ter sido escrito para 'arredondar' a funcionalidade de uma classe

A maioria de suas razões para mantê-lo é totalmente irrelevante, simplificando. Se o código não for usado, jogue-o fora - qualquer benefício envolvido em mantê-lo pode ser derivado trivialmente do controle de origem. No máximo, deixe um comentário dizendo em qual revisão a encontrar.

Simplesmente, quanto mais cedo você cortar o código, mais cedo não precisará perder tempo mantendo-o, compilando-o e testando-o. Essas vantagens superam maciçamente os benefícios triviais que você descreveu, os quais podem ser derivados do controle de origem de qualquer maneira.

Todos os motivos para removê-lo permanecem.

Razões para mantê-lo:

• Pode ser usado como referência
• Pode ser útil em algum momento
• Pode ter sido escrito para 'arredondar' a funcionalidade de uma classe

Todos esses motivos para mantê-lo serão gerenciados pelo controle de origem. Remova-o do código ativo e você poderá recuperá-lo se / quando for necessário.

Código não referenciado é o mesmo que manter aquelas baterias que estão meio que gastas, caso você precise delas um dia para uma tocha.

Contanto que você esteja usando algum tipo de controle de versão, eu diria que o retirará do código ativo e usará o histórico de versões, caso seja útil.

A única boa razão para manter um código que não é usado no momento é se ele faz parte de um módulo independente: Embora algumas partes do código possam não ser usadas no momento, pode ser que elas sejam usado no futuro.

Isso pode ser especialmente verdadeiro para uma biblioteca que você usa em diferentes projetos: você não deseja continuar inserindo e retirando trechos de código, de acordo com o que você precisa para um projeto específico: Eu acho isso demorado e propenso a erros.

Minha abordagem é: (1) se você a usar uma vez, mantenha apenas o que realmente precisa; (2) se você usá-lo duas vezes, copie e adapte-o na segunda vez que o usar; (3) se você usá-lo mais de duas vezes, faça um módulo estável e bem definido com ele, e use este módulo conforme necessário.

Resumindo: eu descartaria todo o código não utilizado, a menos que faça parte de um módulo de uso geral que você tenha projetado como tal e que saiba que vai reutilizar várias vezes.

Nota : Obviamente, uma solução ainda mais limpa seria criar um projeto separado para uma biblioteca e adicionar uma dependência entre os projetos.

Geralmente, eu me curvaria a YAGNI sobre isso. Se "você não vai precisar disso", está simplesmente ocupando espaço em sua base de código, testes de unidade e montagens. Você pode acabar precisando, mas também pode precisar reescrevê-lo completamente, porque entre agora e quando precisar de algo assim, muita coisa pode mudar.

No entanto, isso muda um pouco quando você está escrevendo um utilitário ou API destinado ao consumo geral. Assim como você nunca pode esperar que os usuários finais do software interajam com o software da maneira que você pretendia, você nunca pode esperar que os consumidores do seu código desejem usá-lo exatamente da maneira que você acha que eles deveriam. Nesses casos, desde que você possa justificar a existência de um método com "é uma maneira válida de querer interagir com meu objeto", provavelmente deve entrar, porque mesmo que você não precise, as chances são boas de que alguém .

Dado que a base de código tem menos de um ano, provavelmente ainda está com muito fluxo (sim?) - portanto, a noção de que alguns bits talvez precisem ser ressuscitados em um futuro próximo não é irracional.

Para os bits que eram difíceis de acertar em primeiro lugar e parecem mais suscetíveis de serem ressuscitados, eu os manteria um pouco mais "ativos" do que apenas no controle de origem. As pessoas não sabem / lembram que elas existem - dizer "você pode encontrá-lo apenas no controle de origem" pressupõe que você sabe / lembra que está lá! Nesses tipos de casos, considere a descontinuação (com um limitador de "afirmação (falso)") ou comentário.

Se o código é trivial e desinteressante, eu apenas o jogo fora para livrar-me da inércia desnecessária do sistema de software.

Para cadáveres de código interessantes, eu uso uma archiveramificação em meus sistemas de controle de versão.

"Pode ser usado como referência" Eu não tenderia a concordar em ser um bom motivo para deixar código não utilizado. Muitas vezes, apenas uma pequena parte do código não utilizado está realmente demonstrando algo interessante. Existem várias maneiras de documentar e armazenar código útil, mas não utilizado.

Embora o controle de versão contenha um histórico que permita restaurar facilmente uma funcionalidade específica, se você decidir mais tarde o código, sabendo que é necessário procurar no histórico de controle de versão para encontrar xy ou z de quem sabe qual revisão anterior pode ser um pouco entediante e geralmente é ignorado, a menos que você tenha uma idéia bastante específica do que está procurando.

O código pode ser comentado com uma nota sobre quando foi removido e por que não foi simplesmente excluído do código. No entanto, isso geralmente é considerado um estilo inadequado, e o código que não é usado e não é mantido adequadamente pode apresentar todos os tipos de erros, se não for comentado posteriormente; portanto, isso geralmente é melhor como uma etapa temporária de depuração / teste durante a refatoração intermediária do que uma maneira de deixar o código de produção.

Minha maneira favorita de armazenar o código excluído, se parecer útil no futuro, é criar um documento de referência secundário contendo todos os vários fragmentos de código excluído que vale a pena. Cada bloco de código é rotulado com uma breve menção de onde veio ou qualquer outra coisa pertinente para lembrar, como quando foi removido ou o número da revisão em que foi o último no código em. Tudo o que foi removido, mas "potencialmente útil", está em um só lugar, facilmente pesquisável, mas não exige esforço constante para manter e testar continuamente (esse teste é adiado para qualquer ponto em que o código for reintroduzido).

Uma boa razão para manter os métodos não utilizados é: eles podem ser usados ​​em outros ramos / tags!

Explore todos os seus ramos e tags ativos antes de removê-los.

Se você usa um sistema de controle de versão, não se preocupe com futuras referências, pois você pode ver através do histórico desse código e encontrar a parte excluída. Se você não o fizer e acha que seria usado algum dia, deixe-o ficar lá, mas comente com uma descrição explicando por que ele foi comentado.

No entanto, se tiver certeza de que não o usará no futuro, basta removê-lo . Acho que os motivos que você mencionou são bastante simples para a remoção do código.

Mas antes de removê-lo, verifique se ele não é usado em nenhum lugar. O Visual Studio possui um recurso chamado Localizar todas as referências, que pesquisa toda a solução e encontra qualquer referência à variável atual, método, propriedade, classe, interface etc. Sempre verifique se não há nenhuma referência antes de remover parte do meu código.

Com relativa frequência, tive a experiência de encontrar uma função que parece que fará exatamente o que eu preciso e confiando que ela funcione desde que esteja em produção há muito tempo, apenas para descobrir que ela não foi realmente usada em muitos anos. O código que não é usado não é mantido e, embora possa ter funcionado anos atrás, a API ao redor foi alterada o suficiente para que você não possa confiar.

Na melhor das hipóteses, você acaba gastando muito tempo se certificando de que ainda faz o que deseja. Na pior das hipóteses, parece funcionar até que você seja mordido com um bug desagradável mais tarde e demore mais para encontrá-lo, porque você assumiu que o código "testado em produção" funciona, então o problema deve estar em outro lugar no seu novo código. Na minha experiência, é quase sempre mais rápido escrever uma nova função.

Se você excluí-lo, mas descobrir relativamente cedo que realmente precisa dele, estará lá no controle de origem. Se você não precisar dele até que tenha passado tanto tempo que não se lembre do controle de origem, provavelmente será melhor escrevê-lo do zero de qualquer maneira.

Nada consome menos tempo que nenhum código.

Se você precisar mergulhar em uma base de código, precisará de algum tempo para descobrir para que serve esse código e, se for usado para nada, precisará de ainda mais tempo.

Ok - isso pode ser curado, é um comentário, mas, novamente, todos pensarão sobre por que esse código não utilizado ainda está na base de código, se deve ser removido ou não.

Se não houver nada, ninguém perderá tempo com isso.

Se foi difícil acertar, você precisa de uma boa documentação, de que esse código exista, mas se a base de código evoluir em algumas iterações, talvez não funcione mais, se for reativada.

Remova o código não utilizado - menos confusão, melhor entendimento. Seu sistema de controle de versão cuidará. Além disso, se você estiver usando algo melhor que o bloco de notas, seu ambiente permitirá que você use código antigo para referência.

Comentários longos do código antigo são perturbadores e dificultam a navegação.

Saudações

Siga este algoritmo simples:

1. É feito backup em um SCM? Se sim, pule para 3.
2. Configure um SCM.
3. Jogue o material fora .

Todos os seus pontos a favor da remoção são válidos.

Todos os seus pontos a favor de manter a bagunça são inválidos quando você tiver um SCM para procurá-la ou restaurá-la. Na verdade, seu SCM deve poder ajudá-lo a determinar por que esse código está aqui e sem uso, se foi usado corretamente.

É chamado de "código morto" por um motivo. Deixe morrer e descanse em paz.

Ele permanecerá no controle de origem; não deve permanecer na base de código ativa.

A única exceção é se o código concluir o design e enquanto você não estiver usando o código, você planeja eventualmente tornar o código público e outras pessoas podem querer essa funcionalidade básica. Em seguida, apenas crie testes para garantir que essas partes do código funcionem, imitando como você propõe que outras pessoas possam usar essas partes do código. No entanto, se você está pensando em excluir o código e não consegue encontrar um motivo sólido para mantê-lo, ele deve continuar. O código não utilizado cria mais trabalho para todos (é mais difícil ler o código; o código pode estar quebrado; mais trabalho para manter; etc.)

Na minha experiência, remover o código não utilizado também pode sair pela culatra. Você pode esquecer que tinha esse código e não o procurará na história. Ou talvez você nem saiba que alguém implementou esse código e o removeu posteriormente. Novamente, você não o procurará na história ...

Sem dúvida, ter código não utilizado é um mau cheiro.

ATUALIZAÇÃO: Acabei de perceber que Ed Staub deu uma resposta muito semelhante.