Impedisci la compilazione del codice obsoleto dopo aver raggiunto una scadenza [chiuso]

Nel mio team abbiamo ripulito molte cose vecchie in un grande progetto monolitico (intere classi, metodi, ecc.).

Durante le attività di pulizia mi chiedevo se ci fosse una sorta di annotazione o libreria più elaborata del solito @Deprecated. Ciò @FancyDeprecateddovrebbe impedire il completamento della compilazione del progetto se non è stato pulito il vecchio codice inutilizzato dopo che è trascorsa una determinata data.

Ho cercato su Internet e non ho trovato nulla con le funzionalità descritte di seguito:

• dovrebbe essere un'annotazione o qualcosa di simile da inserire nel codice che si intende eliminare prima di una determinata data
• prima di quella data il codice verrà compilato e tutto funzionerà normalmente
• dopo tale data il codice non verrà compilato e ti darà un messaggio che ti avverte del problema

Penso di essere alla ricerca di un unicorno ... Esiste una tecnologia simile per qualsiasi linguaggio di programma?

Come piano BI, sto pensando alla possibilità di fare la magia con alcuni test unitari del codice che si intende rimuovere che iniziano a fallire alla "scadenza". Cosa ne pensi di questo? Qualche idea migliore?

Non penso che questa sarebbe una caratteristica utile quando proibisce davvero la compilazione. Quando al 01/06/2018 non verrà compilata gran parte del codice compilato il giorno prima, il tuo team rimuoverà rapidamente quell'annotazione, ripulendo o meno il codice.

Tuttavia, è possibile aggiungere alcune annotazioni personalizzate al codice come

@Deprecated_after_2018_07_31

e costruisci un piccolo strumento per scansionare quelle annotazioni. (Un semplice liner in grep lo farà, se non si desidera utilizzare la riflessione). In lingue diverse da Java, è possibile utilizzare un commento standardizzato adatto per "grepping" o una definizione di preprocessore.

Quindi esegui quello strumento poco prima o dopo la data particolare e se trova ancora quell'annotazione, ricorda al team di ripulire urgentemente quelle parti di codice.

Ciò costituirebbe una caratteristica nota come bomba a orologeria . Non creare bombe a tempo.

Il codice, non importa quanto bene lo strutturi e lo documenti, si trasformerà in una scatola nera quasi mitica mal compresa se sopravvive oltre una certa età. L'ultima cosa di cui chiunque avrà bisogno in futuro è l'ennesima strana modalità di fallimento che li sorprende totalmente di sorpresa, nel peggior momento possibile e senza un ovvio rimedio. Non ci sono assolutamente scuse per produrre intenzionalmente un tale problema.

Guardalo in questo modo: se sei organizzato e consapevole della tua base di codice abbastanza da preoccuparti dell'obsolescenza e seguirla, allora non hai bisogno di un meccanismo all'interno del codice per ricordartelo. In caso contrario, è probabile che tu non sia aggiornato su altri aspetti della base di codice e che probabilmente non sarai in grado di rispondere tempestivamente e correttamente all'allarme. In altre parole, le bombe a tempo non servono a nessuno. Dì semplicemente di no!

In C # useresti ObsoleteAttributenel modo seguente:

• Nella versione 1, spedisci la funzione. Un metodo, classe, qualunque cosa.
• Nella versione 2, viene fornita una funzionalità migliore destinata a sostituire la funzionalità originale. Metti un attributo Obsoleto sulla funzione, impostalo su "avviso" e gli dai un messaggio che dice "Questa funzione è obsoleta. Usa invece la funzione migliore. Nella versione 3 di questa libreria, che verrà rilasciata su tale e tale una data, l'utilizzo di questa funzione sarà un errore. " Ora gli utenti della funzionalità possono ancora utilizzarla, ma hanno il tempo di aggiornare il proprio codice per utilizzare la nuova funzionalità.
• Nella versione 3, aggiorni l'attributo in modo che sia un errore anziché un avviso e aggiorni il messaggio per dire "Questa funzione è obsoleta. Usa invece la funzione migliore. Nella versione 4 di questa libreria, che verrà rilasciata su tale e tale una data, questa funzione verrà lanciata ". Gli utenti che non hanno rispettato l'avviso precedente ricevono ancora un messaggio utile che dice loro come risolvere il problema e devono risolverlo, perché ora il loro codice non viene compilato.
• Nella versione 4, si modifica la funzionalità in modo che generi un'eccezione irreversibile e si modifica il messaggio per dire che la funzionalità verrà rimossa interamente nella versione successiva.
• Nella versione 5, rimuovi completamente la funzione e se gli utenti si lamentano, beh, ehi, hai dato loro tre cicli di rilascio di un avvertimento corretto e possono sempre continuare a usare la versione 2 se ne sono fortemente convinti.

