Что делать, если критическая функциональность зависимости нарушена и препятствует развитию?

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

В качестве быстрого исправления я просто клонировал репозиторий, исправил проблему с тем же кодом, что и PR, и указал мой Gemfile (файл управления версиями зависимостей) на мой собственный форк Github, пока исправление не было окончательно слито обратно в master.

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

Представьте, что эту функцию нужно было завершить до разработки других зависимых функций - что вы делаете в этой ситуации? Что, если для меня тегирование было абсолютно критическим для следующей фразы разработки, где все остальное полагалось на нее - но зависимость тегирования прослушивается для моей конфигурации? Что делать, когда критическая функциональность зависимости мешает разработке (а) функции (ий)?

И, конечно же, бои на мечах на офисных креслах в течение нескольких часов или дней не вариант ...

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

Вы могли бы привести тот же аргумент в отношении того, «что произойдет, если моя очень дорогая, проприетарная библиотека с закрытым исходным кодом внезапно упадет? Будет ли кто-нибудь в [крупной монолитной софтверной компании] кто-нибудь, кто позаботится об этом?» С программным обеспечением с открытым исходным кодом, по крайней мере, у вас есть шанс исправить эту ошибку самостоятельно.

Если ваше программное обеспечение имеет критическую зависимость от библиотеки с открытым исходным кодом, вы можете сделать три вещи, чтобы снизить риск:

1. Познакомьтесь с базой кода, возможно, даже сделав взнос сами. Это еще одна причина, почему вы выбрали open-source, верно?

2. Иметь запасную библиотеку, если первая библиотека падает. Вот почему вы программируете на интерфейсы; так что вы можете изменить реализацию, если нужно, верно?

3. Сбалансируйте ваше стремление к передовой линии с вашей потребностью в стабильности (т.е. не используйте альфа-программное обеспечение). Вы знали, во что ввязались, верно?

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

Вы сказали, что это альфа-релиз. Не используйте альфа-релизы для критических проектов. Это даже не бета-версия, не говоря уже о 1.0, так что такого рода вещи следует ожидать. Весь смысл этого этапа проекта - найти проблемы и укрепить проект.

Если вы окажетесь в такой ситуации, вам придется делать то, что вы делали (мы сделали то же самое). Исправь это и пиши проект.

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

Обычно рекомендуется прятать сторонние библиотеки за адаптерами или обертками, которые вы пишете сами. Это имеет два преимущества:

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