Software Rewrite-vs-Running Cost Analaysis

Question

Il reparto IT in cui lavoro come programmatore ruota attorno a una base di codice di oltre 30 anni (Fortran e C). Il codice è in pessime condizioni, in parte a causa di oltre 30 anni di modifiche mal progettate ad hoc, ma ho anche il sospetto che gran parte abbia a che fare con le capacità dei programmatori che hanno apportato le modifiche (e che, per inciso, sono ancora in giro).

L'attività che dipende dal software funziona 363 giorni all'anno e 20 ore al giorno. Purtroppo ci sono numerose interruzioni. Questo è il primo posto in cui ho lavorato dove ci sono sviluppatori in chiamata per applicare correzioni del codice operativo ai sistemi di produzione. Quando ero il primo, c'era in realtà una copia del codice sorgente e degli strumenti di sviluppo sui server di produzione in modo che al volo si potessero applicare le modifiche; per fortuna che la pratica è stata ora interrotta.

Ho suggerito un paio di volte alla direzione che i costi dei tempi di inattività, gli sviluppatori in servizio, il personale operativo extra, i clienti insoddisfatti, ecc., Stanno costando molto più al business, e forse anche a breve termine, di quanto vorrebbe lanciare uno sforzo totale per riscrivere/rifattorizzare/sostituire l'intera cosa (la base di codice è di circa 300k linee).

Idealmente si tratterebbe di una società di consulenza esterna che potrebbe entrare ed eseguire la regola sulla qualità del codice e sui costi necessari per mantenerla in esecuzione contro riscrittura/refactoring/sostituzione. La domanda che ho è come dovrebbe andare un'azienda a fare quel tipo di analisi dei costi sul software E essere in grado di avere fiducia in tale analisi? I primi consulenti IT in fondo alla strada potrebbero affermare di essere in grado di fare l'analisi, ma come si potrebbe fare in modo che la direzione si senta a proprio agio con ciò che viene detto dallo staff interno?

Answer 1

In primo luogo, il profilo del consulente necessario è molto specifico. A meno che tu non possa trovare qualcuno che ha lavorato in un dominio simile con le stesse lingue, non assumerlo.

In secondo luogo, c'è una probabilità del 99% (mi piace numeri drammatici) l'analisi andrà come segue:

• Consulente esplora l'applicazione
• consulente non comprendere il 10% della domanda di
• Tempo scaduto , il tempo per il rapporto
• Consultant Consigli una completa riscrittura (senza refactoring, riscrittura pianura)

Quindi potresti anche fare economia di ciò che il consulente avrà un costo.

avete solo due soluzioni qui:

• conserva, insieme alla codice sorgente, ma determinano metodi adeguati per risolvere i problemi in modo da avere un tempo molto lungo refactoring periodo che è progressly fatta da coloro che conoscono l'applicazione
• Ottieni una squadra secondaria per fare una nuova applicazione per sostituire il vecchio

Se parlo di una squadra secondaria, è perché non si può portare un solo architetto per rendere la nuova applicazione e avere il vecchio team di lavoro con Ciao m:

• Sono troppo occupati sulla vecchia applicazione
• Ci saranno attriti, perché il nuovo arrivato sarà senza dubbio sottovalutare il compito a portata di mano

parlo per esperienza, credimi.

Se usi la "nuova applicazione", non mettere le tue speranze troppo in alto. Finirai con un'applicazione che ha meno della metà delle funzionalità di quella corrente, semplicemente perché non puoi stipare più di 30 anni di casi speciali e correzioni di situazioni eccezionali in un nuovo software di progettazione.

Oh, inoltre, se i tuoi sviluppatori ti capita di dirti che hanno un piano, a tutti i costi, ascoltali. Molto probabilmente sanno di cosa stanno parlando.

Answer 2

Recentemente abbiamo deciso di riscrivere completamente grandi parti del nostro codice aziendale da zero, e non è andata bene come avevamo sperato. Ho visto molte citazioni che dicono che non dovresti mai provare a riscrivere tutto da zero, e ora capisco perché. Consiglierei di iniziare in piccolo - non provare a riscrivere il tutto in una volta. Identificare le grandi aree problematiche e concentrarsi sul refactoring di piccole porzioni del sistema alla volta. Poiché il sistema richiede oltre 30 anni di lavoro, ci vorrà molto tempo per riportarlo a uno stato ragionevole. Avevamo circa 5-8 anni di lavoro da riscrivere, ed è stato difficile. Non posso immaginare più di 30 anni di lavoro!

Answer 3

