Usar un "interruptor de hombre muerto" para administrar el código urgente

En nuestro entorno de software, a menudo ejecutamos pruebas a / b, como probablemente sea una buena práctica. Sin embargo, nuestro entorno está configurado de tal manera que, en muy poco tiempo, el código comienza a ser muy difícil con las pruebas muertas. El registro de pruebas es poco más que una colección de páginas wiki internas.

Pensé en el estilo de un "interruptor de hombre muerto" de gestión de código difunto. Si no está familiarizado con el término, se refiere a un interruptor que debe reiniciarse periódicamente para evitar que algo se dispare; en esencia, si no responde, el interruptor se dispara y lo que sea que desee que cambie. Se realiza el gatillo.

Por ejemplo, escribiría algún código, lo registraría de alguna manera con este sistema, y ​​cuando aparezca una fecha de mi elección predeterminada, recibiría una notificación de que este código se eliminaría (se limpiaría automáticamente) a menos que interviniera (manualmente limpiar o posponer).

¿Cuáles son los pros, los contras y la viabilidad de incorporar dicho sistema? ¿Es posible o sabio? ¿Cuáles podrían ser algunas formas alternativas de administrar el código contra la descomposición?

Me preocuparía un sistema que elimine automáticamente el código. A menos que su equipo esté muy bien disciplinado, solo puedo ver esto como un camino hacia las lágrimas y el dolor. Las cosas suceden: la gente se va de vacaciones, se enferma, deja la empresa, olvida lo que hace el código que está a punto de caducar, ... y hacer que el código se limpie automáticamente suena como si invitara a todo tipo de problemas. Tendría que asegurarse de que no hay dependencias del compilador entre estos módulos, o podrían fallar repentinamente en la compilación cuando algo de lo que dependen expire fuera de existencia. Y no olvide lo que sucedería si alguien en el soporte de producción está trabajando en un ticket de problema anterior y el seguimiento de la pila en el mensaje de error hace referencia al código que se eliminó. Y esto tampoco haría que las personas que realizan auditorías tengan mucho éxito, me imagino ...

Algo que podría ser más seguro es un marco donde sus pequeños módulos de código pueden consultar una fecha de activación y una fecha de desactivación. Cuando el código está a punto de ejecutarse, verifica en una base de datos cuáles son las fechas y si la fecha actual está entre la fecha de activación y desactivación, su marco permite que el código se ejecute. Y si almacena estas fechas en una base de datos, puede escribir fácilmente un script que generará un informe de todos los módulos que vencen en los próximos n días y se lo enviará por correo electrónico para que sea lo primero en su bandeja de entrada el lunes por la mañana.

Este sistema crea un problema de pruebas huérfanas: si alguien que escribió un conjunto de pruebas y un conjunto de código de producción asociado a él abandona la empresa, las pruebas corren el peligro de ser eliminadas prematuramente por omisión de su nuevo propietario.

No creo que "demasiadas pruebas" sea un problema: siempre que las pruebas estén automatizadas, su desperdicio se limita principalmente a las horas de CPU, que es un cambio pequeño en comparación con las horas hombre. Una prueba eliminada automáticamente a través del interruptor del hombre muerto podría detectar errores que de lo contrario terminarían en producción, causando graves problemas de mantenimiento en el futuro.

Creo que puede crear una alternativa basada en procesos creando un registro que combine conjuntos de pruebas con módulos de su código. Cada vez que se realiza un mantenimiento en un módulo, el proceso requeriría tomar una decisión sobre mantener / eliminar / actualizar el conjunto de pruebas correspondiente. Como se trata de una contabilidad pura, no hay peligro de que el código se elimine de la lista automáticamente.

Durante mucho tiempo he usado alertas de calendario simples (cualquier software de calendario que use su empresa debería ser suficiente) donde simplemente lo configuré para que me avise en cualquier momento y pongo toda la información que necesitaré, supongo que olvidé todo cuando suena la alerta.

Instalar un certificado SSL? Mire la fecha de vencimiento, establezca un evento de calendario para mí (y un gerente y otro ingeniero en caso de que uno o 2 de los tres ya no estemos con la compañía, lo que ha sucedido) 2 meses antes de eso para comenzar a sonar el alarma a quien sea que deba reemplazarse, poner en caso de que la información de contacto de las personas de las que recibimos el certificado, los lugares específicos en los que se usa el certificado y los detalles de las ramificaciones sistémicas de dejar que caduque (tal vez sea un sistema muerto y el certificado debe expirar cuando llegue ese momento).

La modificación automática del código es una idea francamente terrible y peligrosa. Todo lo que necesita hacer es usar juiciosamente su calendario para asegurarse de que se le notifiquen las cosas urgentes cuando su tiempo se vuelva relevante. Esto es específicamente para lo que son los calendarios. Ahora, si tiene un problema de no prestar atención a los eventos sensibles al tiempo de una manera responsable, creo que tiene un problema completamente diferente sobre el que podría preguntar en el lugar de trabajo .

Suena como una muy mala idea, ya que el código más tarde será dependerá de esos cambios. La reversión automática causará daños generalizados.

En cambio, escriba sus pruebas como pruebas automatizadas (unitarias) y ejecútelas todas las noches.