Jak długo trzeba czekać na usunięcie przestarzałej metody? [Zamknięte]

38

Utrzymuję publiczny interfejs API i muszę wycofać metodę.

Czy istnieje ogólna zasada określająca, ile miesięcy / lat / wersji przed usunięciem powinienem zastąpić metodę?

java deprecation

— deviDave
źródło

27

Ogólna zasada brzmi: „przechowuj to tak długo, jak długo Ty i / lub Twoi klienci będą tego potrzebować”.

— Robert Harvey

15

Zdefiniuj „publiczny”. Darmowe oprogramowanie typu open source, z zastrzeżeniem „użytkowania na własne ryzyko”? Lub sprzedane oprogramowanie, jeśli istnieje umowa?

— Doc Brown,

11

To bardzo zależy od rynku, na którym działają Twoi użytkownicy i od tego, czy płacą Ci za interfejs API.

— 17 z 26

10

Zależy to również od tego, dlaczego „musisz” to amortyzować; czy stary sposób stanowi zagrożenie bezpieczeństwa? Czy właśnie znalazłeś powód, dla którego stary sposób jest zasadniczo niestabilny z powodu niefortunnej decyzji projektowej? Czy stary sposób jest teraz znacznie wolniejszy niż kiedyś? Czy kończy Ci się pamięć w systemie docelowym (np. System osadzony) i dosłownie nie możesz na nim zainstalować obu interfejsów API? A może po prostu znalazłeś „lepszy” sposób i chcesz po prostu wyczyścić stary kod, aby zmniejszyć koszty utrzymania?

— jrh

8

java.io.StringBufferInputStreamprzestarzałe od JDK 1.1 (1997?). Nie ma dobrej lub złej odpowiedzi na to pytanie. To zależy od twoich potrzeb zapewnienia kompatybilności wstecznej.

— Laiv

52

Przynajmniej powinieneś zachować przestarzałe metody w jednej wersji przed ich usunięciem, co wydaje się dość oczywiste, gdy je wypiszę. Nie sądzę, by był maksymalny czas, ale jeśli tak naprawdę nigdy ich nie usuniesz, wycofanie się stanie się trochę bezcelowe.

Najważniejsze wydania wersji to dobry czas na usunięcie przestarzałych metod. Drobne wydania zazwyczaj nie powinny zawierać przełomowych zmian. Jak zauważył cHao w komentarzach, wycofanie niekoniecznie oznacza, że nastąpi ostateczne usunięcie, więc jeśli planujesz usunąć rzeczy po wycofaniu, powinieneś wyraźnie to zauważyć i podać pewne wskazówki na osi czasu.

— JimmyJames
źródło

58

Wycofanie niekoniecznie musi dotyczyć ostatecznego usunięcia, więc wycofanie bez usunięcia nie jest bezcelowe (i często jest właściwe, jeśli ważna jest zgodność wsteczna). Często chodzi o to, że „mamy teraz lepszy sposób, więc nie powinieneś już tak robić”.

— cHao

9

@ cHao Jeśli coś jest przestarzałe, nie należy oczekiwać, że będzie nadal występować. Podejrzewam, że jeśli chcesz w swoim projekcie napisać specjalne oświadczenie, że nie usuniesz przestarzałej funkcjonalności, to dobrze, ale w przeciwnym razie tak, sugeruje się, że nastąpi ostateczne usunięcie. Chodzi mi o to, że jeśli nie utrzymasz jakiegoś rygoru wokół tego, ludzie mogą uwierzyć, że to się nigdy nie wydarzy. To wymyśliło najnowsze wersje Javy, w których funkcje, które były przestarzałe przez dekadę lub dłużej, są obecnie usuwane.

— JimmyJames,

6

@ cHao Wolę projekt usunąć jego przestarzałą funkcjonalność. Korzyścią jest nie tylko fakt, że użytkownicy są zmotywowani do zmiany, ale także zapobiegają ingerowaniu przestarzałego interfejsu w inne ulepszenia.

— jpmc26,

9

@cHao To kwestia wrażliwa na kontekst. Z mojego doświadczenia wynika, że polityka amortyzacji jest jasna. Wyraźnie stwierdzono, że przestarzała funkcjonalność zostanie w pewnym momencie usunięta. Często przestarzała funkcjonalność ma problemy z użytkowaniem i nie jest po prostu kwestią tego, czy cenisz sobie kompatybilność wsteczną, czy nie.

— JimmyJames,

6

Zamierzam zgodzić się z @JimmyJames, że wycofanie wyraźnie oznacza zbliżające się usunięcie. Okres amortyzacji istnieje jako sposób na zapewnienie tymczasowej kompatybilności wstecznej, aby konsumenci mogli przeprowadzić migrację do nowszej funkcjonalności. Absolutnie nie należy oczekiwać, że przestarzała funkcjonalność pozostanie na czas nieokreślony. Jeśli stara funkcjonalność pozostanie, nie ma powodu, aby ją wycofywać.

