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

13

Ieri stavo lavorando a un progetto API Rails 5 che utilizza il act-as-taggable-on per consentire alle cose di avere tag (come le domande su SE). Rails 5 è in supporto alfa in questo momento. Al momento c'è un PR per correggere un bug in attesa di essere fuso in master; il bug ha causato il blocco del mio ramo di funzionalità a metà del completamento: non è stato possibile implementare alcuna funzionalità della libreria perché il caricamento è stato interrotto.

Come soluzione rapida, ho semplicemente clonato il repository, risolto il problema con lo stesso codice del PR, e ho indirizzato il mio Gemfile (file di controllo delle versioni di dipendenza) alla mia forcella Github, fino a quando il bugfix non è stato ricollegato master.

Sono stato fortunato che la correzione fosse semplice ( e che qualcuno l'avesse già fatto ), quindi sono stato in grado di aggirare il problema. Ma cosa succede se questa libreria è stata fondamentale per lo sviluppo della mia applicazione? Che cosa succede se il bugfix che interrompeva lo sviluppo mio non era un problema diffuso per altre persone , quindi la correzione non si presentava rapidamente come in quel momento?

Immagina che questa funzionalità debba essere completata prima dello sviluppo su altre funzioni dipendenti - che cosa fai in quella situazione? Cosa accadrebbe se, per me, il tagging fosse assolutamente critico per la frase successiva di sviluppo, dove tutto il resto si basava su di esso - ma la dipendenza di tagging è infestata dalla mia configurazione? Che cosa si fa quando una funzionalità critica di una dipendenza impedisce lo sviluppo di (a) funzionalità (i)?

E, sicuramente, combattimenti con le spade sulle sedie da ufficio per ore o giorni non è un'opzione ...

    
posta Chris Cirefice 18.05.2016 - 03:09
fonte

3 risposte

19

Questa è una delle ragioni per cui stai usando software open source, giusto?

Potresti fare lo stesso argomento per "cosa succede se la mia libreria molto costosa, proprietaria, closed-source cade improvvisamente? Ci sarà qualcuno disponibile in [grande, società di software monolitico] per sistemarlo per me?" Con il software open-source, almeno hai la possibilità di risolvere il problema da solo.

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

  1. Acquisisci familiarità con la base di codice, magari anche apportando contributi tu stesso. 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 modificare l'implementazione se necessario, giusto?

  3. Equilibra il tuo desiderio di sanguinare contro il tuo bisogno di stabilità (ad esempio, non utilizzare il software alpha). Sapevi in cosa ti stavi cacciando, vero?

risposta data 18.05.2016 - 03:36
fonte
11

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

Hai detto che questa è una versione alpha. Non utilizzare versioni alfa per progetti critici. Non è nemmeno una versione beta, né tantomeno 1.0, quindi è normale aspettarsi questo genere di cose. L'intero punto di questa fase di 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 intese o almeno mantenendo la retrocompatibilità con una versione stabile. Dovresti essere cauto a dipendere al 100% da qualcosa su cui non hai alcun controllo e richiede di avere successo.

    
risposta data 18.05.2016 - 03:35
fonte
1

Di solito si consiglia di nascondere le librerie di terze parti dietro adattatori o wrapper che scrivi tu stesso. Questo ha due vantaggi:

  • Puoi sostituire la libreria di terze parti con un'altra senza modificare il tuo codice
  • È possibile programmare il resto del codice sulla propria interfaccia adattatore. In caso di problemi temporanei con la libreria, è sufficiente collegare la propria versione stub / falsa o semplificata della funzionalità della libreria. In questo modo sviluppo e testing delle funzionalità downstream non sono bloccati (anche se la distribuzione del programma completo è ancora).
risposta data 25.05.2016 - 23:01
fonte

Leggi altre domande sui tag