Як довго чекати, перш ніж видалити застарілий метод? [зачинено]

38

Я підтримую відкритий API і мушу знести метод.

Чи існує загальне правило про те, скільки місяців / років / версій перед видаленням я повинен знести метод?

java deprecation

— deviDave
джерело

27

Загальне правило - "тримати його довше, наскільки вам та / або вашим клієнтам це потрібно".

— Роберт Харві

15

Визначте "громадськість". Безкоштовне програмне забезпечення з відкритим кодом із звичайною відмовою від відповідальності "використовувати на свій страх і ризик"? Або продане програмне забезпечення там, де існує контракт?

— Doc Brown

11

Це дуже залежить від того, на якому ринку працюють ваші користувачі та платять вони вам чи ні за API.

— 17 з 26

10

Це також залежить від того, чому ви "маєте" його знецінити; чи є старий спосіб ризику для безпеки? Ви тільки що зараз знайшли причину, чому старий спосіб є принципово і незмінно нестабільним через невдале дизайнерське рішення? Зараз старий шлях набагато повільніше, ніж раніше? У вас не вистачає пам'яті вашої цільової системи (наприклад, вбудованої системи), і ви буквально не можете встановити обидва API на ній? Або ви просто знайшли "кращий" спосіб і просто хочете очистити старий код, щоб зменшити накладні витрати на обслуговування?

— jrh

8

java.io.StringBufferInputStreamзастаріла після JDK 1.1 (1997?). На це питання немає хорошої чи неправильної відповіді. Це залежить від ваших потреб у забезпеченні зворотної сумісності.

— Лаїв

52

Як мінімум, ви повинні зберігати застарілі методи в одній версії, перш ніж видаляти їх, що здається очевидним, коли я виписую це. Я не думаю, що є максимальний час, але якщо ви ніколи їх не видаляєте, застарілість стає трохи безглуздою.

Основні версії версій - хороший час для видалення застарілих методів. Незначні випуски, як правило, не повинні містити порушень. Як зазначає cHao у коментарях, припинення роботи не обов'язково означає, що відбудеться можливе видалення, тому якщо ви плануєте видалити речі після депресії, ви повинні чітко зазначити це та надати певні вказівки щодо часової шкали.

— JimmyJames
джерело

58

Позбавлення інформації не обов'язково стосується можливого видалення, тому припинення роботи без видалення не є безглуздим (і часто це правильна річ, якщо важлива відстала сумісність). Часто справа не в чому іншому, як "у нас зараз кращий шлях, тому більше не варто робити це так".

— cHao

9

@cHao Якщо щось застаріле, не варто сподіватися, що воно буде там. Я гадаю, що якщо ви хочете зробити спеціальну заяву у своєму проекті, яка стверджує, що ви не будете видаляти застарілу функціональність, це нормально, але в іншому випадку, так, мається на увазі, що можливе видалення. Я висловлюю думку про те, що якщо ви не будете дотримуватися певної суворості навколо цього, люди можуть повірити, що це ніколи не відбудеться. Це з’явилося з останніми версіями Java, де функціональність, яка була застаріла протягом десятиліття і більше, зараз видаляється.

— JimmyJames

6

@cHao Я скоріше б проект видалив його застарілу функціональність. Не тільки є користь користувачів, які насправді спонукають до перемикання, але також запобігає перестарелому інтерфейсу не втручатися в інші вдосконалення.

— jpmc26

9

@cHao Це річ, що залежить від контексту. На мій досвід, політика знецінення зрозуміла. Чітко сказано, що застарілий функціонал буде видалено в якийсь момент в майбутньому. Часто застаріла функціональність має проблеми, що роблять її проблематичною для використання, і не просто питання в тому, цінуєте ви відсталу сумісність чи ні.

— JimmyJames

6

Я збираюся подзвонити, щоб погодитись з @JimmyJames, що застаріння явно передбачає неминуче видалення. Період припинення існування існує як спосіб забезпечення тимчасової зворотної сумісності, щоб споживачі могли перейти на нові функції. Не слід сподіватися, що застаріла функціональність залишатиметься нескінченно. Якщо стара функціональність залишиться, немає ніяких причин знецінювати її.

