Как долго ждать перед удалением устаревшего метода? [закрыто]


38

Я поддерживаю общедоступный API и должен осудить метод.

Существует ли общее правило о том, за сколько месяцев / лет / версий до удаления я должен отказаться от метода?


27
Общее правило: «держите его так долго, как вам и / или вашим клиентам».
Роберт Харви

15
Определите «общественность». Бесплатное программное обеспечение с открытым исходным кодом, с обычной оговоркой «использовать на свой страх и риск»? Или проданное программное обеспечение там, где существует контракт?
Док Браун

11
Это очень сильно зависит от того, на каком рынке находятся ваши пользователи и платят ли они вам деньги за API.
17 из 26

10
Это также зависит от того, почему вы «должны» обесценивать это; старый способ является угрозой безопасности? Вы только что нашли причину, по которой старый способ в корне и нестабильно нестабилен из-за неудачного дизайнерского решения? Является ли старый способ намного медленнее, чем раньше? У вас заканчивается память на вашей целевой системе (например, встроенной системе), и вы буквально не можете разместить на ней оба API? Или вы просто нашли «лучший» способ и просто хотите очистить старый код, чтобы уменьшить накладные расходы на обслуживание?
августа

8
java.io.StringBufferInputStreamустарело с JDK 1.1 (1997?). Нет хорошего или неправильного ответа на этот вопрос. Это зависит от ваших потребностей для обеспечения обратной совместимости.
Laiv

Ответы:


52

Как минимум, вы должны хранить устаревшие методы в одной версии, прежде чем удалять их, что кажется довольно очевидным, когда я пишу их. Я не думаю, что есть максимальное время, но если вы никогда не удаляете их, устаревание становится немного бессмысленным.

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


58
Устаревание не обязательно о возможном удалении, поэтому устаревание без удаления не имеет смысла (и часто является правильным, если важна обратная совместимость). Зачастую речь идет не более чем о том, что «теперь у нас есть лучший способ, поэтому вам больше не следует так поступать».
Чао

9
@cHao Если что-то устарело, не стоит ожидать, что оно останется там. Я полагаю, если вы хотите сделать специальное заявление в своем проекте, в котором говорится, что вы не удалите устаревшую функциональность, это нормально, но в противном случае да, подразумевается, что будет возможное удаление. Я хочу сказать, что если вы не будете придерживаться какой-то строгости, люди могут поверить, что этого никогда не произойдет. Это появилось в последних версиях Java, где функциональность, которая была устаревшей в течение десятилетия или более, теперь удаляется.
JimmyJames

6
@cHao Я бы предпочел, чтобы проект удалил устаревшую функциональность. Преимущество не только в том, что пользователи фактически мотивированы для переключения, но и в том, что устаревший интерфейс не мешает другим улучшениям.
jpmc26

9
@cHao Это контекстно-зависимая вещь. По моему опыту политика амортизации ясна. Ясно сказано, что устаревшая функциональность будет удалена в будущем. Часто устаревшие функциональные возможности имеют проблемы, делающие их проблематичными для использования, и это не просто вопрос того, цените ли вы обратную совместимость или нет.
JimmyJames

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

17

Это зависит исключительно от того, какие гарантии стабильности вы дали своим пользователям, и какую боль вы хотите причинить своим пользователям.

В идеале ваш API использует semver, так что любое критическое изменение приводит к увеличению номера основной версии. На практике желательно делать это практически никогда. Если ваш API установлен через некоторый менеджер пакетов, вы можете захотеть создать новое имя пакета после критического изменения, чтобы простое обновление не вызывало конфликтов (например, myapi2 v2.123.4vs myapi3 v3.2.1). Это может быть ненужным, если ваш менеджер пакетов поддерживает более жесткие зависимости версий (например, спецификация зависимостей ~v2.120не включает в себя v3.*), но у разных имен пакетов есть преимущество, заключающееся в том, что несовместимые версии могут очень легко использоваться рядом. Даже при использовании 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 такое переименование раздражает, потому что я должен изменить весь импорт. К счастью, Java 9 (модули) поддерживает использование конфликтующих версий.
Амон

1
@mrsmn Срочные изменения раздражают, как бы вы их ни называли. Semver решает только небольшую часть этой проблемы: возможность определить, не нарушит ли обновление что-либо. Но как только у вас произойдет серьезное изменение, вам все равно придется приложить усилия, чтобы приспособиться к этим изменениям. Поэтому лучше, если API очень стараются быть максимально стабильными. В идеале они разработаны таким образом, чтобы их можно было расширять, не нарушая обратной совместимости.
Амон

@ AJPerez да. Да, это хорошо. Люди все время портят версионность. Исправления ошибок (предположительно, ххх ++) часто ломаются (предположительно, х ++. Хх). Как указывает Амон, у вас (и я имею в виду, что вы как пользователь зависимости) есть проблема, которую вы должны решить. Я знаю, что мой код работает с foo 3.2.1, он может работать с foo 3.3.0. Я знаю, что мой код работает с foo, он может работать с foo-2. Я использую semver, потому что это популярность, и она сама по себе не вредит, но мне действительно не ясно, сколько она вам покупает.
Джаред Смит

14

