Ricominciare tutto da capo? [duplicare]

although I will lose time it will be better to just start all over again?

No.

Ho scartato software scadente senza pensarci due volte.

Raramente penso che perderò tempo perdendo il software spazzatura.

È spazzatura. Scarta. Non importa quanto possa essere sembrato prezioso perché è stato investito qualche sforzo in esso. Se è spazzatura, tutto lo sforzo ulteriore è semplicemente creare più costi, non creare nuovi valori.

What should you consider before making this step?

Il design rivisto.

Come conservare i dati.

I know it can be drastic in some cases,

False. La spazzatura è spazzatura. Scarta in anticipo e spesso. Non è drastico quando il software è spazzatura.

is it best to just totally ignore what you did before, or take some of the best bits from it?

Questo è imponderabile. Dipende dalle specifiche di ciò che hai fatto prima e da quanto è stato male.

Il nostro sito web corrente utilizza uno schema di denominazione application_# finale. Il numero è il numero di versione principale. Quando modifichiamo un database, eliminiamo essenzialmente l'intera versione precedente dell'applicazione. È strettamente legato al database.

Non cambiamo "in modo incrementale" il database. Scartiamo la versione precedente e andiamo avanti.

Due dei moduli sono nella versione principale 3. Due precedenti scarti di software spazzatura.

Uno dei moduli è nella versione principale 2. Il precedente doveva essere scartato come inopportuno.

Questi sono scarti della versione precedente e migrazione dei dati a nuove tabelle con una struttura diversa (da cui il numero di versione principale).

Lo facciamo sempre. Più rapidamente ti libererai del software spazzatura più diventerai efficace.

Non penso che sia saggio. anche Joel lo pensa . Il codice maturo è fragile e tende ad avere molti hack. Ma di solito il codice maturo tende ad essere corretto. È sciocco scartare la correttezza a favore della purezza del design. La purezza del design non significa nulla per l'utente finale, il software corretto significa molto.

Se ritieni che il design sia spazzatura, identifica la parte più spazzatura e ripara. Per dirla in un altro modo, inizia a riparare finestre rotte invece di costruire una nuova casa. Il vantaggio di risolvere a poco a poco è che hai sempre un sistema funzionante. Hai casi di test (si spera) su cui fare affidamento per verificare la correttezza. Potrebbe essere necessario più tempo per crearlo da zero, ma avrai sempre il software corretto da spedire.

Questo succede sempre.

Una critica al Waterfall Model è formulata come "Solo molti dei dettagli del [sistema] ci rendiamo noti mentre progrediamo nell'implementazione [del sistema]. Alcune delle cose che apprendiamo invalidano il nostro design e dobbiamo tornare indietro. "

Però dovresti fare attenzione a conoscere questo effetto solo per essere frustrato dal fatto che non raggiungi il tuo obiettivo non appena / facilmente come speravi.

Penso che questo accada molto spesso, e ci sono modi per batterlo. Questo è esattamente il motivo per cui i prototipi esistono. E battere anche loro è più facile, devi solo essere un po 'organizzato e un po' disciplinato.

Il modo di guardarlo è che la programmazione è fondamentalmente basata sulla risoluzione dei problemi. Quindi devi iniziare con un problema chiaramente definito su carta . Non sono ammesse definizioni ambigue. Una volta fatto ciò, devi decidere quali sono le soluzioni possibili su su carta . Continua a pianificare in modo minimo ma sufficiente.

Dopo questo inizio con il primo set di funzionalità, rilascialo, testalo. Prendi un feedback, inizia con il prossimo set di funzionalità. Ogni volta che qualcosa va storto sai dove correggerlo. Penso che questo sia ciò che chiamiamo agile, anche se c'è più di agilità.

Avviare un progetto di grandi dimensioni nel suo complesso andando a metà strada e poi scoprire cose che vanno storte è praticamente previsto.

Credo nella legge sulla "terza implementazione". La prima implementazione è sempre una qualità di prototipo. Il secondo round di ricostruzione da zero affronta i problemi più basilari trovati in un prototipo e mostra infine difetti di progettazione fondamentali. Questi difetti sono affrontati da una terza reimplementazione da zero. Non dovrebbe essere necessariamente la tua re-implementazione, un sistema in competizione potrebbe anche risolvere i tuoi problemi.

La prima cosa che faccio normalmente in una situazione del genere - fai un respiro profondo e fai una pausa.

