Come giustificare la riscrittura / revamping di software legacy in un business case? [duplicare]

Il tuo software è manutenibile. Ecco perché ci stai lavorando. In effetti, le entrate che ottengono vendendo e supportando quel software probabilmente supportano il tuo stipendio caricato. Se gestissi qualcosa che funziona, lo lascerei in pace. Se tu avessi una casa con un'architettura idraulica contorta, pagherebbe un idraulico per ripulire l'architettura anche se adesso funziona perfettamente bene? Probabilmente no.

Come sviluppatore di software, capisco perché si desidera una buona architettura, orientamento agli oggetti, eccetera, in modo da non dover vendere me o qualsiasi sviluppatore di software.

Scommetto che il prodotto software è in modalità "latte-mucca". Stanno solo cercando di trarne il massimo profitto possibile dai clienti esistenti prima che muoia. Se ciò non è vero, quali sono gli scenari architettonici che scendono dal tubo? Più degli stessi dati? Nuovi dati? Disapprovazione della piattaforma o dello strumento? Algoritmi ad alte prestazioni? Espansione della base clienti? Nuove caratteristiche? Nuove piattaforme? Mobile? Se non ci sono nuove condizioni commerciali che ti spingono a cambiare l'architettura, l'architettura non cambierà? Se la tua architettura è nel punto critico in cui la prossima modifica causerà una correzione incredibilmente costosa, dovrai aspettare che ciò avvenga prima che siano disposti a pagare per una modifica.

L'aspetto positivo di questo concerto è che probabilmente non possono licenziarti, perché le abilità di Delphi sono relativamente difficili da trovare. E c'è sicurezza sul lavoro quando si sostiene un prodotto redditizio.

Leggi Joel on Software - Cose che non dovresti mai fare, parte I , o spero che i tuoi manager non lo facciano . Il mio ovviamente non l'aveva letto, scommetto che ora, se lo sono, vorranno averlo prima .....

Lavoro su un progetto riscritto in Java da oltre un milione di righe di codebase legacy ADA. Ora abbiamo meno di un milione di linee di un nuovo programma Ada legacy "Java syntax", con una serie di difetti che prima non esistevano e una serie di nuove funzionalità che funzionano il più delle volte. Fortunatamente abbiamo anche un framework di test delle unità, quindi quando un difetto viene scoperto possiamo scrivere ancora un altro test unitario che fallisce, correggere il difetto, guardare quell'unità passare e una dozzina di altri fallire ......

Essenzialmente solo un pazzo estraeva un codice funzionante per le promesse vuote di un nuovo codice base.

Una delle mie esperienze è andata bene

Il sistema era morto e incapace di reagire ai cambiamenti del mercato, era rivolto ai clienti, aveva un aspetto datato e funzionato in modo obsoleto e aveva così tanti bug report, che il tempo stimato per risolverli era più che riscrivere l'intera faccenda. Alcune lezioni

• La stima del tempo era sbagliata MA
• Il nuovo sistema ha nuove funzionalità / migliori
• È stato davvero facile aggiungere funzionalità
• Quando viene rilevato un bug, è stato risolto per lo più entro un'ora
• L'esperienza utente è stata notevolmente migliorata, perché i progettisti hanno avuto la possibilità di aggiornare il design.

Non è una buona esperienza

Il sistema era molto buggato e aveva un orribile modello di dati e un livello di accesso ai dati. In realtà era la tecnologia usata che lo paralizzava. Ci sono state discussioni sull'uso dell'attuale modello di dati, ma sono stati abbandonati. Il nuovo design era necessario per rendere possibili nuove funzionalità.

• I problemi del primo sistema sono stati superati. Le ragioni per cui le cose erano un disastro sono perché i poteri che erano non erano sicuri di quello che volevano.
• I ritardi massicci derivanti dal costante cambiamento della mente hanno ucciso il progetto.
• Il software stesso funzionava abbastanza bene, ma la sensazione generale di tutti non era buona.

Un successo di refactoring

Ho ricevuto alcuni sistemi che alcuni avrebbero giustificato la riscrittura (alcune persone sono molto impazienti e talvolta vogliono semplicemente farlo perché il codice sembra diverso).

Il particolare sistema era un casino. Gli strati erano tutti mescolati con nessun livello di accesso ai dati distinguibile, i controlli sugli schermi erano denominati Button1, Button2 ... Le variabili venivano riutilizzate, i pezzi di codice venivano copiati all'ingrosso su classi diverse.