L'idea in questo caso è quella di apportare una modifica sostanziale il più indolore possibile agli utenti interessati e di garantire che possano continuare a utilizzare la funzionalità per almeno una versione della libreria.

Hai frainteso il significato di "deprecato". Obsoleto significa:

essere utilizzabile ma considerato obsoleto e meglio evitabile, in genere perché è stato sostituito.

_{Dizionari di Oxford}

Per definizione, verrà ancora compilata una funzione obsoleta.

Stai cercando di rimuovere la funzione in una data specifica. Va bene. Il modo in cui lo fai è rimuoverlo in quella data .

Fino ad allora, contrassegnalo come obsoleto, obsoleto o come lo chiama il tuo linguaggio di programmazione. Nel messaggio, includere la data in cui verrà rimosso e l'elemento che lo sostituisce. Ciò genererà avvisi, indicando che altri sviluppatori dovrebbero evitare il nuovo utilizzo e dovrebbero sostituire il vecchio utilizzo ove possibile. Quegli sviluppatori lo obbediranno o lo ignoreranno e qualcuno dovrà affrontarne le conseguenze quando verrà rimosso. (A seconda della situazione, potresti essere tu o potrebbero essere gli sviluppatori che lo utilizzano.)

Non dimenticare che è necessario conservare la capacità di creare ed eseguire il debug di versioni precedenti del codice per supportare le versioni del software che sono già state rilasciate. Sabotare una build dopo una certa data significa anche che rischi di impedirti di eseguire legittimi interventi di manutenzione e supporto in futuro.

Inoltre, sembra una banale soluzione per riportare l'orologio della mia macchina uno o due anni prima della compilazione.

Ricorda, "deprecato" è un avvertimento che qualcosa andrà via in futuro. Quando vuoi impedire forzatamente alle persone di usare quell'API, rimuovi semplicemente il codice associato . Non ha senso lasciare il codice nella base di codice se qualche meccanismo lo rende inutilizzabile. La rimozione del codice ti dà i controlli in fase di compilazione che stai cercando e non ha una soluzione banale.

Modifica: Vedo che fai riferimento a "vecchio codice non utilizzato" nella tua domanda. Se il codice non è realmente utilizzato , non ha senso deprecarlo. Basta cancellarlo.

Non ho mai visto una tale funzione prima d'ora - un'annotazione che inizia ad avere effetto dopo una data particolare.

Il @Deprecatedpuò essere sufficiente, tuttavia. Cattura gli avvisi in CI e fai in modo che rifiuti di accettare la build se presente. Ciò sposta la responsabilità dal compilatore alla pipeline di compilazione, ma ha il vantaggio di poter (semi) facilmente modificare la pipeline di compilazione aggiungendo ulteriori passaggi.

Si noti che questa risposta non risolve completamente il problema (ad esempio, le build locali sui computer degli sviluppatori continuerebbero comunque a funzionare, anche se con avvisi) e presuppone che sia stata impostata e eseguita una pipeline CI.

Stai cercando calendari o liste di cose da fare .

Un'altra alternativa è quella di utilizzare avvisi personalizzati del compilatore o messaggi del compilatore, se si riesce ad avere pochi o nessun avviso nella propria base di codice. Se hai troppi avvisi, dovrai dedicare ulteriore sforzo (circa 15 minuti?) E raccogliere l'avvertimento del compilatore nel rapporto di compilazione che la tua integrazione continua offre su ogni build.

I promemoria che il codice deve essere corretto sono buoni e necessari. A volte questi promemoria hanno scadenze rigorose nel mondo reale, quindi potrebbe anche essere necessario metterli su un timer.

L'obiettivo è ricordare continuamente alle persone che il problema esiste e deve essere risolto in un determinato periodo di tempo - una funzione che interrompe semplicemente la generazione in un momento specifico non solo non lo fa, ma quella caratteristica è essa stessa un problema che deve essere risolto entro un determinato periodo di tempo.

Un modo di pensarci è cosa intendi per data / ora ? I computer non sanno quali siano questi concetti: devono essere programmati in qualche modo. È abbastanza comune rappresentare i tempi nel formato UNIX di "secondi dall'epoca", ed è comune inserire un determinato valore in un programma tramite chiamate del sistema operativo. Tuttavia, non importa quanto sia comune questo utilizzo, è importante tenere presente che non è il momento "reale": è solo una rappresentazione logica.