Penso che la descrizione fornisca tutte le informazioni necessarie sulla qualità del codice (mancanza di esso). Il fatto che siano richieste così tante risorse di supporto indica anche i costi elevati legati alla manutenzione del sistema esistente.

Come ho risposto here, un buon approccio da considerare è il refactoring di un pezzo del sistema alla volta finché tutto funziona a un livello accettabile. Sono d'accordo con Joel e non sto buttando via il codice esistente (vedi Things You Should Never Do.Le parti del tuo codice funzionano, quindi dovresti lasciarle a posto quando possibile e concentrarti sulle sezioni che portano ai tempi di inattività

Anche Andy fa un grande punto

Un'altra cosa da provare è la revisione dei processi attorno al sistema. Quando si esegue questa operazione, si dovrebbe provare a determinare quali situazioni di errore sono causate direttamente o indirettamente dall'azione dell'utente ?, ci sono configurazione o problemi di ambiente? Se si riscontrano problemi nel correggere il codice direttamente, è ancora possibile sostenerlo affrontando i problemi esterni in modo più efficace.

Answer 4

La prima cosa che viene in mente è che stai affrontando prematuramente l'argomento riscrittura/refactoring/replace.Il primo passo due passi mi sento di raccomandare sarebbe:

1. unit test
2. QA

E 'così nel campo di applicazione di ingegneria per implementare questi. I test unitari sono una fase preliminare essenziale prima che qualsiasi ragionevole refactoring o riscrittura possa eventualmente aver luogo. Con 'unit test' intendo per avvolgere ogni chiamata di funzione con il codice corrispondente che dimostra che il codice funziona per tutte le condizioni note. Nei retrofit complessi questo potrebbe non accadere realmente al livello più granulare, ma qualsiasi test automatizzato aiuterà immensamente.

E QA: disporre di un team indipendente (e aggressivo) addetto all'assicurazione della qualità che esegue rigorosamente il test delle versioni beta prima della produzione. I loro piani di test e le procedure di test diventano essenziali per qualsiasi tipo di sostituzione.

Una volta che hai il codice sotto controllo, allora sei in una posizione in cui l'azienda può ragionevolmente prendere in considerazione cambiamenti enormi.

Solo una nota sul tuo commento sui consulenti esterni: nessuna consulenza sarà mai sufficientemente interessata al codice per fornire una garanzia di qualità realistica. Il QA finisce per essere sposato con l'anca del business per difendere la linea di fondo dell'azienda. È una funzione interna alla fine e un consulente esterno non può fornire molto di più che iniziare veramente.

Answer 5

Il codice è in uso da 30 anni?

I paradigmi di sviluppo sono cambiati sostanzialmente negli ultimi tre decenni in molti modi, e il più rilevante per la tua situazione, ritengo, è in termini di quantità di tempo (in uomo) necessaria per creare qualcosa da inserire -> processo -> emette qualcosa.

300.000 righe di codice 30 anni fa, potrebbe probabilmente rientrano in 100.000 linee o meno oggi, e spendendo meno ore uomo (?) Questo potrebbe sembrare ottimistico/ridicolo per alcuni, ma d'altra parte è realizzabile, a seconda sul tipo di applicazione in questione. Non hai dato alcuna indicazione sulla classificazione del sistema - si tratta di un sistema di controllo del processo di fabbricazione in tempo reale di tipi con sensori e attuatori collegati ad esso? Un sistema di prenotazione aerea? Post-processa alcuni arretrati di dati? In altre parole, potrebbe essere ricostruito in qualcosa come Java e rapidamente con una squadra aggressiva e un po 'piccola? I requisiti sono stati documentati e, in tal caso, devono essere aggiornati o riprogettati da zero? La sicurezza umana è un fattore?

Basta un controllo di integrità veloce, penso che anche se non si dovrebbe ricostruire dipende (qualsiasi ordine significa la stessa cosa):

1. Numero di tizi codice richiesto.
2. Livello di competenza di detti tizi.
3. Quali lingue non si adattano.
4. Quali lingue sono adatte.
5. Quanto costa utilizzare la lingua scelta (s) in termini di hardware e software.
6. Quanto dipende l'azienda da questo per rimanere in vita.
7. È davvero troppo tempo morto, o stai solo facendo il pelo nell'uovo? (forse a loro non importa, ma fingi di farlo).

Buona fortuna!

Answer 6

1. letto il libro Working Effectively with Legacy Code (vedere anche la short PDF version) e circondano il codice con test automatizzati, come indicato in quel libro.

2. Refactoring del sistema a poco a poco. Se riscrivi alcune parti del codice, fallo un piccolo sottosistema alla volta. Non provare a creare un Grand Redesign.