— Eric King,

17

Zależy to wyłącznie od tego, jaki rodzaj gwarancji stabilności dałeś swoim użytkownikom i ile bólu chcesz sprawić swoim użytkownikom.

Idealnie, twój interfejs API używa semver , aby każda przełamująca zmiana spowodowała zwiększenie głównego numeru wersji. W praktyce pożądane jest, aby robić to prawie nigdy. Jeśli Twój interfejs API jest zainstalowany za pomocą menedżera pakietów, możesz chcieć utworzyć nową nazwę pakietu po przełomowej zmianie, aby prosta aktualizacja nie powodowała konfliktów (np. myapi2 v2.123.4Vs myapi3 v3.2.1). Może to być niepotrzebne, jeśli menedżer pakietów obsługuje ściślejsze zależności wersji (np. Taka specyfikacja zależności ~v2.120nie obejmuje v3.*), ale różne nazwy pakietów mają tę zaletę, że można bardzo łatwo używać obok siebie niekompatybilnych wersji. Nawet podczas korzystania z semver rozsądne może być zastosowanie okresu amortyzacji.

Semver nie zawsze ma zastosowanie. Dlatego ważniejsze jest przekazanie jasnej polityki stabilności. Na przykład:

Funkcje eksperymentalne mogą zostać usunięte bez powiadomienia.
Funkcje można usunąć w dowolnym momencie ze względów bezpieczeństwa.
Inne funkcje zostaną usunięte
- … Po wycofaniu w wydanej wersji
- … Gdzie ta wersja ma co najmniej trzy miesiące
- … I będzie oznaczony guzem w głównej wersji.

Takie zasady działają szczególnie dobrze w przypadku regularnych wydań, dzięki czemu istnieje wyraźny okres amortyzacji, np. Jeden rok.

Oprócz oznaczania jakichkolwiek części interfejsu API jako przestarzałe, powinieneś uczynić je powszechnie znanym. Na przykład:

W dzienniku zmian umieść sekcję o przyszłych kierunkach i rezygnacjach.
Przekaż zamiar wycofania się przed dokonaniem wycofania i wysłuchaj społeczności, aby sprawdzić, czy istnieją poważne zastrzeżenia.
Informuj, jakie korzyści przyniosą te zmiany. W zależności od bazy użytkowników biuletyny, prezentacje, posty na blogu lub komunikaty prasowe mogą być odpowiednimi mediami. Kręcąc „tworzymy niesamowitą nową funkcję! (który wymaga usunięcia tej powszechnie używanej starej funkcji) ”jest nieco mniej frustrujący niż usunięcie funkcji bez kontekstu.

Jeśli chodzi o dokładny okres amortyzacji do wyboru, najpierw sprawdź, czy musisz honorować umowy wsparcia z użytkownikami. Takie umowy mogą wymagać zachowania przez pewien czas zgodności. Jeśli nie, rozważ wpływ na dalszy proces. Staraj się zmieniać szybciej niż dalsi użytkownicy, aby mogli przejść przez własny cykl amortyzacji. Dalsi użytkownicy będą potrzebowali trochę czasu, aby dostosować się do twoich zmian, więc nigdy nie powinieneś mieć okresu amortyzacji krótszego niż miesiąc.

— amon
źródło

3

Usprawiedliwiony z tego powodu: Po

Ideally, your API uses semver so that any breaking change causes the major version number to be incremented. In practice, it is desirable to do this almost never.

co używać semver do wskazywania przełomowych zmian, jeśli śledzisz to, mówiąc, że nigdy nie powinieneś wprowadzać nowej głównej wersji?

— mrsmn

6

Czy naprawdę warto zmienić nazwę pakietu, jeśli nastąpiła poważna zmiana? Do tego służą numery wersji. Nienawidzę, kiedy oni również zmieniają ich nazwy, to naprawdę psuje zarządzanie zależnościami Maven.

— AJPerez

@AJPerez Rozumiem, że to nie jest idealne, ale może zapobiegać konfliktom na dużych wykresach zależności z zależnościami przechodnimi: zależę od libfoo, który zależy od libconflict v1.2.3, a także zależę od libbar, który zależy od libconflict v2.3.4. Następnie nie mogę wybrać żadnej wersji libconflict, która spełnia wszystkie zależności - chyba że libconflict i libconflict2 są odrębnymi pakietami. W przypadku Javy taka zmiana nazwy jest denerwująca, ponieważ muszę zmienić cały import. Na szczęście Java 9 (moduły) obsługuje używanie sprzecznych wersji.

— amon

1

