Quando devono essere aggiornate le dipendenze?

In generale dovresti aggiornare le dipendenze quando:

1. È richiesto
2. C'è un vantaggio a farlo
3. Non farlo è svantaggioso

(Questi non si escludono a vicenda.)

La motivazione 1 ("quando devi") è il driver più urgente. Alcuni componenti o piattaforme da cui dipendi (per esempio Heroku) lo richiedono e devi metterti in coda. Gli aggiornamenti richiesti spesso cadono a cascata da altre scelte; decidi di aggiornare alla versione di PostgreSQL così e così. Ora devi aggiornare i tuoi driver, la tua versione ORM, ecc.

L'aggiornamento perché tu o il tuo team percepite un vantaggio nel farlo è più morbido e più opzionale. Più di una chiamata di giudizio: "La nuova caratteristica, abilità, prestazioni, ... vale la pena e la dislocazione che la porterà causerà?" In Olden Times, c'era un strong pregiudizio contro gli aggiornamenti opzionali. Erano manuali e difficili, non c'erano buoni modi per provarli in un sandbox o in un ambiente virtuale, o per ripristinare l'aggiornamento se non ha funzionato, e non ci sono stati test automatici rapidi per confermare che gli aggiornamenti non "hanno stravolto il carrello della mela". Oggigiorno la tendenza è verso cicli di aggiornamento molto più rapidi e più aggressivi. I metodi agili adorano provare le cose; installatori automatici, gestori delle dipendenze e repository rendono il processo di installazione rapido e spesso quasi invisibile; gli ambienti virtuali e il controllo della versione onnipresente rendono facili rami, fork e rollback; e test automatici ci permettono di provare un aggiornamento quindi valutare facilmente e in modo sostanziale "Ha funzionato? Ha rovinato tutto?" Il pregiudizio è stato spostato all'ingrosso, da "se non è rotto, non aggiustarlo" alla modalità "aggiorna presto, aggiorna spesso" di integrazione continua e persino consegna continua .

La motivazione 3 è la più morbida. Le storie degli utenti non si occupano di "l'impianto idraulico" e non menzionano mai "e mantengono l'infrastruttura non più di N versioni precedenti a quella attuale". Gli svantaggi della deriva della versione (all'incirca, il debito tecnico associato alla caduta dietro la curva) invadono silenziosamente, quindi spesso si annunciano per rottura. "Scusa, quell'API non è più supportata!" Anche all'interno dei team Agile può essere difficile motivare l'incrementalismo e "stare al passo con" la freschezza dei componenti quando non è considerato fondamentale per completare uno sprint o una release. Se nessuno si difende per gli aggiornamenti, possono essere ignorati. Quella ruota potrebbe non cigolare fino a quando non sarà pronta a rompersi, o fino a quando non si rompe.

Dal punto di vista pratico, la tua squadra deve prestare maggiore attenzione al problema della deriva della versione. 2 anni sono troppo lunghi. Non c'è magia. È solo una questione di "pagami adesso o pagami più tardi". Affrontate il problema della deriva della versione in modo incrementale, oppure soffrite e poi superate i sobbalzi più grandi ogni pochi anni. Preferisco l'incrementalismo, perché alcuni degli scossoni della piattaforma sono enormi. Un'API o una piattaforma chiave dipendono dal non funzionare più può davvero rovinare il tuo giorno, settimana o mese. Mi piace valutare la freschezza dei componenti almeno 1-2 volte all'anno. È possibile pianificare le revisioni in modo esplicito o lasciarle agire organicamente dai cicli di aggiornamento relativamente metronomici, solitamente annuali, di componenti importanti come Python, PostgreSQL e node.js. Se gli aggiornamenti dei componenti non innescano il tuo team in modo molto strong, anche i controlli di freschezza sulle versioni principali, sugli altipiani del progetto naturale o su ogni k release possono funzionare. Qualunque cosa metta l'attenzione sulla correzione della deriva della versione su una cadenza più regolare.

Le biblioteche dovrebbero essere aggiornate quando devono essere aggiornate. Ciò significa che se l'aggiornamento non porta alcun valore, non dovresti.

Nel tuo caso particolare, stavi migrando da un vecchio stack tecnologico a uno nuovo, e per farlo dovevi aggiornare le tue dipendenze. In quel momento è il momento giusto per aggiornare le dipendenze.

Se avessi aggiornato le tue dipendenze nel tempo, al fine di "non avere un mal di testa ora", avresti dovuto investire molto tempo lavorativo (codifica) per nessun valore di ritorno. E quando dovevi fare l'ultimo aggiornamento (quello che stai facendo ora, ma l'aggiornamento di 1 versione principale invece di 4), probabilmente avrai ancora un mal di testa da qualche parte (dopo tutto, la versione principale significa interrompere i cambiamenti). Quindi penso che tu sia sulla strada giusta.