Come altri hanno sottolineato, se hai fissato una "scadenza" utilizzando questo meccanismo, è banale alimentare un tempo diverso e infrangere quella "scadenza". Lo stesso vale per meccanismi più elaborati come la richiesta a un server NTP (anche tramite una connessione "sicura", poiché possiamo sostituire i nostri certificati, autorità di certificazione o persino patchare le librerie di crittografia). All'inizio potrebbe sembrare che tali individui siano in errore per aver aggirato il tuo meccanismo, ma può accadere che sia fatto automaticamente e per buoni motivi . Ad esempio, è una buona idea avere build riproducibili e strumenti che aiutino questo a ripristinare automaticamente / intercettare tali chiamate di sistema non deterministiche. libfaketime fa esattamente questo,imposta tutti i timestamp del file su 1970-01-01 00:00:01, la funzione di registrazione / riproduzione di Qemu simula tutte le interazioni hardware, ecc.

Questo è simile alla legge di Goodhart : se fai in modo che il comportamento di un programma dipenda dal tempo logico, allora il tempo logico cessa di essere una buona misura del tempo "reale". In altre parole, le persone in genere non scherzano con l'orologio di sistema, ma lo faranno se gli dai un motivo.

Esistono altre rappresentazioni logiche del tempo: una di queste è la versione del software (la tua app o alcune dipendenze). Questa è una rappresentazione più desiderabile per una "scadenza" rispetto ad esempio al tempo UNIX, poiché è più specifica per ciò che ti interessa (modifica dei set di funzionalità / API) e quindi meno probabilità di calpestare problemi ortogonali (ad esempio, giocherellare con il tempo UNIX per aggirare la scadenza potrebbe finire per rompere i file di registro, cron lavori, cache, ecc.).

Come altri hanno già detto, se controlli la libreria e desideri "spingere" questa modifica, puoi inviare una nuova versione che depreca le funzionalità (causando avvisi, per aiutare i consumatori a trovare e aggiornare il loro utilizzo), quindi un'altra nuova versione che rimuove il caratteristiche interamente. Se lo desideri, puoi pubblicarli immediatamente dopo l'altro, poiché (di nuovo) le versioni sono semplicemente una rappresentazione logica del tempo, non è necessario che siano correlate al tempo "reale". Il versioning semantico può aiutare qui.

Il modello alternativo è "tirare" il cambiamento. Questo è come il tuo "piano B": aggiungi un test all'applicazione che consuma, che controlla che la versione di questa dipendenza sia almeno il nuovo valore. Come al solito, rosso / verde / refactor per propagare questo cambiamento attraverso la base di codice. Ciò può essere più appropriato se la funzionalità non è "errata" o "errata", ma solo "inadatta a questo caso d'uso".

Una domanda importante con l'approccio "pull" è se la versione di dipendenza conta o meno come "unità" ( di funzionalità ), e quindi merita di essere testata; o se si tratta solo di un dettaglio di implementazione "privato", che dovrebbe essere esercitato solo come parte dei test di unità ( di funzionalità ) effettivi . Direi: se la distinzione tra le versioni della dipendenza conta davvero come una caratteristica della tua applicazione, allora fai il test (per esempio, controllando che la versione di Python sia> = 3.x). Altrimenti, non farloaggiungere il test (poiché sarà fragile, non informativo e eccessivamente restrittivo); se controlli la libreria, segui il percorso "push". Se non controlli la libreria, utilizza semplicemente la versione fornita: se i tuoi test superano, non vale la pena limitarti; se non passano, quella è la tua "scadenza" proprio lì!

Esiste un altro approccio, se si desidera scoraggiare determinati usi delle funzionalità di una dipendenza (ad es. Chiamare determinate funzioni che non giocano bene con il resto del codice), soprattutto se non si controlla la dipendenza: vietare i propri standard di codifica / scoraggia l'uso di queste funzionalità e aggiungi controlli per esse alla tua linter.

Ognuno di questi sarà applicabile in diverse circostanze.

Puoi gestirlo a livello di pacchetto o libreria. Controlli un pacchetto e ne controlli la visibilità. Sei libero di ritrarre la visibilità. L'ho visto internamente in grandi aziende e ha senso solo nelle culture che rispettano la proprietà dei pacchetti anche se i pacchetti sono open source o gratuiti da usare.

Questo è sempre disordinato perché i team client semplicemente non vogliono cambiare nulla, quindi spesso hai bisogno di alcuni round di whitelist solo mentre lavori con i clienti specifici per concordare una scadenza per migrare, possibilmente offrendo loro supporto.