@mrsmn Przełamywanie zmian jest denerwujące, niezależnie od tego, czy je pakujesz, czy nadajesz im nazwy. Semver rozwiązuje tylko niewielką część tego problemu: możliwość stwierdzenia, czy aktualizacja coś zepsuje. Ale gdy dojdzie do przełomowej zmiany, nadal musisz poświęcić wysiłek, aby ją zaakceptować. Dlatego lepiej jest, jeśli interfejsy API bardzo mocno starają się być tak stabilne, jak to możliwe. Idealnie są zaprojektowane w taki sposób, aby można je było rozszerzać bez naruszania kompatybilności wstecznej.

— amon

@AJPerez tak. Tak, to jest dobre. Ludzie cały czas psują wersję. Poprawki błędów (przypuszczalnie xxx ++) często się psują (przypuszczalnie x ++. Xx). Jak wskazuje amon, ty (i mam na myśli ciebie jako użytkownika zależności) masz problem, który musisz rozwiązać. Wiem, że mój kod działa z foo 3.2.1, może działać z foo 3.3.0. Wiem, że mój kod działa z foo, może działać z foo-2. Używam semver, ponieważ popularność i sama w sobie nie boli, ale tak naprawdę nie jest dla mnie jasne, że kupuje tyle.

— Jared Smith

14

Idealnie byłoby poczekać, aż nikt nie będzie używać przestarzałej metody. Biorąc pod uwagę, że używasz publicznego interfejsu API, jest to łatwe do śledzenia, ale możesz skończyć z bardzo długim oczekiwaniem.

w 2015 roku Google miał podobny problem z interfejsem API stlport w swoim systemie operacyjnym Android. Przestarzali i chcieli go usunąć, ale mnóstwo aplikacji nadal z niego korzystało. Znaleźli sprytne rozwiązanie:

Zasadniczo dodali 8-sekundową funkcję sleep () podczas uruchamiania dowolnej aplikacji, która nadal używała interfejsu API z odpowiednim komunikatem dziennika dla programistów. Miesiąc później podwoili go do 16 sekund. a następnie miesiąc później mogli bezpiecznie usunąć interfejs API, ponieważ nikt go nie używał.

Może to być bardzo skuteczny sposób na zrobienie tego. Jedynym prawdziwym problemem jest to, że interfejs API jest bardzo stary i aktywnie korzystał z klientów, którzy nie są już aktywnie obsługiwani. Niestety prawdopodobnie nie będziesz w stanie samodzielnie naprawić takich klientów, ale w tym momencie nie możesz zrobić nic więcej niż usunąć metodę i złamać konsumenta.

— Nzall
źródło

5

Uroczy. Bardzo urocze

— David Hammen

8

Minimalny czas na dostarczenie przestarzałych metod zależy od cykli programowania programów korzystających z interfejsu API. Jak można się domyślać, rok powinien wystarczyć.

Jeśli chodzi o maksymalny czas, zanim będziesz musiał usunąć przestarzałe metody, twierdzę, że nie ma czegoś takiego. Bez względu na to, jak długo będziesz czekać, usunięcie przestarzałej metody zawsze coś zepsuje. Niektóre programy używające przestarzałego interfejsu API nie są aktywnie utrzymywane, a zerwanie zgodności będzie oznaczało koniec życia takich programów.

Sugeruję usunięcie przestarzałych metod, gdy uzyskasz coś z usunięcia :

wykryto błąd, który dotyczy konkretnie przestarzałych metod
masz zamiar zmienić kod i utrzymanie przestarzałych metod wymagałoby znacznego wysiłku
optymalizujesz wewnętrzną strukturę biblioteki, a przestarzałe metody już się nie mieszczą.

Usuwanie przestarzałych metod tylko dlatego, że były przestarzałe przez X miesięcy / lat lub dlatego, że wypuszczasz nową wersję, oznacza arbitralną szkodę dla zgodności bez uzasadnionego powodu.

— Dmitrij Grigoriew
źródło

7

Najpierw zastanów się, czy chcesz być przestarzały, czy przestarzały.

Przestarzałe powinny być stosowane w przypadku metod, które są w pewien sposób szkodliwe: bezpieczeństwo, wydajność, nieprawidłowe wyniki. Chcesz się ich pozbyć stosunkowo szybko, nie więcej niż 2 główne wersje i przejść do 3. W przypadku wystarczająco znaczących problemów, przestarzałe mogą zostać usunięte w następnej mniejszej wersji.

Przestarzały dotyczy rzeczy, które z jakiegoś powodu są mniej przydatne, na przykład zwraca mniej informacji lub nie działa tak dobrze, nie zawiera tylu opcji i tak dalej. Mogą one pozostawać w nieskończoność, ale powinny przynajmniej być obecne w następnej głównej wersji.

— jmoreno
źródło

