Quando eseguire l'aggiornamento a una nuova versione di una lingua o di un framework?

Question

Quando appare una nuova versione di un framework o linguaggio (ad es. .NET 3.5, SQL2008), quale approccio adottano le persone quando adottano / aggiornano?

Generalmente gli sviluppatori lo diranno al più presto (lo vogliono sul proprio CV e dal punto di vista della gestione dando loro ciò che vogliono fornisce una spinta alla motivazione) ma commercialmente c'è spesso un piccolo incentivo (pochi clienti richiedono l'ultima versione) e da Dal punto di vista dei costi (ripetere il test, formazione) c'è spesso un disincentivo.

Sto pensando in particolare a "in corso". sistemi e progetti (come in una software house) che esistono e si evolvono nel corso degli anni in cui i "nuovi progetti utilizzano la nuova tecnologia" l'approccio non funziona.

Le persone sono guidate da requisiti specifici (la necessità di utilizzare una nuova funzionalità, un cliente potenziale o esistente che richiede supporto per essa), la valutano formalmente (nel qual caso quali sono i criteri) o eseguono l'aggiornamento in funzione di routine (nel qual caso quando - bordo anteriore vs. bordo sanguinante)? ??

Le persone pensano che non essere nell'ultima versione di qualcosa debba essere considerato debito tecnico e gestito come tale?

O è " se non è rotto, non aggiustarlo " un approccio valido?

Answer 1

Leggi su Debito tecnico . Questa è una semplice decisione costi-benefici.

Il " se non è rotto non aggiustarlo " è una politica di gestione comune che dice "i dollari di domani non valgono quanto quelli di oggi, quindi non pianificare miglioramenti futuri." Alla fine il debito tecnico si accumula al punto in cui il prodotto non può più zoppicare.

Il punto di rottura più comune è quando parte dell'infrastruttura non è più supportata. A quel punto, il cambiamento incrementale è impossibile.

Reinventare da zero è un nuovo investimento di capitale. La correzione del codice esistente è una spesa. I conti obbligano il management a prendere decisioni tecnicamente pazze.

Nel caso di software open source, richiede un'attenta gestione tecnica poiché non esiste un supporto ufficiale "supporto tramonto" annuncio da Oracle / Sun. Una cattiva gestione tecnica, ovviamente, porta al fallimento tecnico.

Answer 2

Esaminiamo i costi del ciclo di vita dell'assistenza . Per quanto tempo sono supportate le versioni precedenti ea quali costi? Piattaforme come Windows e Java tendono a muoversi rapidamente rispetto agli ambienti mainframe e parte del costo di fare affari su tali piattaforme è eseguire aggiornamenti periodici. In un mondo razionale, cioè!

Le nuove versioni possono avere le caratteristiche killer di cui abbiamo bisogno, ma questo è raro nello sviluppo aziendale. I principali punti di forza positivi delle nuove versioni (rispetto a quelli negativi come il supporto scaduto) tendono ad essere maggiore efficienza degli sviluppatori , che è difficile da misurare. Al contrario, come indicato, il costo della riqualificazione deve essere considerato, non solo per gli sviluppatori iniziali, ma, soprattutto, per la manutenzione. In ogni aggiornamento, alcune applicazioni tendono ad essere lasciate indietro perché troppo critiche per andare in pensione e troppo costose / fragili per l'aggiornamento. Nel tempo, il numero di piattaforme e versioni che devi supportare aumenta il debito tecnico complessivo (indipendentemente dalla loro età).

Un altro criterio per l'aggiornamento a nuove versioni (che noti) è la capacità di attrarre e trattenere il personale . Con l'attuale fase economica, si sta giocando il secondo violino, ma non è ancora possibile ignorarlo completamente. Vuoi avere almeno un condimento di sviluppatori entusiasti e competenti.

Answer 3

Penso che la domanda killer sia se la tua app sopravviverà a lungo se non aggiorni MAI la versione piattaforma / lingua. Se pensi che non sia possibile, puoi anche aggiornare prima piuttosto che dopo, poiché diventerà solo più difficile.