Un requisito è introdurre una nozione di tempo nella build. In C, C ++, o altri linguaggi / sistemi che utilizzano un preprocessore C-come costruire ¹ , si potrebbe introdurre un timestamp attraverso definisce per il preprocessore in fase di compilazione: CPPFLAGS=-DTIMESTAMP()=$(date '+%s'). Questo probabilmente accadrebbe in un makefile.

Nel codice si confronterebbe quel token e causerebbe un errore se il tempo è scaduto. Si noti che l'utilizzo di una macro di funzione rileva il caso che qualcuno non ha definito TIMESTAMP.

#if TIMESTAMP() == 0 || TIMESTAMP() > 1520616626
#   error "The time for this feature has run out, sorry"
#endif

In alternativa, si potrebbe semplicemente "definire" il codice in questione quando è giunto il momento. Ciò consentirebbe la compilazione del programma, a condizione che nessuno lo utilizzi. Supponiamo che abbiamo un'intestazione che definisce un api, "api.h", e non consentiamo di chiamare old()dopo un certo tempo:

//...
void new1();
void new2();
#if TIMESTAMP() < 1520616626
   void old();
#endif
//...

Un costrutto simile probabilmente eliminerebbe old()il corpo della funzione da qualche file sorgente.

Ovviamente questo non è a prova di sciocco; si può semplicemente definire un vecchio TIMESTAMPin caso di emergenza di venerdì notte menzionata altrove. Ma questo è, credo, piuttosto vantaggioso.

Questo ovviamente funziona solo quando la libreria viene ricompilata, dopodiché il codice obsoleto semplicemente non esiste più nella libreria. Sarebbe Non impedire che il codice client di collegamento a binari obsoleti però.

In Visual Studio, puoi impostare uno script pre-build che genera un errore dopo una determinata data. Ciò impedirà la compilazione. Ecco uno script che genera un errore il 12 marzo 2018 o successivamente ( preso da qui ):

@ECHO OFF

SET CutOffDate=2018-03-12

REM These indexes assume %DATE% is in format:
REM   Abr MM/DD/YYYY - ex. Sun 01/25/2015
SET TodayYear=%DATE:~10,4%
SET TodayMonth=%DATE:~4,2%
SET TodayDay=%DATE:~7,2%

REM Construct today's date to be in the same format as the CutOffDate.
REM Since the format is a comparable string, it will evaluate date orders.
IF %TodayYear%-%TodayMonth%-%TodayDay% GTR %CutOffDate% (
    ECHO Today is after the cut-off date.
    REM throw an error to prevent compilation
    EXIT /B 2
) ELSE (
    ECHO Today is on or before the cut-off date.
)

Assicurati di leggere le altre risposte su questa pagina prima di utilizzare questo script.

Capisco l'obiettivo di ciò che stai cercando di fare. Ma come altri hanno già detto, il sistema di compilazione / compilatore non è probabilmente il posto giusto per imporlo. Suggerirei che il livello più naturale per applicare questa politica sia SCM o le variabili di ambiente.

Se lo fai, aggiungi fondamentalmente un flag di funzionalità che contrassegna un'esecuzione pre-ammortamento. Ogni volta che costruisci la classe deprecata o chiami un metodo deprecato, controlla il flag di funzionalità. Basta definire una singola funzione statica assertPreDeprecated()e aggiungerla a ogni percorso del codice deprecato. Se impostato, ignora le chiamate assert. Se non è un'eccezione. Una volta trascorsa la data, disattiva il flag della funzione nell'ambiente di runtime. Eventuali chiamate obsolete persistenti al codice verranno visualizzate nei registri di runtime.

Per una soluzione basata su SCM, suppongo che tu stia usando git e git-flow. (In caso contrario, la logica è facilmente adattabile ad altri VCS). Crea una nuova filiale postDeprecated. In quel ramo elimina tutto il codice obsoleto e inizia a lavorare sulla rimozione di eventuali riferimenti fino a quando non viene compilato. Eventuali modifiche normali continuano ad apportare al masterramo. Continua a fondere eventuali modifiche masteral codice correlate non deprecate postDeprecatedper ridurre al minimo le sfide di integrazione.

Al termine della data di ammortamento, creare un nuovo preDeprecatedramo da master. Quindi postDeprecatedricollegati master. Supponendo che la tua versione vada fuori dal masterramo, ora dovresti utilizzare il ramo post-deprecato dopo la data. Se si verifica un'emergenza o non è possibile fornire risultati in tempo, è sempre possibile eseguire il rollback preDeprecatede apportare le modifiche necessarie su quel ramo.