Kiedy wycofywać, a kiedy usuwać w Javie

W ramach działań refaktoryzacyjnych lub po prostu ciągłego rozwoju, określona metoda lub może cała klasa może stać się w pewnym sensie przestarzała. Java obsługuje @Deprecatedadnotację wskazującą, że prawdopodobnie istnieje lepszy sposób obsługi danych funkcji. Wyobrażam sobie, że jest to szczególnie przydatne w publicznych interfejsach API, w których skutki usunięcia części interfejsu API mogą nie być znane. W przypadku niepublicznego interfejsu API i projektu korzystającego z systemów kontroli wersji (więc usunięcie może być cofnięte w pewnym sensie), kiedy należy przestać działać, zamiast usuwać przestarzałe elementy?

Czy Twój interfejs API jest interfejsem publicznym? To decyduje, czy należy wycofać czy usunąć. Jeśli interfejs API jest ściśle na Twoją korzyść (tzn. Jest używany tylko w Twojej firmie), najlepiej po prostu usunąć kod naruszający. Jest znacznie czystszy i na dłuższą metę spowoduje mniej problemów z konserwacją.

Jeśli jednak interfejs API jest publicznie dostępny, po prostu usunięcie metody może spowodować, że kod, który był używany ze starszymi wersjami biblioteki, przestanie działać. Tam rzeczy się psują. Oto kilka wskazówek:

• Wewnętrzny interfejs API: raczej usuń niż przestarzałe. Jeśli jakiś klient korzysta z wewnętrznej klasy lub metody, to z jego winy narzędzie się zepsuje.
• Zewnętrzny interfejs API: najpierw przestarzałe, później usuń. Wycofanie jest flagą, że coś zostanie później usunięte. Później zależy od tego, co uważasz za uzasadnione. Przynajmniej daj 2-3 wersje przed faktycznym usunięciem przestarzałego kodu.

Prawdopodobnie dobrym pomysłem jest ustawienie przypomnienia @deprecate klasy lub metody. Robisz to, aby promować jego starzenie się. Więc zgadnij, ile czasu zajmie, w miarę możliwości, wyeliminowanie wszystkich odniesień. Oznacz go jako @deprecated i umieść przypomnienie w swoim kalendarzu. Po otrzymaniu przypomnienia sprawdź. Jeśli nie jest już używany, usuń go. Jeśli pozostanie kilka odniesień, które można szybko zaktualizować, zrób to i usuń element. Jeśli pozostaną bardziej znaczące prace, podnieś nieco przypomnienie do przodu.

Zrób to wystarczająco dużo razy, a poczujesz, ile czasu zajmuje pozbycie się klasy lub metody w swoich projektach.

IMHO, jeśli możesz upewnić się, że nikt go nie używa i nigdy nie będzie, po prostu go usuń. (Może to być trudne w przypadku odbicia lub zewnętrznych komponentów, takich jak makra Velocity - nowoczesne IDE, takie jak IntelliJ, mogą znaleźć odniesienia np. W JSP, ale nie poprzez odbicie lub Velocity.)

Jeśli istnieje lepsza alternatywa, ale stara jest nadal używana w wielu miejscach, a obecnie nie masz czasu na refaktoryzację całego kodu klienta, wystarczy @deprecate przestarzałą klasę / metodę (z odpowiednim komentarzem na temat preferowana alternatywa).