Cosa fare quando la funzionalità critica di una dipendenza viene interrotta e impedisce lo sviluppo?

Ieri stavo lavorando a un progetto API di Rails 5 che utilizza la libreria act-as-taggable-on per consentire alle cose di avere tag (come domande su SE). Rails 5 è attualmente in supporto alfa. Al momento esiste un PR per correggere un bug in attesa di essere unito al master; il bug ha causato l'interruzione del ramo della mia funzione a metà del completamento: non ho potuto implementare nessuna delle funzionalità della libreria perché il caricamento era interrotto.

Come soluzione rapida, ho semplicemente clonato il repository, risolto il problema con lo stesso codice del PR e indirizzato il mio Gemfile (file di controllo della versione di dipendenza) al mio fork di Github, fino a quando il bugfix non è stato nuovamente unito al master.

Ho avuto la fortuna che la correzione fosse semplice ( e che qualcuno l'avesse già fatto ), quindi sono stato in grado di aggirare il problema. E se questa libreria fosse fondamentale per lo sviluppo della mia applicazione? E se la correzione di bug che stava interrompendo il mio sviluppo non fosse un problema diffuso per altre persone , quindi la correzione non è arrivata rapidamente come questa volta?

Immagina che questa funzione debba essere completata prima dello sviluppo su altre funzionalità dipendenti : cosa fai in quella situazione? E se per me il tagging fosse assolutamente critico per la prossima frase di sviluppo, in cui tutto il resto si basava su di esso - ma la dipendenza dal tagging è infastidita per la mia configurazione? Cosa si fa quando la funzionalità critica di una dipendenza impedisce lo sviluppo di (a) feature (s)?

E, sicuramente, i combattimenti con la spada sulle sedie da ufficio per ore o giorni non sono un'opzione ...

Questo è uno dei motivi per cui stai utilizzando un software open source, giusto?

Potresti fare lo stesso argomento per "cosa succede se la mia costosissima libreria proprietaria e chiusa cade all'improvviso? Ci sarà qualcuno disponibile presso [una grande società monolitica di software] per sistemarlo?" Con il software open source, almeno hai la possibilità di correggere tu stesso quel bug.

Se il tuo software assume una dipendenza critica in una libreria open source, ci sono tre cose che puoi fare per mitigare il rischio:

1. Acquisire familiarità con la base di codice, forse anche dare contributi da soli. Questo è un altro motivo per cui hai scelto open-source, giusto?

2. Avere una libreria di fallback se la prima libreria cade. Questo è il motivo per cui programmate le interfacce; in modo che tu possa cambiare l'implementazione se necessario, giusto?

3. Bilancia il tuo desiderio di spigolo con il tuo bisogno di stabilità (cioè non usare il software alfa). Sapevi in ​​cosa ti stavi cacciando, vero?

La soluzione per lo sviluppo di applicazioni in cui i bug o la mancanza di funzionalità presentano un rischio elevato di interruzione del lavoro è di non utilizzare librerie ad alto rischio. Noioso e zoppo, lo so ..

Hai detto che questa è una versione alfa. Non utilizzare le versioni alpha per progetti critici. Non è nemmeno una versione beta, figuriamoci 1.0 quindi questo genere di cose è prevedibile. L'intero punto di questa fase in un progetto è trovare problemi e rafforzare il progetto.

Se ti trovi in ​​questa situazione, in pratica devi fare quello che hai fatto (abbiamo fatto esattamente la stessa cosa). Risolvilo e PR il progetto.

Ma la soluzione sta usando librerie più stabili con funzionalità e API comprese o almeno mantenendo la retrocompatibilità con una versione stabile. Dovresti stare attento, dipendendo al 100% da qualcosa su cui non hai il controllo e che devi avere successo.

Si consiglia in genere di nascondere librerie di terze parti dietro adattatori o wrapper scritti dall'utente. Questo ha due vantaggi:

• Puoi scambiare la libreria di terze parti con un'altra senza cambiare il tuo codice
• È possibile programmare il resto del codice sulla propria interfaccia dell'adattatore. In caso di un problema temporaneo con la libreria, basta collegare la propria versione stub / fake o semplificata della funzionalità della libreria. In questo modo lo sviluppo e il test delle funzionalità a valle non vengono bloccati (anche se la distribuzione dell'intero programma è ancora).