Gran parte del mio codice ha un difetto di progettazione importante. Finirlo o ripararlo ora? [chiuso]

Se fossi nei tuoi panni, probabilmente lo proverei in questo modo:

• per prima cosa, completa il progetto corrente, almeno in parte, il prima possibile, ma in uno stato funzionante . Probabilmente hai bisogno di ridurre i tuoi obiettivi originali, pensa alle funzionalità minime che devi assolutamente vedere in "versione 1.0".

• allora, e solo allora pensa a una riscrittura da zero (chiamiamo questa "versione 2.0"). Forse puoi riutilizzare parte del codice dalla V1.0. Magari dopo aver dormito di nuovo sulla situazione, si giunge alla decisione di poter refactoring V1.0 e salvare la maggior parte di esso. Ma non prendere questa decisione prima di non avere una "prova del concetto V1.0" a portata di mano.

Un programma di lavoro "1.0" è qualcosa che puoi mostrare agli altri, anche quando il codice è cattivo (di cui nessun altro si preoccuperà, tranne te stesso). Se nel mezzo della creazione di V2.0 ti accorgi di essere a corto di tempo, hai ancora la V1.0 come un parziale successo, che sarà molto meglio per il tuo morale. Tuttavia, se non si finisce prima la V1.0, c'è una grande possibilità che non si possa mai completare la V2.0 perché quando a metà strada, ci sarà un punto in cui non si è soddisfatti di nuovo con il progetto, e poi? Abbandonerai nuovamente la V2.0 e lavorerai su V3.0? C'è un alto rischio di imbattersi in questo cerchio infinito, senza mai finire.

Meglio prendere questa come un'opportunità per imparare come raggiungere obiettivi intermedi, invece di un'opportunità per imparare come lasciare i progetti in uno stato incompleto alle spalle.

I progetti IT finiti, anche quelli difettosi, sono molto meglio di quelli incompiuti.

Anche quelli incompiuti possono insegnarti molto, ma non tanto quanto quelli finiti.

Potresti non vederlo ora, ma ottieni un enorme quantità di valore lavorando anche con codice difettoso.

Il mio voto va per la finitura e poi, forse, per il refactoring, se necessario. Quando inizi a lavorare con più progetti vedrai che sorprendentemente spesso la parte che "doveva essere rifattorizzata" rimane invariata per anni, mentre altri pezzi vengono estesi.

Da un punto di vista lavorativo, nella maggior parte dei casi, otterrai più complimenti per un progetto finito.

Vorrei iniziare felicemente il progetto.

Sei uno studente e stai ancora imparando. Questo ti mette in una posizione molto diversa dalla domanda a cui ti sei collegato.

• Non hai alcuna responsabilità professionale per il tuo codice; se dovessi eliminare l'intero progetto adesso e andare via, non subiresti ripercussioni. Questo è un enorme vantaggio per uno sviluppatore. Nella domanda che hai collegato, quegli sviluppatori stanno cercando di mantenere il software per il quale la gente paga dei soldi, e anche i microscopici bug possono causare grossi problemi ai clienti, il che rende pericoloso scrivere da zero. Non hai questo problema.

• Come progetto personale, questa è l'occasione perfetta per provare nuove cose e imparare dai tuoi errori. È fantastico che tu abbia riconosciuto che il tuo vecchio codice ha problemi, perché questo significa che hai imparato come fare meglio. L'esperienza attraverso tentativi ed errori può essere preziosa per i programmatori principianti.

• Il tuo progetto è relativamente piccolo e in pratica non hai test. Potrebbero essere poche notti a scrivere 3000 righe da zero, soprattutto perché hai già idee su cosa fare meglio la prossima volta.

• Lavorare in una base di codice spezzata sarà un drenaggio molto più grande del tuo morale di quanto farebbe una riscrittura.