L'uso di strumenti di refactoring ha aiutato molto, ma in sostanza sono stati necessari circa 2 mesi di lavoro dedicato, intercalati da correzioni di bug e richieste di miglioramento. Essenzialmente il progetto potrebbe continuare a funzionare nonostante la massiccia revisione interna. Se inizi in piccolo e aggiusti presto le piccole cose, ti rendi conto che puoi stare tranquillo lavorando con qualcosa.

Lezioni che ho imparato

Cerca sempre di pensare a ogni singolo motivo per non riscrivere . Pensa il più strong possibile come puoi salvare un sistema morente. Saresti sorpreso di quanto meno lavori sia di quanto pensi. I Riscrivi sono un enorme gioco d'azzardo e in buona compagnia funzionerà bene. La gestione di solito cerca di giustificare una riscrittura aggiungendo funzionalità alla nuova versione. Questo potrebbe aprire un incubo di creep di portata costante, cosa-se-avessimo-stupido-caratteristica-x, paralisi dell'analisi e tutte le altre cose brutte che vengono con un nuovo progetto.

Se la tua azienda è brava in nuovi progetti e non c'è modo di salvarla, quindi segnala cosa c'è di male nel sistema. Mostralo ai tuoi manager, ottieni una terza opinione da un altro sviluppatore e prendila da lì.

Come sempre quando si tratta di persone con mentalità aziendale, presenta il tuo caso come analisi di profitti / perdite. La tua analisi dovrebbe rispondere a queste tre domande:

• Quali ulteriori entrate possono essere generate dalla ricostruzione proposta? (ad esempio, il supporto a 64 bit potrebbe essere tradotto in piattaforme più mirate)
• Quale perdita di entrate si limita a ricostruire? (ad esempio, dedicare meno tempo e risorse alla manutenzione e aggiungere nuove funzionalità)
• Il costo della ricostruzione tuo è giustificato da una modifica sufficiente nei due elementi precedenti?

Questo grafico potrebbe aiutare, è una funzione della qualità del codice base e del valore commerciale dell'applicazione:

Il grafico finge di essere una guida su quando una reingegnerizzazione del software legacy è giustificata e quando non lo è. Ad esempio, se il software ha un alto valore commerciale e la qualità del codice è scarsa, allora una riprogettazione è giustificata.

Come si fa a fare affari per spendere un sacco di soldi scrivendo un pezzo di software che fa esattamente la stessa cosa del software che hai ora, oltre al rischio aggiuntivo che non faccia esattamente la stessa cosa?

Buona fortuna.

Does anyone know of any blog posts or the like where this is talked about?

Sì, ecco due articoli da esaminare e inoltrare alla tua gestione:

1. Un pasticcio non è un debito tecnico
2. Quadrante del debito tecnico

E qui ci sono due punti sui software legacy da tenere a mente:

Il software legacy che è difficile da modificare sarà:

1. Limita le opzioni di una società per il futuro (supponendo che l'azienda non stia cercando solo di mungere la mucca da mungere).
2. Frustrare gli sviluppatori attuali e incidere sulla capacità di un'azienda di attrarre e trattenere nuovi talenti.

Non c'è ragione per cui non puoi affrontare i problemi che esistono nel tuo attuale progetto. Non è necessario buttare il bambino con l'acqua del bagno. Ci sono molti modi in cui puoi affrontare i problemi che esistono. Se si dispone di un elevato livello di difetti, le prove unitarie e di convalida e verifica sono una di quelle soluzioni.

The software lacks any meaningful architecture - there's no object orientation whatsoever, horrible amounts of cyclical dependencies and an over-reliance on global variables to name just a few things. Another huge thing for me is Delphi 7 does NOT support 64-bit.

Delphi supporta quasi tutti i moderni concetti di programmazione supportati da Java e C #. Ciò significa che potresti facilmente risolvere le tue dipendenze cicliche e il problema delle variabili globali. Potresti anche risolvere il tuo orientamento all'oggetto se lo desideri. Tutto ciò che devi fare è risolvere un singolo problema alla volta.

The problem here for me is that my management team don't care about technical things, they want to know why they should care. Obviously that's expected, so what I'm asking here is for some guidance, or tales, or pitfalls about this kind of thing.

Come dipendenti ritengono che il software sia irrinunciabile. È necessario presentare una motivazione per i motivi, è necessario trovare una soluzione ai motivi per cui il progetto non è realizzabile. Se non puoi farlo, è molto probabile che il progetto SIA REALMENTE MANTENIBILE perché è stato mantenuto per oltre 20 anni.