Quale sarebbe l'approccio migliore? Scrivi test unitari per loro o chiedi perché sono lì?
L'eliminazione del codice è una buona cosa.
Quando non puoi eliminare il codice, puoi sicuramente contrassegnarlo come @Deprecated , documentando quale versione principale stai prendendo di mira per rimuovere il metodo. Quindi puoi eliminarlo "più tardi". Nel frattempo, sarà chiaro che non dovrebbe essere aggiunto alcun nuovo codice che dipende da esso.
Non consiglierei di investire in metodi deprecati, quindi nessun nuovo test unitario solo per raggiungere gli obiettivi di copertura.
La differenza tra i due è principalmente se i metodi fanno parte o meno dell'interfaccia pubblicata . L'eliminazione arbitraria di parti dell'interfaccia pubblicata può rappresentare una spiacevole sorpresa per i consumatori che dipendono dall'interfaccia.
Non posso parlare con EclEmma, ma dalle mie esperienze una delle cose di cui devi fare attenzione è la riflessione. Se, ad esempio, usi i file di configurazione del testo per scegliere a quali classi / metodi accedere, la distinzione usata / non usata potrebbe non essere ovvia (ne sono stato bruciato un paio di volte).
Se il tuo progetto è una foglia nel grafico delle dipendenze, il caso della deprecazione è indebolito. Se il tuo progetto è una libreria, il caso della deprecazione è più forte.
Se la tua azienda utilizza un mono-repo , l'eliminazione comporta un rischio inferiore rispetto al caso multi-repo.
Come notato da l0b0 , se i metodi sono già disponibili nel controllo del codice sorgente, recuperarli dopo l'eliminazione è un esercizio semplice. Se eri davvero preoccupato di doverlo fare, rifletti su come organizzare i tuoi commit in modo da poter recuperare le modifiche cancellate se ne hai bisogno.
Se l'incertezza è abbastanza elevata, potresti considerare di commentare il codice , piuttosto che eliminarlo. È un lavoro extra nel percorso felice (in cui il codice eliminato non viene mai ripristinato), ma semplifica il ripristino. La mia ipotesi è che dovresti preferire una cancellazione diretta fino a quando non ne sei stato bruciato un paio di volte, il che ti darà alcune idee su come valutare "l'incertezza" in questo contesto.
domanda perché sono lì?
Il tempo impiegato per catturare la tradizione non è necessariamente perso. Sono stato conosciuto per eseguire una rimozione in due passaggi: in primo luogo, aggiungendo e facendo un commento che spiega ciò che abbiamo imparato sul codice, e successivamente cancellando il codice (e il commento).
Potresti anche usare qualcosa di analogo ai record di decisione dell'architettura come un modo per catturare la tradizione con il codice sorgente.