— Ерік Кінг

17

Це залежить виключно від того, яку стабільність ви гарантуєте своїм користувачам, і скільки болю ви хочете заподіяти своїм користувачам.

В ідеалі ваш API використовує semver, так що будь-яка зміна приводить до збільшення номера основної версії. На практиці бажано робити це майже ніколи. Якщо ваш API встановлено через якийсь менеджер пакунків, вам, можливо, захочеться створити нове ім'я пакета після перервної зміни, щоб просте оновлення не викликало конфліктів (наприклад, myapi2 v2.123.4проти myapi3 v3.2.1). Це може бути непотрібним, якщо ваш менеджер пакунків підтримує жорсткіші залежності версій (наприклад, специфікація залежності, така ~v2.120, яка не включає v3.*), але різні назви пакунків мають перевагу в тому, що несумісні версії можуть бути використані поруч дуже легко. Навіть при використанні semver може бути розумним період депресії.

Semver застосовується не завжди. Тоді важливіше повідомляти чітку політику стабільності. Наприклад:

Експериментальні особливості можуть бути видалені без попереднього повідомлення.
Особливості можуть бути видалені з міркувань безпеки в будь-який час.
Інші функції будуть видалені лише
- … Після того, як було вимкнено у випущеній версії
- … Де цій версії принаймні три місяці
- … І буде позначено шишкою в основній версії.

Така політика працює особливо добре, коли у вас є регулярні випуски, щоб був чіткий термін депресії, наприклад, один рік.

Окрім позначення будь-яких частин API як застарілих, вам слід зробити депрекацію широко відомою. Наприклад:

Майте у своєму журналі змін розділ про майбутні вказівки та анулювання.
Передайте свій намір зняти з ладу перед тим, як здійснити депресію, і слухайте спільноту, щоб побачити, чи є суттєві заперечення.
Повідомте, які вигоди будуть мати ці зміни. Залежно від вашої бази користувачів, інформаційні бюлетені, презентації, дописи в блогах або прес-релізи можуть бути відповідними засобами масової інформації. Закрутившись "ми створюємо дивовижну нову функцію! (для цього потрібно видалити цю широко використовувану стару функцію) "трохи менше неприємно, ніж видалення функції без контексту.

Що стосується точного терміну амортизації, який слід вибрати, то спочатку подивіться, чи потрібно виконувати будь-які договори про підтримку з вашими користувачами. Такі договори можуть вимагати збереження сумісності протягом певного періоду. Якщо ні, врахуйте будь-який вплив за течією. Постарайтеся змінитись менш швидко, ніж наступні користувачі, щоб вони могли пройти власний цикл анулювання. Користувачам, які перебувають у нижній частині мережі, знадобиться деякий час, щоб адаптуватися до ваших змін, тому ви ніколи не повинні мати амортизаційний період, менший за місяць.

— амон
джерело

3

Зважаючи на це:

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.

Який сенс використовувати semver для вказівки на порушення змін, якщо ви слідуєте за цим, кажучи, що ніколи не слід вводити нову основну версію?

— mrsmn

6

Чи дійсно гарна ідея перейменувати пакет, якщо відбулися серйозні зміни? Ось для чого номери версій. Я ненавиджу, коли вони також перейменовують їх, це дійсно заплутує управління залежністю Maven.

— AJPerez

@AJPerez Я розумію, що це не ідеально, але це може запобігти конфліктам у великих графах залежності з транзитивними залежностями: я залежу від libfoo, який залежить від libconflict v1.2.3, і я також залежу від libbar, який залежить від libconflict v2.3.4. Тоді я не можу вибрати жодну версію libconflict, яка задовольняє всі залежності - якщо тільки libconflict і libconflict2 не є різними пакетами. Спеціально для Java таке перейменування дратує b / c. Я повинен змінити весь імпорт. На щастя, Java 9 (модулі) підтримує використання конфліктуючих версій.

— амон

1