Per inciso, questa potrebbe essere una buona occasione per provare a scrivere un programma più modulare con i test unitari. In questo modo è più facile capire il codice se torni indietro dopo una lunga pausa e aiuta a prevenire gli errori che potresti introdurre involontariamente a causa della dimenticanza.

Infine, qui è un'opinione sulla saggezza di fare talvolta passi indietro per fare passi avanti più grandi.

Probabilmente sei ancora nella parte "learning fast" del tuo sviluppo. Ci sono buone probabilità che tra qualche mese scoprirai che il tuo nuovo e fantastico design è orribilmente rotto in modi di cui non eri nemmeno a conoscenza quando hai iniziato.

Fai le cose - questa è la singola cosa più importante che devi imparare. Credetemi, conosco un sacco di persone (non solo programmatori) che sono bloccate nel "continuate a ricominciare da zero da quando ho imparato tanto prima di iniziare questo progetto". Il problema è che non finisce mai - finché non smetti di imparare cose nuove, che non è un bel posto per essere:)

È anche importante essere in grado di terminare effettivamente qualsiasi cosa. Ricominciare è eccitante, bello, divertente ... ma se lo impari solo, non sarai mai in grado di finire nulla. Ancora una volta, questa non è un'abilità molto utile, e in realtà non è abbastanza buona come rendere qualcosa di utile (o divertente). La vita è breve, il tempo è limitato, e non puoi semplicemente continuare a praticare senza risultati tangibili - diventerai piuttosto pazzo da quello. Se non riesci a iniziare a lavorare perché non riesci a decidere quale approccio adottare, sei già nella zona di pericolo.

Ci saranno sempre impulsi da ricominciare. Anche in un ambiente di apprendimento, queste sono probabilmente una cattiva idea. Ciò non significa che è necessario trasportare ogni singolo prototipo in un'applicazione pronta per la produzione, tutt'altro. Ma è necessario almeno arrivare a una fase di prototipo funzionante: molto probabilmente aiuterà il morale, ed è un tratto molto utile per uno sviluppatore di qualsiasi tipo. Fai le cose . E la parte divertente è che vedrai subito che ci sono un milione di cose più divertenti o utili che puoi fare con il tuo prototipo piuttosto che "riscriverlo da zero" - e in molti casi, persino rifattorizzarlo. Tutto quello che fai ha un costo - per lo meno, avresti potuto fare qualcos'altro nel frattempo.

Seguo la "Fallo funzionare, rendilo giusto, fallo velocemente" ideologia nello sviluppo del software.

1. Fallo funzionare : scrivi le funzionalità di base, in modo che il progetto sia utilizzabile. Fai quello che devi per far funzionare tutto, anche se questo significa un brutto codice.
2. Rendi corretto : correggi bug e rifatta il codice in modo che sia più facile da leggere, capire e mantenere.
3. Rendi veloce : ottimizza il programma, mirando a un buon equilibrio tra velocità, utilizzo delle risorse e manutenibilità.

In questo momento, non hai completato il passaggio 1. Prima fallo, quindi puoi preoccuparti di quanto sia brutto il tuo codice. Realmente creare un prodotto funzionante è una delle cose più difficili da fare per i nuovi sviluppatori, perché sono così presi dal tentativo di rendere il loro codice perfetto per la prima volta, e quindi rimangono bloccati in Optimization Hell e non arrivano mai alla fine implementando tutte le funzionalità. Devi imparare come mettere da parte tutte quelle preoccupazioni sul refactoring e sull'ottimizzazione in modo che tu possa concentrarti solo sul far funzionare il software. Una volta acquisita maggiore esperienza, farai naturalmente più cose per la prima volta, quindi è necessario un minore refactoring.

Ricorda: l'ottimizzazione prematura è la radice di tutti i mali (vedi questa eccellente domanda di Programmers.SE per una buona discussione). Se passi troppo tempo a pensare a come migliorare il tuo codice, rimani bloccato nella paralisi dell'analisi . Questo uccide il progetto. È meglio portare a termine il progetto prima di provare a ottimizzarlo.

