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

Питання :

Який правильний спосіб вирішити помилку, яку вважав кінцевий користувач?

Розробка :

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

Теоретично, оскільки це незначне виправлення помилок, воно може кваліфікуватися як PATCH, що розглядається за семантичною версією: xyZ Однак, оскільки він порушує зворотну сумісність (навіть лише для кількох користувачів), це повинно бути ОСНОВНЕ збільшення: Xyz правильний? Чи може вона все-таки кваліфікуватися як PATCH (оскільки вона не задумана як функція), поки це документально підтверджено?

EDIT: У цьому конкретному випадку це помилка в API бібліотеки, що використовується внутрішньо, а також інші розробники.

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

Чи додає вартість помилка? Якщо так, то це більше особливість. Іноді "помилка" може закінчуватися як "особливість додавання вартості".

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

У цьому конкретному випадку це помилка в API бібліотеки, що використовується внутрішньо, а також інші розробники.

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

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

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

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

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

Оскільки помилка знаходиться в бібліотеці, ось ще один підхід, який ви можете застосувати:

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

2. Виправте помилку лише в клоні (і впровадьте всі інші зміни інтерфейсу, які ви хочете, поки ви знаходитесь у ньому).

3. Оголосити початкову функцію як застарілу.

4. Видаліть оригінальну функцію в майбутньому великому випуску.

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

У цьому конкретному випадку це помилка в API бібліотеки, що використовується внутрішньо, а також інші розробники.

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

• чи дійсно важливо виправити помилку, наприклад, тому що існує високий ризик дозволити користувачам вашого API збій свої програми, якщо помилка не виправлена? Або мова йде лише про узгодженість API?

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

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

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

(І так, якщо ви збираєтесь змінити API, який не є сумісним назад, номери версій повинні це чітко виражати, не важливо, називаєте ви це "помилкою" чи ні).

Прийняти це. Це може зробити весь ваш продукт.

GunZ: У «Дуелі» (онлайн-гра) була помилка, яку ви могли використовувати і постійно зловживати, щоб майже змінити весь геймплей (так званий K-Style; шукайте його на YouTube). Це зробило весь ігровий шлях більш складним; це потребувало майстерності та зробило його просто дивовижним та веселим .. настільки веселим, що навіть модератори відкрито використовували його як свій основний стиль гри.
Це те, що зробило гру.
Я не грав у роки, але до сьогодні, як геймер, це одна з моїх улюблених ігор усіх часів, тому що вона настільки заснована на навичках і просто така забава, і все це приголомшує саме через помилку.

Вони все-таки виправили це, але люди так ненавиділи, що чорти серйозно відвернули його.

Тож моя відповідь стабілізувати та підтримувати її (рефактор, якщо потрібно).

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