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

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ę?

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.

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.

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.

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.

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.

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.

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.)

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ę.