Tuttavia, se lo trovi troppo difficile da migrare e devi eseguire molti refactoring, è probabile che il problema sia nella base di codice. È abbastanza comune per i progetti Android non avere un'architettura generale in termini di struttura del codice. Una buona infrastruttura per le dipendenze come Dagger 2 e alcuni principi di ingegneria del software come SOLID avrebbe reso più facile cambiare l'implementazione del codice mantenendo lo stesso comportamento / requisiti.

Inoltre, dal momento che siamo in fase di refactoring, leggi un po 'di Unit Testing, perché sarebbe di grande aiuto quando fai questo tipo di lavoro.

Se si utilizzano strumenti di gestione dei pacchetti (ad esempio npm, NuGet) e una suite di test automatizzata completa, l'aggiornamento delle dipendenze dovrebbe essere un'attività a basso sforzo, semplicemente aggiornare il pacchetto, eseguire la suite di test e vedere se ci sono problemi . Se ci sono poi rollback e sollevare un oggetto di lavoro per indagare e risolvere il problema.

Finché il costo dell'aggiornamento delle dipendenze è basso, vale la pena tenerlo aggiornato:

• Se ci sono problemi con l'aggiornamento, vuoi sapere prima piuttosto che nel caso in cui siano richieste modifiche a monte.
• Lasciando gli aggiornamenti delle dipendenze all'ultimo minuto spesso significa che si stanno eseguendo gli aggiornamenti durante il crunch (ad es. in risposta a un bug critico per la sicurezza). Mantenersi al passo con le dipendenze significa che hai il controllo su quando spendi questo sforzo e puoi eseguire quegli aggiornamenti quando non sei così impegnato.
• Le versioni più recenti potrebbero avere miglioramenti della produttività, ad es. migliore documentazione, API più facile da usare, correzioni di bug (anche se è possibile anche il contrario).

Se l'aggiornamento delle dipendenze non è uno sforzo minimo (ad esempio perché è necessario testare manualmente l'aggiornamento o perché ci sono problemi noti / modifiche di rottura), è necessario valutare i pro e i contro delle altre attività. Le vecchie dipendenze sono una sorta di debito tecnico a basso interesse, e quindi dovrebbero essere trattate di conseguenza.

Penso che dipenda in un certo senso dalla libreria in questione, ma ho avuto anch'io mal di testa di dipendenza simile.

Il buon senso mi dice che una versione principale è probabilmente il momento giusto per l'aggiornamento, e una versione minore che risolve un difetto grave, o che include un vantaggio significativo, lo sostituirà.

A volte non abbiamo il lusso di lavorare su tutte le applicazioni che richiedono manutenzione, o anche di smobilitare quelle mission critical, ma alla fine ti morderanno e un grammo di prevenzione batte spesso un chilo di cura!

Non dovresti fare un rilascio in cui usi consapevolmente vecchie versioni delle tue dipendenze, a meno che quelle versioni siano alternative supportate.

Ad esempio, se si è su V1 ed è ancora supportato, è comunque possibile utilizzare l'ultima versione di v1.

L'unica volta che dovresti essere scaduto è se:

A: Non hai fatto un rilascio tra qualche tempo.

B: Sei stato su v1 tanto a lungo che non è più supportato

Gli aggiornamenti sono rilasciati per un motivo, contengono correzioni di sicurezza che dovresti tenere a bordo.

Se esce una nuova versione della tua dipendenza, dovresti anche fare un rilascio

Le librerie dovrebbero essere aggiornate quando offre un vantaggio che il software utilizzerà per compensare il lavoro speso nella modifica.

Anche gli aggiornamenti delle versioni di librerie minori possono interrompere o inserire incongruenze nelle app. Da quella prospettiva non ci sono cambiamenti minori.

Non c'è vergogna nell'usare le vecchie librerie. Quando il cambiamento è necessario può essere doloroso, ma fa parte del lavoro.