Come gestisci il cambiamento nei framework open source che utilizzi per i tuoi progetti?

Il problema non è unico per l'open source. Gli stessi problemi si verificano con i progetti commerciali. Forse ancora di più perché non hai una fonte puoi mantenerti se la compagnia cede il supporto.

I progetti open source di tipo utente finale hanno cicli di aggiornamento rapidi e le vecchie versioni perdono il supporto molto rapidamente. D'altra parte, i progetti che sono progettati per consentire agli utenti di inserire una significativa codifica dello sforzo tendono ad avere lunghi cicli di supporto della vecchia filiale dopo un importante aggiornamento. Abbastanza a lungo da permetterti di dedicare il tuo tempo prima che si stabilizzi e maturi, quindi esegui la migrazione e testate a fondo il tuo codice.

Può essere difficile resistere alla tentazione di avere l'ultimo e il più grande, ma rendersi conto che c'è un compromesso fondamentale nel software tra stabilità e nuove funzionalità. Non puoi averne uno senza sacrificare l'altro. Ecco perché esistono i rami di bugfix, quindi puoi scegliere quale lato dello spettro si adatta meglio alle tue esigenze.

Abbiamo risolto questo problema modularizzando il nostro codice.

Il nostro sito web principale è stato costruito circa otto anni fa, e siamo stati abbastanza fortunati da essere costruito da uno dei primi contributori al Framework di Primavera, quindi era una base abbastanza ben costruita. Ma sfortunatamente siamo stati anche sfortunati che questo sviluppatore ha deciso di lanciare Spring dopo una discussione sulla direzione in cui stava andando, quindi questo codebase è ora bloccato su un fork non mantenuto di Spring 1.1.4 (o qualcosa del genere).

Abbiamo provato a riscrivere il codice per passare a nuove versioni di Spring, ma ciò si è rivelato estremamente difficile. Quindi la nostra soluzione era iniziare a costruire nuove funzionalità del sito come moduli in un'applicazione completamente separata, usando i framework più recenti come Spring 3.x, Hibernate 3.6, ecc.

Ora abbiamo due applicazioni Web in esecuzione sullo stesso URL di base e usiamo il modulo mod_proxy di Apache per allocare ogni percorso all'applicazione appropriata. Ad esempio, "/ members" passa alla vecchia applicazione e "/ directories" va alla nuova applicazione. Tuttavia, un visitatore del sito non avrebbe idea di utilizzare applicazioni diverse; sembrano esattamente uguali per l'utente.

Le due applicazioni devono comunicare, ad esempio quando un utente accede al sito (usando la nostra nuova applicazione), dobbiamo notificare alla vecchia applicazione che ora sono loggati. Lo facciamo usando un semplice servizio web, esposto solo a localhost. La quantità di integrazione necessaria tra le due app è risultata minima.

Una parte importante del lavoro è stata quella di identificare e raggruppare insieme le risorse condivise. Quindi tutto il testo statico, i grafici, i fogli di stile, i Javascript e i modelli sono stati spostati dall'applicazione originale in un terzo progetto separato che utilizzano sia le nuove che le vecchie applicazioni. Ciò garantisce che entrambe le applicazioni Web guardino e agiscano allo stesso modo anche se sono completamente separate.

Immagino che col tempo sostituiremo sempre di più l'applicazione originale fino a quando non sarà completamente inutile. La cosa bella di questa tecnica è che possiamo farlo lentamente attraverso una serie di piccoli cambiamenti a basso rischio: non è necessario un massiccio e rischioso passaggio ad un nuovo sistema.

Non lo faccio sempre. Molti progetti open source hanno filiali di manutenzione attive mantenute per le precedenti versioni principali. A volte quelli sono mantenuti da persone che hanno bisogno di quella versione da mantenere. Molti progetti rimangono in una versione importante fino a quando non sono pronti per una pubblicazione importante.

And this is what gets me every time.

Ogni momento? Devi fare scelte pessime. Ci deve essere un esempio in cui non è successo.

When the devs start playing with a new shiny toy

Questo è un suggerimento. Evita i nuovi giocattoli scintillanti quando usi progetti open source. Evitare la versione 1.0.

How do you deal with radical changes in the open source projects that you use?

Passaggio 1. Scegli i progetti open source molto, molto attentamente. Confronta sempre due o più progetti in competizione.

Passaggio 2. Quando si confrontano due progetti in competizione, provare a comprendere la caratteristica "essenziale" che viene offerta e in che modo si avvicinano entrambi. Evita di "sposare" una specifica API troppo presto.

Passaggio 3. Abbracciare i principi di progettazione di "Late Binding" e "Loose Coupling". Prova ad isolare dalle modifiche del progetto open source.

Passaggio 4. Effettua esplicitamente il confronto costi / benefici tra progetti open source e "rolling your own". Una volta ogni tanto, la creazione della propria soluzione potrebbe essere migliore rispetto a una soluzione open source.

Cambiare i nomi dei file non dovrebbe essere troppo difficile. Sì, è una sceneggiatura brutta e grossa. Sì, deve essere eseguito per diverse settimane mentre si effettua la conversione. Ma è un costo finito.

Se succede ogni tempo, allora sviluppa strategie di coping migliori. Dato che la tua osservazione del mondo reale è che succederà sempre, allora sperare che il mondo reale cambierà non aiuterà molto. Hai qualche esperienza vincente nel cambiamento. Sfruttalo. Consideralo come un'infezione e sviluppa la tua risposta immunitaria.