Pensa a quanto tempo la tua app deve essere sviluppata attivamente fino a quando non hai bisogno di una riscrittura completa. Se non prevedi mai di riscriverlo, aggiornerei continuamente. Considera quanto sarà difficile trovare i migliori sviluppatori se stai lavorando con una tecnologia obsoleta. Considera come le nuove funzionalità del framework / linguaggio potrebbero accelerare il tuo processo di sviluppo a lungo termine, per un po 'di dolore a breve termine.

Answer 4

Quando ne hai davvero bisogno. .NET 1.0 era scadente, 1.1 era un buon aggiornamento, ma lo sviluppo Web con VS2003 non era così fluido. Le cose sono migliorate con VS2005 e .NET 2.0 - e vedo ancora molti sviluppatori e aziende aderire a .NET 2.0. Le versioni precedenti erano così fresche, la versione 2.0 era tecnologia avanzata. Quindi, se tu fossi soddisfatto di 1.1, perché dovresti aggiornare? Se sei soddisfatto ora con 2.0, perché aggiornare a 3.5 o 4.0?

Answer 5

Quando i vantaggi dell'aggiornamento (sono necessarie più funzionalità o una correzione di bug) superano i rischi / i costi (nuovi problemi, violazione del codice esistente).

Answer 6

Quando sviluppi per piattaforme basate su Microsoft, come un'app di Windows Forms per Windows o ASP.NET per Windows Server, il momento giusto per migrare è per ogni due versioni principali del sistema operativo. Ad esempio, se l'app è stata sviluppata per Windows 2000, è necessario migrare a Vista sebbene XP possa essere trascurato. Allo stesso modo, se fosse progettato per XP SP2, puoi tranquillamente ignorare Vista e scegliere Win 7. Di solito Microsoft non interrompe (o raramente interrompe) gli aggiornamenti incrementali del sistema operativo. Quindi un'app in esecuzione sul sistema operativo odierno verrà sicuramente eseguita sul successivo. Ma mai su quello che lo segue. (Se funziona come può M $ fare soldi ???)

Fonte: Self ... Sviluppatore Windows per oltre 5 anni)

Answer 7

Sono nel campo di aggiornamento il più presto possibile (anche se potrei aspettare un mese dopo l'uscita di una nuova versione per eventuali problemi non rilevati). Ci sono alcune cose a cui devi pensare:

1. Comunicati di sicurezza

Molte delle persone che mi dicono che se non è rotto non lo riparano sono anche le stesse persone che chiudono i loro occhi quando vengono rilasciate le patch di sicurezza. Pensa a Equifax.

Per me è una responsabilità etica essere almeno sulle versioni di un framework supportate dalla sicurezza. Lo dobbiamo ai nostri clienti per salvaguardare i loro dati.

2. Attrarre & amp; Conservare i talenti

Si discute molto su come il linguaggio di programmazione o il framework utilizzati non contano. Ma nella mia esperienza, il codice e il design più puliti per un'app Web sono generalmente scritti da persone appassionate del framework & amp; linguaggio di programmazione utilizzato a causa della loro esperienza e amp; competenza con esso.

È improbabile che queste persone rimangano a lungo o si uniscano alla tua azienda se ti attieni a una versione molto vecchia. Pensa alla felicità dei tuoi sviluppatori.

3. Modi più recenti e più semplici offerti dalla versione più recente

Molto spesso le versioni più recenti di un framework rendono molto più semplice qualcosa di difficile in passato. Se non eseguiamo l'aggiornamento, perdiamo i nuovi buoni pacchetti / funzionalità e scriviamo il nostro codice nel vecchio modo frustrante sapendo che esiste un modo molto più semplice per ottenere la stessa funzionalità. E quando arriva il momento di aggiornare, potremmo finire per dover cambiare di nuovo nel nuovo modo. Quindi perché non aggiornare e utilizzare il nuovo modo migliore e perdere meno tempo?