Quando abbandonare la retrocompatibilità a favore di una nuova e migliorata implementazione dell'interfaccia? [chiuso]

Lavoro nella stessa società di software da più di dieci anni. Di conseguenza, ho implementato una base di codice estesa utilizzando vari linguaggi di programmazione orientati agli oggetti. Ero un programmatore principiante quando ho iniziato la mia carriera e non sapevo molto dei buoni principi di interfaccia e design di classe. Vorrei pensare che le mie capacità di progettazione sono migliorate nel tempo, ma ora incontro sempre più difficoltà nel migliorare il mio codice precedente a causa di problemi di compatibilità con le versioni precedenti. Il mio codice viene utilizzato da un gran numero di clienti come parte dei prodotti venduti dalla mia azienda.

La mia domanda è: quando dovremmo smettere di cercare di mantenere la retrocompatibilità delle vecchie interfacce e mordere il proiettile a favore dell'implementazione di un nuovo design?

Penso che arrivi un punto in cui il mantenimento della compatibilità con le versioni precedenti diventa un peso così grande che diventano impossibili modifiche utili alle interfacce. Qualcuno ha riscontrato preoccupazioni simili, chi può fornire un feedback?

Mentre "quando" è una buona domanda, penso che "come" sia ancora più rilevante. Può essere difficile effettuare una transizione di rottura in un modo che non rende gli utenti frustrati o infelici. Alcuni elementi da considerare:

• Comunica con i tuoi clienti / clienti molto prima di ogni transizione. Spiega perché e come verrà implementato. Citando sicurezza, prestazioni, stabilità e flessibilità futura come ragioni sono tutte valide.
• Se stai comunque facendo una pausa netta, richiedi un feedback.
• Se ci sono sviluppatori di terze parti, assicurati di includere anche il loro contributo in quanto ha senso.
• Se è possibile, fornire un livello di compatibilità.
• Fornire una guida completa all'aggiornamento.
• Rendi l'aggiornamento il più semplice e indolore possibile. Riduci al minimo il dolore dei tuoi utenti, anche se significa un po 'più di lavoro per te.
• Se addebiti, offri uno sconto per gli aggiornamenti alla nuova versione.
• Aggiungi almeno alcune nuove e utili funzionalità in una nuova versione per incentivare l'aggiornamento. Ciò è particolarmente importante per rendere l'aggiornamento più attraente per i manager.
• Se fai una pausa, fallo l'ultima volta che ne hai bisogno. Ciò significa una pianificazione completa in anticipo e assicurarsi che tutto sia impostato correttamente.
• Se hai un'interfaccia utente, vai piano con le modifiche ad esso. Pensa ad aggiornare piuttosto che a riprogettare. Per gli utenti non tecnici, drastiche modifiche dell'interfaccia utente da una versione all'altra possono essere una grande causa di frustrazione.
• La tua nuova versione dovrebbe essere notevolmente più stabile e performante rispetto alla vecchia. Non dare ai tuoi utenti un motivo per inviare nuovamente l'aggiornamento. Non rilasciare una nuova versione senza test approfonditi (unità, integrazione e beta test).
• Mantenere la vecchia versione contemporaneamente per un lungo periodo di tempo. Se decidi di eliminarlo gradualmente e di interrompere il supporto, dai almeno 6-12 mesi di preavviso, se possibile di più.
• Puoi permetterti di mantenere due versioni contemporaneamente sia in termini finanziari che di manodopera? (Inoltre, dal punto di vista aziendale, non dovresti interrompere il supporto della vecchia versione fino a quando non puoi permetterti di perdere i client rimanenti che si aggrappano alla vecchia versione e non vogliono aggiornare. Quel punto dovrebbe essere quando i tuoi costi di mantenerlo supera i tuoi profitti.)
• Impegnarsi a eseguire aggiornamenti di sicurezza per un periodo di tempo dopo l'interruzione della versione precedente, se necessario.
• Ancora una volta, la comunicazione è enorme per tutto il processo. Non lasciare che i tuoi utenti / clienti / clienti si sentano abbandonati in nessun momento. La loro lealtà e passione è il fondamento della tua attività. Assicurati di rispondere alle loro domande sul tuo blog o nei tuoi forum. Il fattore sociale non dovrebbe essere sottovalutato.

Per quanto riguarda il "quando", probabilmente avrai un'idea migliore per la tua applicazione rispetto a chiunque altro. In generale, tuttavia, potrebbe essere il momento di una netta pausa quando il debito tecnico e l'architettura inibiscono completamente la stabilità, impediscono prestazioni ragionevoli e rendono schiacciante o inutilmente lo sviluppo di nuove funzionalità.

Detto questo, non fare questo passo alla leggera. Anche fatto bene, rompere la compatibilità con le versioni precedenti è un grosso problema. Dovresti prendere in considerazione l'idea di aumentare la copertura del test e il refactoring prima e, se possibile, prima di prendere in considerazione una pausa.

In generale, sono d'accordo con James Anderson. Nella mia esperienza, tuttavia, vi sono altri aspetti che possono giustificare la considerazione e che possono indicare un'opzione che consente effettivamente interfacce in evoluzione.

