In continua evoluzione quadri / API - come si fa a tenere il passo?

Question

Questa domanda non è davvero per una tecnologia specifica, ma più di questione generale degli sviluppatori.

Tutti sappiamo per esperienza che le cose cambiano. Frameworks evolvono, nuove caratteristiche sono aggiunte e roba del genere viene rimosso.

Per esempio, come potrebbe un prodotto utilizzando la versione 1.0 del framework "ABC" adattarsi quando la versione 2.0 viene avanti (ABC potrebbe essere .NET, Java, cacao, o quello che volete)?

Una soluzione potrebbe essere quella di rendere i quadri compatibile; in modo che il codice scritto per 1.0 continuerà a funzionare nella versione 2.0 del framework.

Un altro potrebbe essere quello di mirare selettivamente solo la versione 1.0 del framework, ma questo potrebbe lasciare molte nuove caratteristiche di fantasia inutilizzato (molte applicazioni .NET 2.0 sembrano fare questo)

Ogni pensiero su ciò che noi come gli sviluppatori dovrebbero fare come le migliori pratiche per mantenere le nostre tecnologie fino ad oggi, pur non rompendo le nostre applicazioni?

Answer 1

Anticipare e investire nel cambiamento.

Molte aziende sembrano pensare che il cambiamento è una brutta cosa. Complica un processo altrimenti lavorare. Ma, come gli sviluppatori, tendiamo a vedere le cose in modo diverso.

Cambia, in particolare le nuove versioni, può portare a molte cose buone, come gli aggiornamenti di sicurezza, miglioramenti delle prestazioni, e le caratteristiche. E il più delle volte, il cambiamento è inevitabile. Quindi, perché non guardare come una realtà di situazione, invece di una sorpresa?

È possibile fare cose come mantenere i vostri dati di backup in un formato specifico non-vendor nel caso in cui una nuova tecnologia fangled non funziona ed è necessario abbandonare la nave.

Inoltre, se si hanno le risorse, è possibile mantenere le versioni vecchie e nuove di qualcosa in esecuzione contemporaneamente. Idealmente, non si vorrebbe vostri sistemi di produzione per essere in esecuzione la versione più recente del software fino a quando qualcuno ha valutato e firmato fuori su di esso. Cose come test di unità e cloni di sviluppo dei sistemi di produzione di beta / possono aiutare in questo processo.

Cambia dovrebbe essere abbracciata, non temuta. Gli sviluppatori, le parti interessate, e uomini d'affari dovrebbero essere stare al passo con le nuove tecnologie e framework. Essere sempre pronta a cambiamento di indirizzo. In Russia sovietica, API tenere il passo con voi!

Answer 2

Oh, le possibili risposte ....

I miei pensieri, anche se non unico (per essere sicuri) vanno più o meno come questo.

1. Branch tuo codice nel tuo controllo del codice sorgente - si sta utilizzando controllo del codice sorgente, giusto?
2. Sul ramo, aggiornare il quadro (o quello che avete)
3. Fissare i problemi nei test di unità. Approfittate delle nuove API Framework, rimuovere i riferimenti ammortizzati, etc
4. accuratamente test.
5. [opzionale] torna spinta per il tronco (questo e 4 potrebbe probabilmente essere capovolto)
6. di uscita alla produzione - congratulazioni, si è ora sul nuovo quadro
.

Non è davvero così facile ma credo la risposta più semplice è probabilmente la migliore risposta. Devi solo andare avanti ...

Answer 3

Le uniche due "soluzioni" che vedo sono quello che suggeriscono: per mantenere o per l'aggiornamento al nuovo quadro. Penso che in genere, quando la vostra API riceve un importante aggiornamento e il software è importante, è probabilmente meglio per valutare i benefici della riqualificazione e se tali benefici superano il tempo necessario per aggiornare quindi la migliore linea di azione è quello di aggiornare.

Answer 4

Scegliere un conservatore, rischioso, o in-tra approccio appropriato per l'azienda e seguire attraverso.

Per esempio, se la vostra azienda è in procinto di innovazione è necessario essere in grado di utilizzare le ultime versioni di frameworks-- o almeno indagare liberamente. Avrete bisogno di assumere persone che sono interessate e confortevole in un tale environment-- alcuni sviluppatori sono davvero entusiasta di questo, altri non tanto. Mettere in una struttura per fare gli aggiornamenti di sicurezza (filiali e l'architettura statica). I clienti dovrebbero capire i benefici che stanno ottenendo con l'essere con un tale Company-- all'avanguardia se non stai comunicando questo a loro, non può essere qualcosa che il valore, e saranno (giustamente) sconvolto quando le cose si rompono a causa di un aggiornamento del sistema.

o scegliere un approccio conservativo. Scegli una solida, la tecnologia ben indossato e non ha intenzione di aggiornarlo, ad eccezione di minori emissioni. Nelle vostre parole, indirizzare una versione specifica. Assumere persone che apprezzano questo tipo di ambiente.

o scegliere qualcosa di più in mezzo alla strada.

Ognuno di questi approcci sono appropriati a differenti times-- Sono stato su entrambi gli estremi su diversi progetti.