Utilizzo di un "dead man's switch" per gestire il codice sensibile al tempo

Sarei preoccupato per un sistema che rimuove automaticamente il codice. A meno che la tua squadra non sia ben disciplinata, posso solo vederla come una strada per le lacrime e il dolore. Le cose accadono: le persone vanno in vacanza, si ammalano, lasciano la compagnia, dimenticano il codice che sta per scadere, ... e avendo il codice automaticamente ripulito sembra che inviti tutti i tipi di problemi. Dovresti assicurarti che non ci siano dipendenze del compilatore tra questi moduli, oppure potrebbero improvvisamente fallire la compilazione quando qualcosa da cui dipendono viene espirata dall'esistenza. E non dimenticare cosa succederebbe se qualcuno nel supporto di produzione stia lavorando su un vecchio trouble ticket e lo stack trace nel codice di riferimento del messaggio di errore che è stato cancellato. E questo non renderebbe nemmeno le persone che fanno auditing, immagino ...

Qualcosa che potrebbe essere più sicuro è una struttura in cui i vostri piccoli moduli di codice possono interrogare una data di attivazione e una data di disattivazione. Quando il pezzo di codice sta per essere eseguito, verifica in un database le date e se la data corrente è compresa tra la data di attivazione e disattivazione, il framework consente l'esecuzione del codice. E se memorizzi queste date in un database, potresti facilmente scrivere uno script che genererà un rapporto di tutti i moduli che scadrà nei prossimi n giorni, e mandalo via email così è la prima cosa nella tua Posta in arrivo il lunedì mattina.

Questo sistema crea un problema di test orfani: se qualcuno che ha scritto una suite di test e una serie di codici di produzione associati lascia la società, i test rischiano di essere rimossi prematuramente per omissione del loro nuovo proprietario.

Non penso che "troppi test" sia un problema: finché i test sono automatizzati, i tuoi rifiuti sono limitati principalmente alle ore di CPU, il che è un piccolo cambiamento rispetto alle ore di lavoro. Un test rimosso automaticamente dall'interruttore dell'uomo morto potrebbe catturare bug che altrimenti finirebbero nella produzione, causando gravi problemi di manutenzione lungo la strada.

Penso che sia possibile creare un'alternativa basata sui processi creando un registro che accoppi le suite di test con moduli del codice. Ogni volta che viene eseguita una manutenzione su un modulo, il processo richiede la decisione di mantenere / rimuovere / aggiornare la suite di test corrispondente. Poiché si tratta di una contabilità pura, non vi è alcun pericolo che il codice venga rimosso automaticamente dalla lista.

Ho usato da tempo avvisi di calendario semplici (qualsiasi software di calendario utilizzato dalla tua azienda dovrebbe essere sufficiente) in cui l'ho semplicemente impostato per avvisarmi in qualsiasi momento e ho inserito tutte le informazioni di cui ho bisogno presumo che ho dimenticato tutto per il momento dell'avviso si spegne.

Installa un certificato SSL? Guarda la data di scadenza, imposta un evento del calendario per me (e un manager e un altro ingegnere nel caso in cui uno o due dei 3 di noi non siano più con la compagnia, cosa che è accaduta) 2 mesi prima di iniziare a sondare il allarme a chi ha bisogno di essere sostituito, inserire le informazioni di contatto per le persone da cui abbiamo ricevuto il certificato, i luoghi specifici in cui è stato utilizzato il certificato ei dettagli delle ramificazioni sistemiche di lasciarlo scadere (forse è un sistema morto e il certificato dovrebbe scadere quando arriva il momento).

La modifica automatica del codice è un'idea davvero terribile e pericolosa. Tutto quello che devi fare è usare giudiziosamente il tuo calendario per assicurarti di essere informato delle cose sensibili al fattore tempo quando il loro tempo diventa rilevante. Questo è specificamente per cosa sono i calendari. Ora, se hai un problema di non prestare attenzione agli eventi sensibili al tempo in modo responsabile, penso che tu abbia un problema completamente diverso che potresti voler chiedere su il posto di lavoro circa.

Sembra una pessima idea, perché il codice successivo dipenderà da tali modifiche. Il rollback automatico causerà danni diffusi.

Invece, scrivi i tuoi test come test automatici (unità) e eseguili tutti i giorni.