O problema de adicionar um comentário a um arquivo que deve ser excluído, em vez de excluí-lo no controle de origem e colocar a explicação nele, pressupõe que, se os desenvolvedores não lerem mensagens de confirmação, eles certamente lerão comentários na origem código.
Do ponto de vista de um estranho, essa metodologia parece estar enraizada em uma visão muito conservadora do controle de origem.
"E se eu excluir esse arquivo não utilizado e alguém precisar dele?" alguém pode perguntar.
Você está usando o controle de origem. Reverta a mudança ou, melhor ainda, fale com a pessoa que apagou o arquivo (comunicar).
"E se eu deletar o arquivo morto, então alguém começa a usá-lo novamente e eles fazem alterações?" alguém pode perguntar.
Novamente, você está usando o controle de origem. Você terá um conflito de mesclagem que uma pessoa deve resolver. A resposta aqui, como na última pergunta, é se comunicar com seus colegas de equipe.
Se realmente duvida que um arquivo deve ser removido, comunique-o antes excluindo-o do controle de origem. Talvez ele tenha parado de ser usado recentemente, mas um recurso futuro pode exigir isso. Você não sabe disso, mas um dos outros desenvolvedores pode.
Se precisar ser removido, remova-o. Cortar a gordura da base de código.
Se você fez um "oopsie" e realmente precisa do arquivo, lembre-se de que está usando o controle de origem para recuperar o arquivo.
Vincent Savard, em um comentário sobre a questão, disse:
... If your colleagues don't read the commit messages and they resurrect a file that was rightfully deleted and it passes code reviewing, there's definitely something wrong in your team, and it's a great opportunity to teach them better.
Este é um bom conselho. Revisões de código deveriam estar pegando esse tipo de coisa. Os desenvolvedores precisam estar consultando mensagens de confirmação quando uma alteração inesperada é feita em um arquivo ou um arquivo é removido ou renomeado.
Se as mensagens de confirmação não contar a história, os desenvolvedores também precisarão escrever melhores mensagens de confirmação.
Ter medo de excluir códigos ou excluir arquivos é indicativo de um problema sistêmico mais profundo com o processo:
- Falta de comentários precisos sobre o código
- Falta de compreensão sobre como o controle de origem funciona
- Falta de comunicação da equipe
- Mensagens de comprometimento insuficientes por parte dos desenvolvedores
Esses são os problemas a serem resolvidos, então você não sente que está jogando pedras em uma estufa quando apaga código ou arquivos.