Usando um "interruptor do homem morto" para gerenciar código com sensibilidade ao tempo

Em nosso ambiente de software, geralmente executamos testes a / b, como provavelmente é uma boa prática. No entanto, nosso ambiente é configurado de modo que, em pouco tempo, o código começa a ficar muito sujo com testes mortos. O registro de teste é pouco mais que uma coleção de páginas internas da wiki.

Pensei no estilo do "interruptor do homem morto" de gerenciamento de código extinto. Se você não estiver familiarizado com o termo, refere-se a uma chave que deve ser redefinida periodicamente para impedir que algo seja acionado - em essência, se você não responder, a chave será acionada e o que você deseja que a chave seja gatilho é realizado.

Por exemplo, eu escrevia algum código, registrava-o neste sistema de alguma maneira e, quando chegava uma data da minha escolha predeterminada, recebia uma notificação de que esse código seria removido (limpo automaticamente), a menos que eu intervenha (manualmente). limpar ou adiar).

Quais são os prós, contras e viabilidade de incorporar esse sistema? É possível ou sábio? Quais podem ser algumas maneiras alternativas de gerenciar código contra rotting?

Eu ficaria preocupado com um sistema que remove automaticamente o código. A menos que sua equipe seja muito bem treinada, só vejo isso como um caminho para lágrimas e dor. As coisas acontecem: as pessoas saem de férias, ficam doentes, saem da empresa, esquecem o que o código que está prestes a expirar faz ... ... e a limpeza automática do código soa como um convite a todos os tipos de problemas. Você precisaria garantir que não houvesse dependências do compilador entre esses módulos, ou eles poderiam falhar subitamente na compilação quando algo de que dependessem expirasse. E não se esqueça do que aconteceria se alguém no suporte à produção estivesse trabalhando em um registro de problemas mais antigo e o rastreamento da pilha na mensagem de erro referencia o código que foi excluído. E isso também não faria as pessoas que fazem auditoria acontecerem, imagino ...

Algo que pode ser mais seguro é uma estrutura em que seus pequenos módulos de código podem consultar uma data de ativação e uma data de desativação. Quando o trecho de código está prestes a ser executado, ele verifica em um banco de dados quais são as datas e se a data atual está entre a data de ativação e desativação, sua estrutura permite que o código seja executado. E se você armazenar essas datas em um banco de dados, poderá escrever facilmente um script que gerará um relatório de todos os módulos que expiram nos próximos n dias e enviar por e-mail para você, para que seja a primeira coisa na sua caixa de entrada na segunda-feira de manhã.

Esse sistema cria um problema de testes órfãos: se alguém que escreveu um conjunto de testes e um conjunto de códigos de produção associados a ele sai da empresa, os testes correm o risco de serem removidos prematuramente por omissão de seu novo proprietário.

Eu não acho que "muitos testes" seja um problema: enquanto os testes são automatizados, seu desperdício é limitado principalmente às horas da CPU, o que é uma pequena mudança em comparação às horas de trabalho. Um teste removido automaticamente pelo interruptor do homem morto pode detectar bugs que acabariam em produção, causando sérios problemas de manutenção no caminho.

Acho que você pode criar uma alternativa baseada em processo, criando um registro emparelhando conjuntos de testes com módulos do seu código. Toda vez que uma manutenção é realizada em um módulo, o processo exigiria a decisão de manter / remover / atualizar o conjunto de testes correspondente. Como se trata de uma contabilidade pura, não há risco de o código ser removido da lista automaticamente.

Há muito tempo que uso alertas simples de calendário (qualquer software de calendário que sua empresa use deve ser suficiente), onde simplesmente o defino para me alertar a qualquer momento e coloco todas as informações necessárias, presumo que eu tenha esquecido tudo quando o alerta disparar.

Instalar um certificado SSL? Observe a data de validade, defina um evento do calendário para mim (e um gerente e outro engenheiro, caso um ou dois de nós já não estejam mais com a empresa, o que aconteceu) dois meses antes de começar a soar o alarme para quem precisar ser substituído, coloque no evento as informações de contato das pessoas de quem recebemos o certificado, os locais específicos em que o certificado é usado e os detalhes das implicações sistêmicas de deixá-lo expirar (talvez seja um sistema morto e o certificado deve expirar quando chegar a hora).

A modificação automática de código é uma ideia absolutamente terrível e perigosa. Tudo o que você precisa fazer é usar criteriosamente o seu calendário para garantir que você seja notificado sobre itens sensíveis ao horário quando o horário deles se tornar relevante. É exatamente para isso que servem os calendários. Agora, se você tem um problema de não atender a eventos sensíveis ao tempo de maneira responsável, acho que você tem um problema completamente diferente que você pode querer perguntar no local de trabalho .

Soa como uma idéia muito ruim, porque o código mais tarde vai depender essas mudanças. A reversão automática causará danos generalizados.

Em vez disso, escreva seus testes como testes automatizados (unitários) e execute-os todas as noites.