@mrsmn Порушення змін дратують, однак ви пакуєте або називаєте їх. Semver вирішує лише невелику частину цієї проблеми: бути в змозі сказати, чи не вдасться оновити щось. Але після того, як у вас відбудеться переломна зміна, вам доведеться витратити зусилля на їх зміну. Тому краще, якщо API дуже намагаються бути максимально стабільними. В ідеалі вони розроблені таким чином, щоб їх можна було розширити, не порушуючи зворотної сумісності.

— амон

@AJPerez так. Так, це добре. Люди весь час накручують версії. Виправлення помилок (імовірно xxx ++) часто ламаються (припускається x ++. Xx). Як вказує Амон, у вас (і я маю на увазі, що ви як користувач залежності) у вас є проблема, яку вам доведеться виправити. Я знаю, що мій код працює з foo 3.2.1, він може працювати з foo 3.3.0. Я знаю, що мій код працює з foo, він може працювати з foo-2. Я використовую semver, оскільки популярність, і вона не шкодить сама по собі, але мені дійсно не зрозуміло, що вона купує тобі все так багато.

— Джаред Сміт

14

В ідеалі, ви хочете зачекати, поки ніхто більше не використовує застарілий метод. Зважаючи на те, що ви використовуєте загальнодоступний API, це легко відстежувати, але ви, можливо, очікуєте дуже довго.

у 2015 році у Google виникли подібні проблеми з API stlport на їх ОС Android. Вони його зняли і хотіли видалити, але багато додатків все ще використовували його. Вони знайшли розумне рішення:

По суті, вони додали 8-секундний сон () під час завантаження будь-якої програми, яка все ще використовувала API з відповідним повідомленням журналу для розробників. Через місяць вони подвоїли його до 16 секунд. потім ще через місяць вони могли безпечно видалити інтерфейс API, оскільки ніхто не залишився ним користуватися.

Це може бути дуже ефективним способом зробити це. Єдине справжнє питання - якщо ваш API дуже старий і активно використовує споживачів, які більше не підтримуються активно. На жаль, ви, ймовірно, не зможете самостійно виправити таких споживачів, але в цей момент ви дійсно не можете зробити більше, ніж видалити метод і зламати споживача.

— Nzall
джерело

5

Симпатичний. Дуже мило.

— Девід Хаммен

8

Мінімальний час надання застарілих методів залежить від циклів розробки програм, що використовують ваш API. Як цифра бального парку, 1 року має бути достатньо.

Що стосується максимального часу, перш ніж вам доведеться видаляти застарілі методи, я б стверджував, що такого немає. Незалежно від того, як довго ви чекаєте, видалення застарілого методу завжди щось порушить. Деякі програми, що використовують застарілий API, не підтримуються активно, і порушення сумісності означатиме кінець терміну служби для таких програм.

Я пропоную вам видалити застарілі методи, коли ви отримуєте щось від видалення :

виявляється помилка, яка конкретно впливає на застарілі методи
Ви збираєтесь переробити код і підтримка застарілих методів потребує значних зусиль
ви оптимізуєте внутрішню структуру вашої бібліотеки, а застарілі методи вже не вписуються.

Видалення застарілих методів лише тому, що вони були застаріли протягом X місяців / років або через те, що ви випускаєте нову версію, означає безпідставно завдавати шкоди сумісності.

— Дмитро Григор’єв
джерело

7

Спочатку слід подумати про те, чи хочете ви застаріле чи застаріле.

Застарене слід використовувати для методів, які певним чином шкідливі: безпека, продуктивність, неправильні результати. Ви хочете позбутися від них відносно швидко, не більше 2-х основних версій і пішли до 3-ї. Для достатньо значних проблем застаріле може бути видалено в наступній другорядній версії.

Застарілий - це речі, які з якоїсь причини є менш корисними, наприклад, повертає менше інформації або також не працює, не включає стільки варіантів тощо. Вони можуть зависати нескінченно, але повинні як мінімум бути присутніми в наступній великій версії.

— jmoreno
джерело

Я б сказав, що метод, що дає неправильні результати або шкодить безпеці, повинен бути негайно відключений або виправлений. Метод із поганою роботою може зависати нескінченно, доки його ефективність є прийнятною для деяких користувачів.

