Per riscrivere o riformulare lentamente il vecchio progetto C ++ [duplicato]

Se riscrivi & riprogettazione da zero, avrai due problemi MASSIVE:

1. Non hai una specifica. Potresti pensare di avere una specifica, ma si scopre che la specifica REALE è il vecchio codice. Quindi dovrai scavare per capire cosa fa veramente, solo così sai come fare il nuovo sistema.
2. Avrai un lungo periodo (osservando la gerarchia delle classi, possibilmente anni) in cui non avrai un prodotto vendibile. Il che significa che devi mantenere il vecchio in parallelo, o rinunciare a spedire qualsiasi cosa per molto tempo.

Puzza, ma probabilmente devi solo provare a migliorare quello vecchio. Scrivi test per tutto ciò che tocchi, non esitare a strappare una grande sezione per renderlo migliore, ma non provare a riscriverlo tutto in una volta. Il progetto potrebbe non sopravvivere a un simile tentativo.

Riscrivere un progetto di queste dimensioni è destinato a fallire a causa dei motivi del post di Michael Kohne.

Il refactoring di una base di codice bug è difficile perché non saprai mai se i bug sono dovuti al tuo refactoring oa causa del codice originale.

Prenderò l'approccio di non fare altro che correggere i bug per un periodo di tempo significativo. Come parte di queste correzioni di bug, è possibile riscrivere piccole sezioni che sono palesemente errate. I vantaggi di questo sono:

1. Offre agli sviluppatori l'opportunità di imparare molto sul codice, l'architettura e il comportamento del prodotto. Avrai bisogno di questa conoscenza per fare qualsiasi refactoring significativo.
2. Stabilizza il codebase prima di qualsiasi importante lavoro di ristrutturazione.
3. Puoi vendere il prodotto stabilizzato mentre le modifiche principali vengono apportate in seguito.

Sembra anche che tu abbia disperatamente bisogno di un sistema di tracciamento dei bug e una sorta di QA per trovare bug e amp; verifica le correzioni.

Quando ho implementato il re-factoring su progetti di grandi dimensioni, in genere ho usato la strategia di fare l'architettura di nuovo, e di provare prima l'architettura, mentre lo sviluppo continua sul progetto originale. Quando la nuova architettura è stata provata, c'è una grande quantità di trasferimento della logica esistente nella nuova architettura. Questo sembra essere fatto meglio in fretta, piuttosto che come attività in background.

Vale la pena farlo? È difficile giudicare senza essere presenti al progetto, ma pensa a questi problemi:

1. Il code base esistente è stabile e privo di errori? Se devi dedicare molto tempo a trovare e applicare patch al codice esistente senza comprenderlo veramente, il tempo risparmiato da una riduzione del supporto mediante il reimplementing utilizzando il codice capito può essere significativo.

2. Hai almeno la stessa conoscenza del prodotto dei codificatori originali? Quanta parte della complessità è dovuta a correzioni di bug per situazioni inaspettate, e quanto è stata scarsa la progettazione?

3. Hai il tempo di finire l'attività? Una delle cose che apprezzo di più di un codice base è la coerenza. Il codice incoerente è un incubo per supportare, estendere e presentare nuovi membri del team.

4. Se non hai una conoscenza approfondita delle regole di business dei prodotti, è probabile che tu faccia un lavoro peggiore rispetto alla versione corrente.

Conclusioni - basate sugli aggiornamenti delle domande, è che non hai una conoscenza sufficiente del progetto per eseguire una re-implementazione. Nella tua situazione attuale, anche un fattore di ri-fattore significativo è rischioso. La buona notizia, almeno, è che gli attuali clienti non sono colpiti da bug che impediscono loro di usare il prodotto, il che significa che hai tempo per capire il codice base. Questo deve essere il tuo primo obiettivo.

Essendo anch'io uno sviluppatore Delphi (e il VCL è scritto su Object Pascal), sono d'accordo con gli altri sul fatto che devi prima conoscere VCL e la base di codice dell'applicazione prima di prendere decisioni radicali.

Lo stesso VCL è principalmente legato ai concetti dell'API di Windows, mentre crea una sua traduzione OO molto precisa. È diverso dal QT che ha un obiettivo multipiattaforma.

Riguardo alla logica di business, decifralo (dal codice) al punto in cui puoi scrivere una specifica molto precisa delle REGOLE (o, in altre parole, una nozione precisa di problemi reali che il codebase mirava a rappresentare e risolvere). Con quello, avrai una direzione da percorrere.

dipende dalla tua situazione aziendale.

supponi che

1. ci vorrà molto tempo per ridefinire completamente il codice, specialmente dal momento che sei nuovo nella base del codice e non puoi prevedere come potresti se stessi rifatti il tuo primo codice di bozza.