Questo esempio è di una delle squadre con cui sto lavorando. Spediscono un prodotto su base regolare, almeno una volta al mese a volte anche settimanalmente. I clienti sono incoraggiati a eseguire l'upgrade poiché le nuove funzionalità e le nuove piattaforme sono supportate solo nelle versioni più recenti. L'aggiornamento è semplice e i clienti possono anche saltare le versioni in mezzo. Il downgrade non è supportato. Inoltre, le versioni sono supportate solo per 3 anni. Dopo di che c'è un periodo di grazia di un anno in cui le spese di manutenzione raddoppiano.

Di conseguenza, la stragrande maggioranza - circa il 95% dei clienti - si aggiorna regolarmente, almeno una volta all'anno. Ciò significa anche che è possibile introdurre gradualmente nuove interfacce.

Che ne dici di vecchie interfacce? La tecnica utilizzata da questo team sta dichiarando le vecchie interfacce come "fine vita". Quindi c'è un periodo di 12 mesi in cui la nuova interfaccia è disponibile e la vecchia interfaccia non è ancora stata ritirata. Le nuove interfacce offrono funzionalità migliori rispetto alla vecchia interfaccia, quindi ci sono due incentivi: la vecchia interfaccia di fine vita e la nuova interfaccia sono molto migliori.

La vecchia interfaccia concreta in questo caso era una tecnologia specifica della piattaforma che sta per essere gradualmente sostituita da un'interfaccia di servizio basata sulla tecnologia standard tradizionale.

Naturalmente questo cambiamento non avviene durante la notte e ci vogliono molti anni per completarlo. Ma ha permesso di bloccare gli investimenti nella vecchia tecnologia e invece di investire nella nuova tecnologia. Ai clienti viene fornita assistenza e hanno una strada da percorrere. Molti di loro accolgono con favore anche il passaggio a nuove tecnologie.

Tieni presente, tuttavia, che questo particolare approccio potrebbe non funzionare nel tuo scenario. Certamente funziona per la squadra con cui sto lavorando.

Hai già delle buone risposte qui, quindi vorrei solo aggiungere un puntatore a un bellissimo articolo di Joel Spolsky su questo argomento. Sta discutendo i piani per rinunciare alla retrocompatibilità in IE 8, che è essenzialmente lo stesso del tuo problema:

http://www.joelonsoftware.com/items/2008/03/17.html

La risposta breve è mai!

L'esperienza dimostra che il fatto di abbandonare la retrocompatibilità perlomeno infastidisce i clienti e gli utenti e, nel peggiore dei casi, li perde completamente.

Se stai chiedendo ai tuoi utenti di riscrivere il codice, dopo aver terminato la consueta maledizione di te e di tutti i tuoi discendenti, penseranno "Se dovessi riscrivere comunque, forse dovrei semplicemente passare a quella bella libreria ACME che ho letto così tanto? ".

Il trucco è migliorare l'interfaccia attuale in modo tale da non interrompere la retrocompatibilità, oppure offrire un'interfaccia completamente nuova, brillante e ovviamente superiore, mantenendo al contempo l'interfaccia precedente. Ad un certo punto ci saranno funzionalità nella nuova interfaccia che non saranno possibili nell'interfaccia precedente, ma questo dà alle persone solo un incentivo a muoversi, senza forzare il problema.

Modifica per chiarire ulteriormente questo.

Quello che pensi come programmatore è -

"Migliorerò questa API e renderò il sistema il migliore possibile e tutti mi ammireranno".

Quello che penseranno gli utenti della tua API è:

"A * * * e pensa che il mio tempo e il mio programma non siano importanti. Devo interrompere ciò che sto facendo e refactificare tutto il mio codice per nessun altro motivo se non quello di soddisfare il suo ego. Se devo fare il refactoring allora cambierò a un'altra API solo per attaccarlo anche lui. "

Questa è davvero una decisione aziendale più che tecnica. Di solito, questo viene fatto come parte di una versione principale (ad esempio dalla versione 3.5 alla versione 4.0) e spesso le due versioni sono supportate in parallelo per un po '. Ciò significa che eseguirai la manutenzione sulla vecchia versione, ma tutte le nuove funzionalità appariranno solo nella nuova versione. La vecchia versione è supportata fintanto che l'azienda ne guadagna, o almeno abbastanza per compensare i costi di manutenzione. Preparati a presentare questo al management.

Sono stato dalla parte dei clienti di questo, quindi direi che dipende davvero da cosa pensi di fare per la transizione.

Attualmente stiamo aggiornando il nostro sistema di account. L'azienda che esegue l'aggiornamento supporta anche la precedente versione incompatibile. Hanno in programma di prendere i dati e spostarli nel nuovo sistema in modo che (in teoria) tutti i vecchi dati saranno lì. Pagheremo un paio di centinaia di sterline per la conversione dei dati. Nessun problema.

Confronta con una situazione precedente in un'altra azienda per cui ho lavorato. Il fornitore non aveva modo di passare dal vecchio al nuovo sistema. Questo li ha messi nella stessa situazione di tutti gli altri fornitori. In effetti la loro situazione era peggiore perché sapevamo che non erano impegnati ad aiutarci con gli aggiornamenti. Non hanno ottenuto il nuovo contratto.

Hai fatto il duro lavoro per ottenere e mantenere i clienti, come puoi facilitare la transizione?