Powiedziałbym, że metoda dająca nieprawidłowe wyniki lub naruszająca bezpieczeństwo powinna zostać natychmiast wyłączona lub naprawiona. Metoda o złej wydajności może działać w nieskończoność, o ile jej wydajność jest akceptowalna dla niektórych użytkowników.

— Dmitrij Grigoryev

@DmitryGrigoryev: jedna niewielka wersja jest bardzo blisko natychmiast.

— jmoreno

4

Odpowiedź zależy od rodzaju usług świadczonych klientom.

Z jednej strony skrajności występują błędy w Windows.h z czasów Win 3.1, które propagowały się przez dwie dekady, ponieważ Microsoft bardzo mocno wierzył w zgodność wsteczną.

Na drugim końcu spektrum wiele aplikacji internetowych usuwa funkcje bez ostrzeżenia o rezygnacji.

Często liczy się to, ile klienci płacą za twoje oprogramowanie, podobnie jak ich linia pracy. Naukowcy są zazwyczaj bardziej skłonni zaakceptować deprecjację w ramach marszu postępu niż, powiedzmy, bankierzy lub FAA.

Pracowałem dla firmy opracowującej oprogramowanie do użytku wewnętrznego. Przez lata wspierałem wiele grup. Jedna grupa miała mentalność „nigdy nie usuwaj żadnych funkcji”. Potrzebowali możliwości powrotu do plików 5–10 lat temu i analizowania ich w zbyt krótkim czasie, aby programiści mogli przywrócić funkcje. Jedna grupa postawiła na „upewnienie się, że wszystkie informacje o wycofaniu znajdują się w uwagach do łaty, więc można je później znaleźć ”. Pośrodku mieliśmy jedną grupę, której reguła brzmiała: „Funkcje muszą być przestarzałe dla co najmniej 1 wersji z wydrukowanym ostrzeżeniem, jeśli są używane przed ich usunięciem”. Ta grupa miała zestaw testowy obejmujący potrzebne funkcje. Za każdym razem, gdy wypuszczaliśmy nową wersję, szybko sprawdzali jej pakiet testowy, aby sprawdzić, czy jakiekolwiek zaniechanie nie przysporzyło im problemów.

— Cort Ammon
źródło

4

Utrzymuję publiczny interfejs API i muszę wycofać metodę.

Dlaczego musisz to zrobić? Czy to dlatego, że istnieje nowy błyszczący sposób robienia rzeczy, więc stara metoda jest teraz odradzana, ale nadal działa dobrze? Czy może stara metoda rzeczywiście musi zostać zastosowana, ponieważ rzeczy uległy zasadniczej zmianie?

Jeśli stara metoda nie powoduje żadnych rzeczywistych problemów i może się utrzymywać, może również. Jeśli nie jest zepsuty, nie naprawiaj go. Czy naprawdę musisz to usunąć? Może oznacz to jako przestarzałe i dołącz notatkę w dokumentacji, że inna metoda może być bardziej wydajna, czy coś, ale prawdopodobnie dobrze jest pozostawić ją na miejscu.
Jeśli stara metoda naprawdę musi przejść, ponieważ powoduje bóle głowy związane z utrzymaniem lub po prostu nie ma już sensu z powodu innych zmian, należy monitorować jej użycie i wyraźnie informować klientów o wycofaniu. Daj im jasną datę, po której metoda zostanie usunięta. (Idealnie, nie usuwaj go natychmiast w tym dniu: poczekaj, aż nikt go nie użyje, zanim faktycznie go usunie. Może być konieczne, aby przejść wcześniej, jeśli naprawdę powoduje problemy, ale przynajmniej poczekaj, aż użycie spadnie mało.)
Jeśli stara metoda powoduje problemy z bezpieczeństwem, być może będziesz musiał poruszać się szybciej, prawdopodobnie nawet usuwając ją bez ostrzeżenia, ale powinieneś udokumentować tę zmianę w bardzo widocznym miejscu, a także zwracać sensowne wiadomości klientom, którzy próbują użyć starej metody.

(Pozostałe dwa punkty są dobrze opisane w innych odpowiedziach, ale myślę, że pierwszy jest nowy.)

— Wymuskany
źródło

1

W przypadku projektu publicznego usuń go tylko wtedy , gdy jest to konieczne.

Kiedy robisz niepotrzebne usuwanie API, kosztujesz firmy i kontrahentów pieniądze w taki sposób, że nie możesz nawet obliczyć z powodu kosztownego odejścia.

Chcesz, aby firmy i niezależni programiści przestali korzystać z Twojego projektu? Rozbijaj ich wystarczająco dużo razy, gdy nie jesteś niezbędny, a będziesz na tej łodzi w mgnieniu oka.

deprecation != eventual_removal. Jeśli interfejs API jest niebezpieczny, usuwasz go. Jeśli jest po prostu stary, zostaw go i udokumentuj jego wymianę.

— kayleeFrye_onDeck
źródło