data questa ipotesi, è necessario considerare l'esigenza aziendale di portare questo codice. hai detto che volevi "mantenere" il codice. cosa comporta esattamente questo? hai intenzione di aggiungere funzionalità aggiuntive? o semplicemente correggere bug di output minori o logicamente semplici, ma showstopping, arresti anomali.

quali altri benefici otterresti dal refactoring? il codice sarebbe più portatile o utilizzabile in un nuovo ambiente o sistema operativo? essere più facilmente integrato in un progetto che insieme soddisferà adeguatamente le esigenze aziendali?

prendere in considerazione queste domande quando si decide o si presenta un caso.

considera gli obiettivi a breve, medio e lungo termine di questo compito. potrebbe costare molto a breve termine per il refactoring, ma se intendi mantenere il modello concettuale intorno, potrebbe benissimo servire come base per un'intera nuova generazione di prodotti.

viceversa, se stai apportando modifiche all'ingrosso al tuo ambiente di lavoro che potrebbero rendere non solo obsoleto il codice disordinato, ma l'intero modello concettuale , potrebbe essere preferibile semplicemente selezionare i 10 più coraggiosi o pezzi confusi, riscrivili nella lingua originale, ma chiaramente, e vai avanti. mantienilo in vita, risparmia denaro e costruisci qualcosa che vuoi davvero dopo, prendendo lezioni da ciò che hai, ti piace e non ti piace / hai bisogno di guidarti

In generale, hai appena detto che lo rifaserai perché è un casino. Bene, gli utenti vogliono programmi che girano, fanno quello che vogliono, ecc. Non chiedono nuovi programmi perché il codice di quello vecchio (che non vedono nemmeno) è un casino.

Se il vecchio programma ti impedisce di fare qualcosa, allora, forse, potresti spendere tempo, denaro, ecc. per farlo da zero. Ma tieni presente che ci sono molti punti contrari:

1 - cattivo o no, gli utenti sanno come aggirare alcuni bug. Anche se riscrivi l'app ed è perfetta, i tuoi utenti non sapranno come gestirlo all'inizio. A nessuno piacciono i cambiamenti, anche per migliorare.

2 - Gli utenti sanno che work-around = significa che non sono documentati, quindi potresti perdere alcune funzionalità quando provi a fare il nuovo software (perché non sarà nel vecchio codice, o qualcuno mancherà per dirti che)

3 - devi avere dei guadagni per l'utente per giustificare la riscrittura: fare tutto il resto per finire con lo stesso sistema significa che non ci sono benefici per l'utente

4 - il nuovo software presenterà nuovi bug e questo giocherà contro di te

5 - gli utenti non vogliono qualcosa di nuovo, un altro sistema, ecc., invece di ripetere semplicemente ciò che hanno già?

Quando si guardano progetti su larga scala (specialmente quelli sui quali non si è lavorato), è molto importante realizzare una cosa. Nessuno dovrebbe aspettarsi che tu lo comprenda pienamente. Dovresti vivere secondo il mantra di divide et impera. Questa è la tecnica che ho sempre usato per non deludermi.

Considera un chirurgo che si presenta con un paziente con lesioni gravi che richiedono la tua attenzione. Diciamo che hai qualche infezione in una ferita alla gamba. Questo sarebbe analogo a una cattiva libreria / codice che vuoi eliminare dal tuo codice. Dovresti prima provare a stabilire l'estensione dell'infezione. L'analogia è una rapida grep per vedere quanti file effettivamente usano quella libreria / codice e qual è la natura di utilizzo. Questo è un passo significativo nell'intero processo e solitamente il più ingombrante. Ma dopo aver fatto ciò, ciò che realizzi è l'identificazione dei tuoi confini e questi sono fondamentali. Una volta che conosci le estensioni, puoi applicare l'anestesia in modo appropriato (assumendo l'anestesia locale perché meglio si adatta all'esempio). In termini di codice, queste potrebbero essere interfacce nei posti appropriati vicini al confine, test unitari, ecc. Costruire interfacce e creare test unitari al confine consente di contrassegnare il limite. Dopo aver contrassegnato il tuo limite, dovresti essere più o meno libero di attaccare l'infezione / codice errato che comunque ti piace mentre i tuoi test di interfacce e unità di confine assicurano di non perdere mai la strada. Una volta fatto con tutte le modifiche all'interno del tuo confine, vale a dire: tutti gli ammaccature e la pittura, la tua applicazione dovrebbe comportarsi come ha fatto senza avere alcuna conoscenza di qualsiasi operazione che abbia mai avuto luogo.

Quindi ripeti l'intero processo per la prossima libreria / brutto pezzo di codice finché non li bersagli tutti. Quindi, in sintesi, scegliere le tue battaglie e localizzare la tua attenzione è fondamentale, quando affronti le grandi bestie brutte di tale natura. Buona fortuna.