Що робити, коли критична функціональність залежності порушена і перешкоджає розвитку?

Вчора я працював над проектом API Rails 5, який використовує бібліотеку act-as-taggable-on, щоб дозволити речам мати теги (наприклад, питання щодо SE). Rails 5 зараз є альфа-підтримкою. В даний час є PR, щоб виправити помилку, яка чекає, щоб її об'єднати в головний; помилка спричинила зупинку моєї гілки функцій на півдорозі завершення - я не зміг реалізувати жодну функціональність бібліотеки, оскільки завантаження було порушено.

В якості швидкого виправлення я просто клонував репо, виправляв проблему тим самим кодом, що і PR, і вказав свій Gemfile (файл управління версією залежності) до моєї власної вилки Github, поки помилка остаточно не об'єдналася назад у майстер.

Мені пощастило, що виправлення було простим ( і що хтось це вже зробив ), тому мені вдалося обійти проблему. Але що робити, якщо ця бібліотека мала вирішальне значення для розробки мого додатка? Що робити, якщо помилка, яка зупиняла мій розвиток, не була проблемою для інших людей , тому виправлення не з’явилося так швидко, як це було цього разу?

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

І, безумовно, бої на мечах на офісних стільцях годинами чи днями - це не варіант ...

Це одна з причин, коли ви використовуєте програмне забезпечення з відкритим кодом, правда?

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

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

1. Ознайомтеся з базою коду, можливо, навіть робите внески самостійно. Це ще одна причина, чому ви вибрали відкритий код, правда?

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

3. Збалансуйте своє бажання кровотечі перед потребою стабільності (тобто не використовуйте програмне забезпечення альфа). Ви знали, в що потрапляєте, правда?

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

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

Якщо ви опинилися в цій ситуації, вам в основному потрібно зробити те, що ви зробили (ми зробили абсолютно те саме). Виправте це та піар проект.

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

Зазвичай рекомендується ховати сторонні бібліотеки за адаптерами або обгортками, які ви самі пишете. Це має подвійні переваги:

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