Вопрос :
Как правильно исправить ошибку, которая, по мнению конечного пользователя, была функцией?
Разработка :
Я предполагаю, что если большой процент пользователей ожидал, что это будет функция, ее следует оставить «нефиксированной» или «фиксированной», чтобы быть более стабильной? Однако, что если очень маленький процент пользователей ожидает, что это будет функция ... скажем, 0,1% или 1%, и эта ошибка должна быть исправлена.
Теоретически, поскольку это незначительное исправление ошибки, его можно квалифицировать как PATCH, что рассматривается семантическим версионированием: xyZ. Однако, поскольку он нарушает обратную совместимость (даже для нескольких пользователей), это должно быть ОСНОВНОЕ увеличение: Xyz Correct? Может ли он по-прежнему квалифицироваться как PATCH (поскольку он не был задуман как функция), если он задокументирован?
РЕДАКТИРОВАТЬ: В данном конкретном случае это ошибка в API библиотеки, используемой внутри, которую используют другие разработчики.
источник
Ответы:
Баг добавляет ценность? Если это так, это больше особенность. Иногда «ошибка» может закончиться как добавленная стоимость.
Трудно действительно ответить на это окончательно, потому что каждая ситуация будет отличаться.
В этом случае я бы включил исправление как часть вашего следующего критического изменения в отношении обратной совместимости. На самом деле вы не можете просто делать это последовательно в большинстве сред, и, вероятно, для этого есть график / сроки.
Как разработчик, последнее, с чем я хочу иметь дело, это API с некорректным или непоследовательным поведением. Ошибки считаются этим.
По крайней мере, создайте своего рода «известные ошибки с текущей версией» document / wiki внутри, чтобы вы могли убедиться, что все ваши внутренние пользователи знают, что функциональность похожа на ошибку. Надеюсь, у вас достаточно тестов, охватывающих области, в которых люди используют функцию «ошибка как функция», чтобы вы увидели, где / когда что-то сломается, когда / если вы исправите ошибку.
источник
Я бы порекомендовал сделать его более стабильным. Пользователи являются каноническим источником того, что делает ваше программное обеспечение. Если они хотят этого и стали полагаться на это, я бы дважды подумал о том, чтобы его дернуть.
Хорошим примером этого является механик «Лыжи» в видеоигре «Племена». Изначально ошибка в том, как физический движок обрабатывал прыжки с холма, в итоге оказалась одной из основных игровых механик. Вы можете прочитать немного больше об этом здесь , если вам интересно.
источник
Поскольку ошибка находится в библиотеке, вы можете воспользоваться еще одним подходом:
Сделать клон ошибочной библиотечной функции. Во многих случаях люди просто добавляют
2к имени функции в этих случаях, но, если у вас есть другие изменения, которые вы хотели бы применить к интерфейсу этой функции, вы могли бы также дать ему совершенно другое имя.Исправьте ошибку только в клоне (и реализуйте все другие изменения интерфейса, которые вы хотите, пока вы в нем).
Объявите исходную функцию как устаревшую.
Удалите оригинальную функцию в следующем выпуске.
Этот подход особенно полезен для функций, чей интерфейс в основном нарушен: вы не нарушаете пользовательский код сразу, но предупреждаете всех, кто полагается на сломанный код, чтобы перейти к использованию фиксированного кода. И даже если люди не прислушаются к предупреждению, они не могут винить вас, если вы действительно удалите нарушенную функцию.
источник
Если эти другие разработчики считали, что поведение является функцией, вероятно, они использовали ее и создали на ней работающее программное обеспечение . Исправление ошибки, вероятно, сломает их существующий код, и они обвинят вас в этом. Это делает исправление ошибки компромиссом, и вы должны учитывать
действительно ли важно исправить ошибку, например, потому что существует высокий риск того, что пользователи вашего API могут аварийно завершить работу своих приложений, если ошибка не исправлена? Или это только о согласованности API?
или важнее сохранить стабильность существующего программного обеспечения и обратную совместимость вашей библиотеки?
Ответ на этот вопрос не всегда прост: вы должны принять во внимание количество возможных пользователей вашего API, потенциальный объем работы, который им потребуется для изменения своего программного обеспечения, количество программного обеспечения, которое сломается, если вы измените свой API но также и риски того, что может случиться, если вы этого не сделаете исправите API.
Только то, что вы документируете изменение исправления в «списке критических изменений в вашем следующем основном выпуске», не делает ваших клиентов счастливыми - если вы это сделаете, должны быть хотя бы некоторые пуленепробиваемые доводы, почему вы не могли бы позволить API так был раньше. Часто сохранение обратной совместимости важнее, чем исправление ошибки. Так что исправляйте это, только если вы можете оценить влияние на вашу пользовательскую базу и их программное обеспечение, и вы уверены, что не будете предпринимать необоснованные усилия для них, когда они попытаются обновить вашу последнюю версию библиотеки. И если у вас недостаточно информации, чтобы составить точную оценку, вероятно, лучше не менять поведение.
(И да, если вы собираетесь внести изменение в API, которое несовместимо с предыдущими версиями, ваши номера версий должны это четко выражать, независимо от того, назовете вы это «исправлением» или нет).
источник
Прими это. Это может сделать весь ваш продукт.
GunZ: в Duel (онлайн-игре) была ошибка, которую вы могли использовать и постоянно злоупотреблять, чтобы изменить практически весь игровой процесс (он называется K-Style; посмотрите его на YouTube). Это сделало всю игру более сложной; это потребовало умения и сделало его просто удивительным и веселым ... настолько забавным, что даже модераторы открыто использовали его в качестве основного стиля игры.
Это то, что сделало игру.
Я не играл годами, но по сей день, как геймер, это одна из моих любимых игр всех времен, потому что она настолько основанная на навыках и просто такая веселая, и вся эта удивительность только из-за ошибки.
В конце концов они это исправили, но люди ненавидели это так сильно, что разработчики серьезно отреагировали на это.
Поэтому мой ответ - стабилизировать и поддерживать его (рефакторинг, если необходимо).
Как говорится, эта прекрасная история, я не думаю, что один и тот же ответ применим ко всему, что не имеет прямого преимущества. Если ваша ошибка приводит к событию, которое вызывает преимущество, обычно будет разумнее исправить ошибку и найти другой способ добиться того, что он мог. Если это выходит за рамки, подумайте о том, чтобы исключить его только за то, что оно выходит за рамки, или создайте другой модуль (возможно, небольшой), чтобы представить его. В принципе: не нарушайте принцип единой ответственности .
источник