Divertiti con gli amici, vai in palestra, visita un concerto - qualsiasi cosa per liberare il cervello dalla programmazione. Quindi guarda il progetto il giorno dopo. Se è ancora cattivo, avvialo dappertutto.

Ma non rimuovere i vecchi repository. Trovo alcuni pratici trucchi anche nel mio codice più antico e più noobico. E naturalmente ti ricorderà in futuro quanto hai imparato.

Se è così brutto che correggere bug e aggiungere nuove funzionalità è inaccettabilmente lento, devi fare qualcosa. Altrimenti, non saltare ancora in azione.

In ogni caso, vale la pena fare un piano.

Devi iniziare dichiarando cosa stai cercando di raggiungere e qual è un livello accettabile di successo. Altrimenti la riscrittura potrebbe discendere in un ciclo infinito di raffinamento di bit di codice sempre meno importanti.

Il prossimo passo è tracciare un disegno che si adatti ai criteri precedentemente stabiliti.

Quindi devi cercare di capire come suddividere le modifiche in piccoli passaggi in modo da non dover interrompere tutto per un anno mentre sei impegnato a riscrivere tutto da zero. Se il sistema originale è abbastanza modulare e i moduli sono almeno disposti correttamente, puoi quasi sicuramente trovare un modo.

Affina il tuo progetto in base al risultato del passaggio precedente e verifica se soddisfa ancora i requisiti.

Se la situazione è davvero brutta, puoi iniziare a implementarla, se non lo è, salvala come un piano per il futuro.

Sono stato in questo campo per oltre trent'anni, e credo ancora che pianificare di buttarne via uno sia ancora una solida pratica di ingegneria del software. L'80% della vita utile di un sistema utile viene speso in modalità manutenzione. I sistemi fragili sono più costosi da mantenere rispetto ai sistemi non fragili. Tuttavia, si dovrebbe anche essere consapevoli di un altro Brooksism; vale a dire "L'effetto del secondo sistema".

Se si tratta di qualcosa con una cattiva progettazione o implementazione, ti farà perdere più tempo rispetto a quando lo fai correttamente.

Ogni piccola modifica che si tenta di fare richiederà più tempo del necessario a causa di cattive dipendenze, isolamento, accoppiamento, ecc.

Se lo fai da zero, fai le cose più velocemente, meglio, più facilmente, il morale aumenterà e aumenterà anche la tua produttività!

Devi prima riflettere su una cosa: ricostruirla come un intero o una parte secondaria del sistema? Quest'ultimo è più facile, più veloce e meno rischioso. Dopo una parte, ne scegli un'altra per migliorare e andare avanti finché non hai qualcosa di buono! Il primo potrebbe produrre risultati migliori / più veloci ma aumenta anche le possibilità di rimanere bloccati da qualche parte e di non essere in grado di fare tutto, sprecando una grande quantità di tempo!

Quando stavo facendo la mia tesi di master ho ricostruito completamente la mia applicazione tre volte - che non era il punto principale della tesi - ma questi cambiamenti erano assolutamente degni!

Ogni volta che ho fatto tutto da capo, ho imparato qualcosa di nuovo, ho migliorato qualcosa, ho realizzato che qualcosa potrebbe essere fatto meglio la prossima volta, ecc.

Mi ci è voluto un sacco di tempo (specialmente perché stavo facendo questi miglioramenti da solo, sotto la mia responsabilità - se le cose sarebbero andate male, sarebbe stato il mio problema e il mio tempo perso).

Se il codice è stato scritto correttamente con le unità testate che funzionano, puoi tenere quelle parti sicure sapendo che funzionano e usarle quando ne hai bisogno.

Potrebbe essere possibile disaccoppiarlo abbastanza per estrarre i bit di cui hai bisogno come utilizzabili.

Gettare via tutto di solito è una cattiva idea. Riscrivere parti del sistema potrebbe essere una buona idea. Il refactoring è spesso una buona idea.

Per come la vedo io, la domanda non è se il codice è buono o no. Il codice che hai scritto più di una settimana fa è sempre un pasticcio terribile perché hai imparato qualcosa di nuovo che avresti voluto usare.

La domanda è se il debito tecnologico accumulato stia rendendo difficile il completamento del lavoro. Se il tuo sistema è difficile da eseguire o le modifiche sono più difficili di quelle che dovrebbero essere, ciò significa che probabilmente dovrai correggere qualcosa. Ma a meno che le cose non siano difficili a tutti i livelli, non riscrivere tutto. Riscrivi solo le parti che ti causano dolore.