Que faire lorsque la fonctionnalité critique d'une dépendance est rompue et entrave le développement?

Hier, je travaillais sur un projet d'API Rails 5 qui utilise la bibliothèque agit comme taggable pour permettre aux choses d'avoir des balises (comme des questions sur SE). Rails 5 est actuellement en support alpha. Il existe actuellement un PR pour corriger un bug en attente de fusion avec master; le bogue a provoqué l'arrêt de ma branche de fonctionnalités à mi-chemin de la fin - je n'ai pu implémenter aucune des fonctionnalités de la bibliothèque car le chargement a été interrompu.

Comme solution rapide, j'ai simplement cloné le référentiel, corrigé le problème avec le même code que le PR, et pointé mon Gemfile (fichier de contrôle de version de dépendance) vers ma propre fourchette Github, jusqu'à ce que le correctif soit finalement réintégré dans master.

J'ai eu la chance que le correctif soit simple ( et que quelqu'un l'ait déjà fait ), j'ai donc pu contourner le problème. Mais que se passe-t-il si cette bibliothèque était essentielle au développement de mon application? Et si le correctif qui arrêtait mon développement n'était pas un problème répandu pour d' autres personnes , de sorte que le correctif ne s'est pas produit rapidement comme il l'a fait cette fois?

Imaginez que cette fonctionnalité devait être terminée avant le développement sur d' autres fonctionnalités dépendantes - que faites-vous dans cette situation? Et si, pour moi, le balisage était absolument essentiel pour la prochaine phrase de développement, où tout le reste en dépendait - mais la dépendance du balisage est bogue pour ma configuration? Que faire lorsque la fonctionnalité critique d'une dépendance empêche le développement d'une ou de plusieurs fonctionnalités?

Et, sûrement, les combats à l'épée sur des chaises de bureau pendant des heures ou des jours ne sont pas une option ...

C'est l'une des raisons pour lesquelles vous utilisez un logiciel open source, non?

Vous pourriez faire le même argument pour «que se passe-t-il si ma bibliothèque propriétaire très chère et fermée tombe soudainement? Avec un logiciel open source, vous avez au moins la possibilité de corriger ce bogue vous-même.

Si votre logiciel prend une dépendance critique à une bibliothèque open source, vous pouvez faire trois choses pour atténuer le risque:

1. Familiarisez-vous avec la base de code, peut-être même en contribuant vous-même. C'est une autre raison pour laquelle vous avez choisi l'open source, non?

2. Avoir une bibliothèque de secours si la première bibliothèque tombe en panne. C'est pourquoi vous programmez sur des interfaces; afin que vous puissiez modifier la mise en œuvre si vous le devez, non?

3. Équilibrez votre désir de pointe avec votre besoin de stabilité (c'est-à-dire n'utilisez pas de logiciel alpha). Vous saviez dans quoi vous vous embarquiez, non?

La solution pour développer des applications où les bogues ou le manque de fonctionnalités ont un risque élevé d'arrêter votre travail est de ne pas utiliser de bibliothèques à haut risque. Ennuyeux et boiteux, je sais ..

Vous avez dit que c'était une version alpha. N'utilisez pas de versions alpha pour des projets critiques. Ce n'est même pas une version bêta, encore moins 1.0, donc ce genre de chose est à prévoir. L'intérêt de cette étape d'un projet est de trouver des problèmes et de durcir le projet.

Si vous vous trouvez dans cette situation, vous devez essentiellement faire ce que vous avez fait (nous avons fait exactement la même chose). Réparez-le et PR le projet.

Mais la solution utilise des bibliothèques plus stables avec des fonctionnalités et des API bien comprises ou tout au moins en maintenant la compatibilité descendante avec une version stable. Vous devez vous méfier à 100% de ce que vous n'avez aucun contrôle et dont vous avez besoin pour réussir.

Il est généralement recommandé de masquer les bibliothèques tierces derrière les adaptateurs ou les wrappers que vous écrivez vous-même. Cela présente deux avantages:

• Vous pouvez échanger la bibliothèque tierce avec une autre sans changer aucun de votre code
• Vous pouvez programmer le reste de votre code sur votre propre interface d'adaptateur. En cas de problème temporaire avec la bibliothèque, branchez simplement votre propre stub / fake ou version simplifiée des fonctionnalités de la bibliothèque. De cette façon, le développement et les tests de vos fonctionnalités en aval ne sont pas bloqués (même si le déploiement du programme complet l'est toujours).