В идеале вам следует подождать, пока никто не использует устаревший метод. Учитывая, что вы используете общедоступный API, это легко отследить, но вы можете ждать очень долго.

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

введите описание изображения здесь

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

Это может быть очень эффективным способом сделать это. Единственная реальная проблема - если ваш API очень старый и активно использует потребителей, которые больше не поддерживаются. К сожалению, вы, вероятно, не сможете исправить таких потребителей самостоятельно, но на этом этапе вы не сможете сделать гораздо больше, чем просто удалить метод и сломать потребителя.


5
Милый. Очень мило
Дэвид Хаммен

8

Минимальное время предоставления устаревших методов зависит от циклов разработки программ с использованием вашего API. Как приблизительная цифра, 1 год должно быть достаточно.

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

Я предлагаю вам удалить устаревшие методы, когда вы получаете что-то от удаления :

  • обнаружена ошибка, которая особенно влияет на устаревшие методы
  • вы собираетесь реорганизовать код, и поддержание устаревших методов потребует значительных усилий
  • вы оптимизируете внутреннюю структуру вашей библиотеки, а устаревшие методы больше не подходят.

Удаление устаревших методов только потому, что они устарели в течение X месяцев / лет или потому, что вы выпускаете новую версию, означает произвольное нарушение совместимости без уважительной причины.


7

Сначала вы должны подумать, хотите ли вы устареть или устареть.

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

Устаревшие - для вещей, которые по какой-то причине менее полезны, например, возвращают меньше информации или не работают, не включают столько опций и так далее. Они могут зависать бесконечно, но должны присутствовать как минимум в следующей основной версии.


Я бы сказал, что метод, дающий неправильные результаты или наносящий ущерб безопасности, должен быть либо немедленно отключен, либо исправлен. Метод с плохой производительностью может зависать бесконечно, если его производительность приемлема для некоторых пользователей.
Дмитрий Григорьев

@DmitryGrigoryev: единственная минорная версия довольно близка к немедленной.
Jmoreno

4

Ответ зависит от того, какую услугу вы предоставляете своим клиентам.

С одной стороны, в Windows.h есть ошибки эпохи Win 3.1, которые распространялись в течение двух десятилетий, потому что Microsoft очень сильно верила в обратную совместимость.

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

То, сколько ваши клиенты платят за ваше программное обеспечение, часто имеет значение, равно как и их направление работы. Исследователи, как правило, более охотно принимают амортизацию как часть прогресса, чем, скажем, банкиры или ФАУ.

Я работал в компании, занимающейся разработкой программного обеспечения для внутреннего использования. Я поддерживал многие группы на протяжении многих лет. У одной группы был менталитет «никогда не удаляй никакую особенность». Им нужна была возможность вернуться к файлам 5-10 лет назад и провести анализ по ним в слишком сжатые сроки, чтобы разработчики могли вернуть функции обратно. Позиция одной группы заключалась в том, чтобы «убедиться, что все замечания устарели в примечаниях к исправлению, поэтому мы могу найти их позже. " В середине у нас была одна группа, правило которой было «Не рекомендуется использовать функции как минимум для 1 версии с напечатанным предупреждением, если они используются перед их удалением». У этой группы был набор тестов, который охватывал нужные им функции. Всякий раз, когда мы выпускали новую версию, они быстро запускали свой набор тестов, чтобы проверить, не мешает ли им какая-либо из устаревших версий.


4

Я поддерживаю общедоступный API и должен осудить метод.

Зачем тебе это нужно? Это потому, что есть новый блестящий способ сделать что-то, поэтому старый метод сейчас не рекомендуется, но все еще работает нормально? Или старый метод на самом деле должен пойти, потому что вещи в корне изменились?

  • Если старый метод не вызывает каких-либо реальных проблем, и может остаться, то он может также. Если не сломано, не чини. Вы действительно должны удалить это? Может быть, пометить его как устаревший и включить примечание в документацию о том, что другой метод может быть более эффективным, или что-то еще, но, вероятно, хорошо оставить его на месте.

  • Если старый метод действительно нужен, потому что он вызывает у вас проблемы с обслуживанием или просто не имеет смысла из-за других изменений, то следите за его использованием и четко сообщайте об устаревании клиентам. Дайте им четкую дату, после которой метод будет удален. (В идеале, не удаляйте его сразу в эту дату: подождите, пока никто не использует его, прежде чем фактически удалить его. Может потребоваться, чтобы он пошел раньше, если это действительно вызывает проблемы, но, по крайней мере, дождитесь, пока использование не прекратит маленький.)

  • Если старый метод вызывает проблемы с безопасностью, вам, возможно, придется двигаться быстрее, возможно, даже удаляя его без предупреждения, но вы должны задокументировать это изменение где-то очень заметным, а также вернуть разумные сообщения клиентам, которые пытаются использовать старый метод.

(Вторые два пункта маркера хорошо освещены в других ответах, но я думаю, что первый является новым.)


1

Для публичного проекта удалите его только тогда и только тогда, когда вам это нужно.

Когда вы делаете ненужное удаление API, вы стоите денег для компаний и подрядчиков таким образом, что вы даже не можете рассчитать из-за дорогого оттока.

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

deprecation != eventual_removal, Если API опасен, вы удалите его. Если он просто старый, оставьте его и запишите его замену.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.