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

Нещодавно я натрапив на бібліотеку Python на GitHub. Бібліотека чудова, але містить одну яскраву помилку в назві функції. Давайте назвемо це, dummy_fuction()поки має бути dummy_function(). Ця функція, безумовно, "в природі" і, швидше за все, використовується у вбудованих системах.

Перше, що спадає на думку, - це додати другу версію функції з правильним ім'ям та додати попередження про депресацію до першої версії для наступного випуску.

Три питання:

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

— Джеймі Булл
джерело

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

— Джорджо

дивіться також HTTP referer [sic]

— AakashM

Я також зазначив би модуль Apache , але це могло бути навмисно.

— Відновіть Моніку ямнотмайнар

@AakashM: Мені подобається, що стаття у Вікіпедії зараз використовує як неправильне, так і правильне написання на всій цій сторінці (навіть при посиланні на об’єкт, а не на термін), при цьому версія з помилковою написанням є більш поширеною!

— Martijn Pieters

Ще один добрий шматочок про http_referer- "Це як коли я робив референтне поле. У мене не було нічого, крім горя за свій вибір правопису. Зараз я намагаюся виправити написання в УЗД, оскільки моє написання використовується кілька мільярдів разів на хвилину більше ніж їх ». - Філіп Халлам-Бейкер

— Джеймі Булл

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

Я думаю, що ваше запитання цікаве, але в основному на основі думки.

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

Чи може підхід, що описаний вище, мати якісь ненавмисні наслідки?

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

Чи є стандартний підхід до подібного роду проблем?

Не робіть орфографічних помилок під час написання бібліотеки;)

Як довго повинно залишатися якесь попередження про припинення роботи?

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

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

Просто переконайтесь, що це вказано в журналі змін: хлопці, якщо ви використовували dummy_fuction, замініть його dummy_functionскрізь, і ви готові їхати.

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

— Конрад Моравський
джерело

Приємно чути. Бібліотека узагальнена, тому підхід до контролю версій звучить добре. Насправді він має свій власний IDE, тому неправильно написана версія може бути прихована від інструменту для заповнення коду, який повинен зупинити використання нових користувачів. Якби я міг дати вам ще +1 для відповіді на Q2, я б!

— Джеймі Булл

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

— Карл Ніколл