Per citare un grande oratore motivazionale: fallo e basta .

Come sempre, c'è un xkcd rilevante:

Riscrivialo. Il codice non funzionante ha poco valore e tremila righe non è un gran numero di codice. Non ci vorrà quasi il tempo necessario per scrivere il codice che hai attualmente, e sarà molto meglio. Ho spesso buttato fuori cinquecento o migliaia di righe di codice scadente, e spesso la riscrittura è lunga un quinto.

La maggior parte delle nozioni di "non riscrivere" si riferiscono a sistemi di grandi dimensioni che fanno cose importanti e subiscono continue modifiche per soddisfare i requisiti in evoluzione. Riscrivi di sistemi complessi in uso raramente riescono.

La tua situazione è l'esatto contrario. Hai una piccola applicazione senza utenti e gli unici requisiti sono quelli che decidi di implementare. Quindi vai avanti e riscrivilo.

Riavviare da zero è di solito una brutta mossa nei progetti reali, principalmente perché i progetti di vita reale accumulano correzioni di bug di cui uno sviluppatore non è a conoscenza (ad esempio, vedi Cose da non fare mai , dal blog Joel on Software .

Tuttavia, i progetti scolastici non ereditano tale storia e di solito iniziano con la codifica e la progettazione allo stesso tempo con una conoscenza parziale dell'informatica e della mancanza di esperienza. Prenderò in considerazione la tua prima versione come un prototipo, usato come prova del concetto che ha fallito, e lo butterei volentieri via (vedi Quali sono le differenze tra i prototipi di lancio e quelli evolutivi? per una discussione sulla prototipazione "usa e getta".

Il design giusto è maturato nella tua testa e non dovrebbe richiedere molto tempo per scriverlo nel codice.

Sarei rispettosamente in disaccordo con i suggerimenti che la riscrittura è una cattiva idea.

Nel regno del ciclo di vita del software, è generalmente accettato che il tempo e lo sforzo richiesti per correggere un errore aumentino di un ordine di grandezza ogni strato nel ciclo di vita. Cioè, se ci vuole 1 ora per correggere un errore a livello di requisiti, ci vorranno 10 ore di progettazione, 100 ore di test di codifica e 1000 ore come correzione di bug. Questi numeri potrebbero sembrare scandalosi, ma sono accettati dall'industria come approssimativamente corretti. Ovviamente, meno in un progetto più piccolo, ma l'idea generale rimane. Se il tuo progetto ha un difetto di progettazione di base, è più appropriato chiamarlo un'esperienza di apprendimento e tornare indietro, rivedere i requisiti iniziali e riprogettare.

Vorrei anche incoraggiare la considerazione di un modello di Test Driven Development utilizzando test di unità strutturate. Sono un dolore e inizialmente sembrano uno spreco di tempo, ma la loro capacità di scoprire errori, specialmente quando si integra con il codice di qualcun altro, non può essere superata.

Mi hai perso a questa frase:

The problem is that I have not finished even the main functionality of my program, so I cannot truly refactor, and I feel discouraged to go on perfectly aware that my code's design is flawed.

Credo nel principio (affermato in Systemantics ) che

• A complex system that works is invariably found to have evolved from a simple system that works.
• A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

Quindi, scrivere un sistema complesso include

• Scrivere un semplice sistema
• Assicurarsi che funzioni

... ovvero i seguenti passaggi:

1. Scrivi un po 'di codice
2. Provalo per assicurarti che funzioni
3. Scrivi un po 'più di codice
4. Prova di nuovo
5. Etc.

Nota che il passaggio 3 potrebbe comportare:

3. Scrivi un po 'più di codice
   1. Rifatta il codice esistente per prepararlo per una nuova aggiunta
   2. Verifica il refactoring per assicurarti che funzioni ancora
   3. Aggiungi la nuova funzionalità

Inoltre, il passaggio 2 "Provalo per assicurarti che funzioni" potrebbe comportare un po 'di riscrittura in caso contrario.

Se dovessi basarmi su un codice errato, non sarei incline ad aggiungere ulteriori funzionalità. Quindi sarei propenso a programmare qualcosa come "semplificare l'implementazione del threading esistente" come il prossimo pezzo di lavoro da implementare. Supponendo che tu stia testando mentre vai avanti, dovresti essere in grado di trattarlo come un esercizio di refactoring. I criteri di successo / uscita per questa fase di lavoro sarebbero:

• Il codice sorgente è più semplice
• E non sono stati introdotti nuovi bug
• (E alcuni vecchi bug sono stati eliminati)

Per inciso, "testarlo per assicurarsi che funzioni" non significa necessariamente "test unitari" - quando la struttura del team è semplice, puoi testare un (semplice) sistema usando (simple) test di sistema (invece test unitari) .

Uno dei problemi che stai affrontando quando ti imbatti in un problema come questo, sei emotivamente attaccato al codice che hai scritto finora in un modo o nell'altro.

Un collega mi ha detto che stava scrivendo un programma mentre era all'università mentre riceveva lezioni da un famoso professore (credo fosse Dijkstra). Ha chiesto al professore di dare un'occhiata al codice su cui aveva lavorato per oltre un mese. Il professore gli ha chiesto se aveva fatto un backup, ha risposto di no. Il professore ha quindi cancellato tutto il suo codice e gli ha detto di scriverlo di nuovo.

Era incazzato, ma 3 giorni dopo ha terminato il programma, con un codice più pulito e meno bug e meno linee di codice.

Cerca di fare una stima onesta su quale sia l'opzione migliore nel tempo disponibile per il progetto.

Le 3 scelte sono

• Elimina (completamente, senza guardare indietro)
• Continua a lavorare nel vecchio design
• Codice refactoring mentre vai.

Sono stato un programmatore professionista per oltre 10 anni e nel mio lavoro sono giunto alla conclusione che l'ultima opzione è la maggior parte delle volte scelta, ma non è sempre l'opzione migliore.

Sembra che le tue abilità siano cresciute notevolmente in quel periodo di tempo. Forse lavorare a questo progetto ha contribuito a questo. Progettarlo nuovamente come esperienza di apprendimento intenzionale sarebbe fruttuoso.

Ricorda, questo non è qualcosa che devi fornire come programma di lavoro per un cliente. È stato scritto appositamente per la pratica. Quindi, a meno che tu non voglia esercitarti con problemi di spedizione e consegna difettosa, penso che tu sia attualmente in una fase di sviluppo in cui lavorare i tuoi "muscoli di progettazione" si dimostrerebbe fruttuoso.

Nel fare ciò, concentrati sul processo di progettazione e pianificazione, e rifletti sui tuoi contenuti esistenti e rifletti su ciò che stai capendo meglio.

Refactor. Refactor. Refactoring! Refactor !!!!

Onestamente, non importa quanto tu sia esperto, questo è un problema comune. Hai scritto codice, hai imparato qualcosa e vuoi usare le nuove conoscenze sul vecchio codice. Vuoi misurare il vecchio codice rispetto alla nuova conoscenza.

Questo non funzionerà. Se lo fai, la tua applicazione / gioco non sarà mai completata. Invece, cerca di destinare il tuo tempo al progetto in modo che alcuni dei tuoi "compiti" siano di rifattorizzare il codice errato. Diciamo, ad esempio, che hai avuto un metodo orribile per salvare il gioco. Continua a lavorare sul gioco stesso, ma trova il tempo di refactoring (sostituire) quel metodo orribile. Cerca di mantenere piccoli i refattatori e non dovrebbe essere un problema.

Quando si arriva a una parte importante dell'applicazione che ha bisogno di un refactoring, lo si sta facendo in modo sbagliato, seriamente. Rompi quel refactoring in parti più piccole. Prova a dedicare sette ore alla scrittura del codice e all'ora di refactoring.

Quando hai terminato il progetto e hai bloccato il blocco delle funzionalità, puoi dedicare un lungo periodo di refactoring. Per ora, fai il gioco, ma prova ancora a rifattorici. È il meglio che puoi fare.

Ci sarà sempre qualcosa da refactoring.

Direi che dipende un po 'dal tipo di codice che hai ora e da dove si trovano esattamente i problemi. Vale a dire, se le tue basi sono buone (design di classe corretto nella maggior parte delle parti, buon disaccoppiamento / coesione ecc., Solo alcune scelte sbagliate come i fili che hai citato), allora prendi un nudo di 1.0 e poi rifatti come non c'è domani.

D'altra parte, se in realtà è solo un mucchio di file di testo brutti e schiacciati in qualche modo che passano il compilatore, senza una struttura visibile ecc. (in altre parole, un proof-of-concept di apprendimento sul lavoro prototipo), quindi preferisco eliminarlo e ricominciare da capo.

Nella tua prossima versione, fai un approccio agile: imposta una linea temporale fissa e ripetitiva, ad esempio 2 settimane o qualsiasi altra cosa si adatti al tuo programma. All'inizio di ogni blocco (chiamiamolo uno sprint), definisci obiettivi che sono raggiungibili nelle 2 settimane. Vai avanti e fallo, prova il più presto per farlo funzionare. Imposta i tuoi obiettivi in modo che dopo ogni 2 settimane tu abbia qualcosa che possa essere mostrato ad un amico, non solo un lavoro interno astratto. Google "mischia" e "obiettivo intelligente". Questo è tutto molto facile da fare, se sei da solo, solo un pezzo di carta con alcuni punti elenco rapidamente annotati.

Se riesci a farlo, ricominciare è buono. Se sai bene che dopo aver ricominciato, probabilmente finirai dove sei ora, poi rimani con il tuo codice e fallo funzionare.

Devi metterti nei panni del datore di lavoro.

Per la maggior parte dei reclutatori, saresti il più prezioso se andassi in questo modo: - Completalo con test al 100% sul nuovo codice che scrivi. - Aggiungi test per il vecchio codice (progettato male). - Rifattalo per ottenere quello che volevi come design.

Fai tutto ciò con un buon processo di controllo delle versioni, rami e tag.

La riscrittura è spesso un'idea sexy, ma è spesso un'idea che i nuovi arrivati hanno di che è un po 'pericoloso nella vita reale. Dimostrando che sei più disposto a migliorare la qualità del lavoro che hai già fatto piuttosto che partire da zero è un buon segno che sei una persona seria.

Puoi ovviamente riscriverlo, ma fallo un altro progetto.

Solo per aggiungere un po 'della mia esperienza passata al mix. Ho lavorato a un progetto parallelo da più di un anno, ogni volta che ottengo qualche minuto libero. Questo progetto è passato da un semplice banco di prova a una classe statica a un design a linee sottili orientato agli oggetti che è al momento.

Nel corso di tutte queste modifiche ho mantenuto la stessa funzionalità del codice, escludendo correzioni di bug e prestazioni (occorre essere il più veloce possibile). La stessa base di codice anche se refactored è rimasta la stessa e come tale l'ho migliorata in modo massiccio senza dover riscrivere il codice da zero e perdere tempo.

Questo significa che sono stato in grado di migliorare il codice a un ritmo più veloce di quanto avrei potuto fare prima. Significava anche che stavo andando, era più facile dire cosa rimuovere, cioè classi inutili, e cosa poteva rimanere più facile della riscrittura con la vecchia idea ancora nella mia mente.

Quindi il mio consiglio sarebbe quello di refactoring il codice e andare avanti da lì, apportando miglioramenti, se necessario. Anche se ti ricordi se decidi di riscrivere da zero dovresti prendere le buone idee del vecchio progetto e guardarle attentamente per vedere dove sono difettose. Cioè non copiare semplicemente il vecchio codice nel nuovo progetto.

La risposta dipende da qualcosa che mi piace chiamare il "soffitto della complessità". Man mano che si aggiunge sempre più a una base di codice, si tende a diventare sempre più complesso e sempre meno organizzato. Ad un certo punto, colpirai un "tetto di complessità", a quel punto il progresso diventa molto difficile. Piuttosto che cercare di continuare a muoverti con la forza bruta, è meglio eseguire il backup, riorganizzare / riscrivere e quindi continuare ad andare avanti.

Quindi il tuo codebase è così grave che ti stai avvicinando a un limite di complessità? Se senti che lo è, prenditi del tempo per pulire e semplificare prima di procedere. Se il modo più semplice per ripulire è riscrivere alcune parti, va bene.

Nessuno dei due? Entrambi?

Continua, dedica un po 'di tempo alla revisione del design esistente e aggiungendo un po' di tempo all'aggiunta di nuove funzionalità.

Se hai interazioni filanti, potrebbe essere un buon punto di partenza ("thread eccessivi nel renderer" suona come un'inefficienza, piuttosto che qualcosa che potrebbe causare problemi di correttezza). Vedi se riesci a capire un modo generale di allontanarti dalle razze (e possibilmente deadlock), o almeno più modi specifici per farlo.

Non so fino a che punto siano disponibili deadlock e race detectors per C #, ma se esistono potrebbero essere utili per identificare quali problemi ci sono e verificare che le correzioni funzionino.

Trovo che, in generale, sono più motivato a risolvere i problemi con il codice che fa qualcosa di utile, piuttosto che buttarlo via e ricominciare da capo. Ci sono casi in cui lo sviluppo di campi bruciati (in analogia con greenfield e brownfield ...) è più soddisfacente, ma di solito è per le cose in cui l'approccio esistente è così lontano da dove dovrebbe essere che non è più nemmeno sbagliato.

Se il tuo codice è modulare, dovresti essere in grado di completare il resto del codice attorno ai componenti scritti male, quindi riscrivere i componenti scritti male senza influire sul resto del codice.

In tal caso, spetta a te quando riscrivi i componenti scritti male. Se i componenti scritti male sono scritti così male che il codice finito non funzionerà con loro così come sono, allora dovrai riscriverli prima di poter completare il resto del codice.

La prima domanda che dovresti porci è "quanto è grave il difetto?"

Che cosa hai fatto di sbagliato?

Se qualcosa è così grave da sprecare tonnellate di ore cercando di risolvere il problema, espone dati sensibili (password / carte di credito) o causa una brutta vulnerabilità, forse dovresti modificarlo, ma la maggior parte tempo puoi prendere ciò che hai, finirlo e risolvere il problema più tardi.

I programmatori amano migliorare le loro applicazioni, volendo che siano "il meglio che può essere", ma non è l'approccio corretto.

SE la tua applicazione viene rilasciata il prima possibile, anche se non è al 100%, tutti i bug e poi ricevi FEEDBACK dagli altri, mentre hai tempo per correggere gli errori e altre cose per la versione 1.1. Altre persone saranno in grado di aiutarti a rendere l'applicazione molto migliore e potresti avere tempo perso facendo qualcosa che le persone potrebbero non avere gradito.

Quindi nel tuo caso, fallo fuori, ottieni un feedback, quindi puoi strutturare la versione 2.0 con tutte le modifiche e correggere il difetto che hai.

Un'altra cosa da ricordare è che stiamo migliorando costantemente. C'è un detto che se riesci a vedere il tuo codice da un anno fa e vedi che è cattivo, significa che stai ancora migliorando, ed è una cosa grandiosa.

Dipende da quanto è incasinato il tuo codice.

• Se hai commesso errori n00b reali che rendono il tuo codice troppo complesso o prolisso, ti consiglio di riscrivere quelle parti.

• Se pensi di avere dei bug seri che dovrai comunque risolvere, scrivi alcuni test unitari in grado di verificare se hai corretto il bug (... dato che non puoi ancora lanciare il programma ). È meglio correggere i bug in anticipo, ed è decisamente meglio correggere i bug mentre si ricorda ancora il codice.

• Se non ti piace come vengono chiamati i metodi, o a quale classe appartengono, o cose del genere, usa semplicemente l'IDE. (Ricorda, questo è C #, non alcuni javascript, python, perl, php, ecc.) Quando stai lavorando su codice che usa il componente interessato, e hai una visione chiara di ciò che dovrebbe fare quel componente, quindi rifattalo se il tuo IDE lo rende indolore.

Altrimenti, fallo funzionare e affina le tue abilità nel prossimo progetto.

Come altri hanno suggerito, poiché questo è un progetto personale, non (ancora) un progetto professionale, prenderei seriamente in considerazione una riscrittura.

Tuttavia, puoi sfruttare il metodo scientifico qui, eseguendo un esperimento. Primo, concepire un'ipotesi. Il mio sarebbe "è probabilmente il momento di riscrivere". Per risparmiare tempo, ridurre il costo dell'errore e in qualche modo limitare la distorsione a priori, prima di eseguire qualsiasi altra programmazione, decidere un intervallo di tempo ("time box"). Suggerirei forse 4 ore a muro. Decidere anche su una metodologia per valutare l'ipotesi. Dato che la posta in gioco è bassa, ti suggerirei come una metodologia, semplicemente chiediti: "Sono contento di averlo fatto?" Ora inizia l'esperimento. Dopo la casella prescelta, qual è la valutazione dell'ipotesi? per esempio. Dal mio esempio, sei contento di aver iniziato a riscrivere ora che hai trascorso 4 ore a farlo? Quindi è probabilmente la scelta giusta.

Puoi chiedere tutti i consigli del mondo, ma non c'è nulla di meglio che testare empiricamente un'ipotesi.

Alcuni motivi per considerare la selezione di una riscrittura come esperimento:

• Nella mia esperienza, di solito è più divertente. Un grande motivo per cui le riscritture spesso non vengono selezionate in situazioni professionali è che il divertimento è lontano dall'unico criterio. Ma sei ancora relativamente nuovo nella programmazione, quindi il divertimento è probabilmente un criterio piuttosto importante e anche un indicatore di altri fattori che potrebbero essere intangibili per te in questa fase iniziale (il divertimento suggerisce che ne imparerai di più, ecc.).
• La tua esperienza e probabilmente un fastidioso senso di coscienza sembrano dirti che vale la pena considerare una riscrittura. Ascolta quella voce, se ce n'è una. Anche se non segui il suo consiglio, almeno ascolta. In futuro ci saranno più voci esterne e avrai bisogno di esercitarti ascoltando il tuo buon senso.
• Sospetto che con una riscrittura, è più probabile che tu possa modulare ulteriormente il tuo codice. Quando crei moduli, hai componenti più riutilizzabili e affidabili che puoi sfruttare per altri progetti. Potresti anche scoprire che alla fine, quello che sembrava un semplice modulo del tuo progetto principale risulta essere il pezzo di codice più interessante e prezioso che scrivi.

Finire qualcosa è una buona idea, ma non nel vuoto. Se inizi una riscrittura, puoi scegliere di completare qualcosa terminando un sottomodulo particolare. Potresti impostarlo come primo obiettivo, dopo l'esperimento precedente. Finire non significa necessariamente terminare il tuo progetto principale iniziale. Dopo aver completato un modulo, finisci un altro, ecc., Finché non hai terminato di riscrivere l'intero ambito del tuo progetto originale, se lo desideri.