— Дмитро Григор’єв

@DmitryGrigoryev: єдина незначна версія досить близька до одразу.

— jmoreno

4

Відповідь залежить від того, яку послугу ви надаєте своїм клієнтам.

З одного боку крайності, в Windows.h з епохи Win 3.1 є помилки, які розповсюджувались протягом двох десятиліть, оскільки Microsoft дуже сильно вірив у зворотну сумісність.

На іншому кінці спектру багато веб-додатків видаляють функції, навіть не надаючи попередження про депресію.

Скільки ваших клієнтів платять за ваше програмне забезпечення, часто має значення, як і їхня робота. Вчені-дослідники, як правило, більш охоче сприймають депресію як частину маршу прогресу, ніж, скажімо, банкіри чи FAA.

Я працював у компанії, що розробляє програмне забезпечення для внутрішнього використання. Я підтримував багато груп протягом багатьох років. Одна група мав менталітет "ніколи не знімайте жодних ознак". Їм була потрібна можливість повернутися до файлів 5-10 років тому і робити аналіз на них у часових масштабах занадто швидко, щоб розробники могли повернути функції назад. Ставлення однієї групи було "переконайтесь, що всі застарілі в патч-нотах, тому ми можемо їх знайти пізніше ». В середині у нас була одна група, правило якої було "Особливості повинні бути зняті як мінімум для 1 версії з надрукованим попередженням, якщо вони використовуються перед їх видаленням". Ця група мала тестовий набір, який охоплював необхідні їм функції. Кожного разу, коли ми випускали нову версію, вони швидко запускали свій тестовий набір, щоб перевірити, чи не заподіює їм будь-яка депресія.

— Корт Аммон
джерело

4

Я підтримую відкритий API і мушу знести метод.

Навіщо це робити? Це тому, що є новий блискучий спосіб робити речі, тому старий метод зараз не відсторонений, але все ще працює добре? Або насправді потрібно застосувати старий метод, оскільки все принципово змінилося?

Якщо старий метод не спричиняє жодних фактичних проблем, і він може залишитися навколо, то він може також бути. Якщо вас не зламали, не виправляйте. Вам справді потрібно її видалити? Можливо, позначте його як застаріле і додайте до документації примітку про те, що інший метод може бути більш ефективним, або будь-яким іншим, але, мабуть, добре залишити його на місці.
Якщо старий метод дійсно потребує використання, тому що він викликає у вас головний біль від технічного обслуговування або через те, що він просто більше не має сенсу через інші зміни, тоді слідкуйте за його використанням та чітко повідомляйте про депресію клієнтам. Дайте їм чітку дату, після якої метод буде видалено. (В ідеалі насправді не видаляйте його негайно на цю дату: зачекайте, поки ніхто все ще не використовує його, перш ніж його фактично видалити. Можливо, потрібно буде піти швидше, якщо це справді спричиняє проблеми, але принаймні зачекайте, коли використання скасує мало.)
Якщо старий метод спричиняє проблеми із безпекою, можливо, вам доведеться рухатися швидше, ніж можливо, навіть видалити його без попередження, але вам слід документувати цю зміну десь дуже помітно, а також повертати розумні повідомлення клієнтам, які намагаються використовувати старий метод.

(Два інші пункти кулі добре висвітлені в інших відповідях, але я думаю, що перша - нова.)

— TRiG
джерело

1

Для публічного проекту видаліть його лише тоді, коли і лише в разі потреби.

Здійснюючи непотрібне видалення API, ви витрачаєте гроші компаніям та підрядникам таким чином, що навіть не можете обчислити через дорогий збір.

Хочете, щоб компанії та незалежні програмісти припинили використовувати ваш проект? Розбийте їх речі достатньо разів, коли вам не важливо, і ви будете в цьому човні в найкоротші терміни.

deprecation != eventual_removal. Якщо API небезпечний, ви його видаляєте. Якщо він просто старий, залиште його і документуйте його заміну.

— kayleeFrye_onDeck
джерело