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

Sono uno studente del liceo che lavora a un progetto C # con un mio amico con lo stesso livello di abilità di me. Finora, abbiamo scritto circa 3.000 righe di codice e 250 righe di codice di test in un arco di 100 commit. A causa della scuola, ho rimandato il progetto per alcuni mesi e recentemente sono stato in grado di riprenderlo.

Quando l'ho ripreso, ho capito che il codice che avevo scritto era mal progettato, come l'inclusione di thread eccessivi nel renderer, la scarsa prevenzione delle condizioni di gara nell'interazione tra CPU emulata, GPU e cartuccia di gioco , nonché codice semplicemente ridondante e confuso.

Il problema è che non ho ancora finito le funzionalità principali del mio programma, quindi non posso veramente rifattorizzare, e mi sento scoraggiato a continuare perfettamente consapevole che il design del mio codice è difettoso. Allo stesso tempo, non voglio abbandonare il progetto; sono stati compiuti notevoli progressi e il lavoro non deve andare sprecato.

Mi sento come se avessi un paio di scelte: terminare semplicemente la funzionalità aggirando il design scadente e quindi refactoring una volta che tutto funziona, arrestando tutto e lavorando per districare tutto prima che il resto della funzionalità possa essere completato, iniziando il progetto dappertutto in modo che sia di nuovo fresco nella mia mente, o addirittura abbandonando il progetto a causa delle sue dimensioni eccessive (essenzialmente "torna al tavolo da disegno").

Sulla base dell'esperienza di altri in tali progetti, qual è il ricorso per tornare sulla strada giusta? Dalle risposte su questo sito, il consenso generale è che la riscrittura non è generalmente necessaria ma è un'opzione disponibile se il codice non può essere mantenuto senza costi eccessivi. Vorrei davvero perseguire questo progetto, ma così com'è, il mio codice non è progettato abbastanza bene per continuare e un sentimento di sconforto mi impedisce di continuare.

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

• in primo luogo, completare il progetto corrente - almeno parzialmente - il più presto possibile, ma in uno stato funzionante . Probabilmente devi ridurre i tuoi obiettivi originali, pensa alla funzionalità minima che devi veramente vedere nella "versione 1.0".

• quindi, e solo allora pensa a una riscrittura da zero (chiamiamo questa "versione 2.0"). Forse puoi riutilizzare parte del codice dalla V1.0. Forse dopo aver dormito di nuovo sopra la situazione, arriverai alla decisione di poter refactoring V1.0 e salvarne la maggior parte. 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 è errato (di cui nessun altro si preoccuperà, tranne te stesso). Se nel mezzo della creazione di V2.0 ti rendi conto che stai esaurendo il tempo, hai ancora V1.0 come parziale successo, che sarà molto meglio per il tuo morale. Tuttavia, se non finisci prima la V1.0, c'è una grande probabilità che non completerai mai la V2.0 perché quando sarai a metà strada, ci sarà un punto in cui non sarai più soddisfatto del design, e poi? Abbandonerai di nuovo V2.0 e lavorerai su V3.0? C'è un alto rischio di imbattersi in questo circolo senza fine, senza mai finire.

Meglio coglierlo come un'opportunità per imparare a raggiungere obiettivi intermedi, invece che come un'opportunità per imparare a lasciare indietro i progetti in uno stato incompiuto.

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

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

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

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

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

Sarei felice di ricominciare il progetto.

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

• Non hai alcuna responsabilità professionale per il tuo codice; se dovessi cancellare l'intero progetto in questo momento e andartene, non subiresti ripercussioni. Questo è un enorme vantaggio per uno sviluppatore. Nella domanda che hai collegato, quegli sviluppatori stanno cercando di mantenere un software per il quale le persone pagano soldi e anche piccoli 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 cose nuove e imparare dai tuoi errori. È bello riconoscere che il tuo vecchio codice ha dei problemi, perché ciò significa che hai imparato a fare meglio. L'esperienza attraverso tentativi ed errori può essere preziosa per i programmatori principianti.

• Il tuo progetto è relativamente piccolo e praticamente 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 rotta sarà un drenaggio molto più grande per il tuo morale rispetto a una riscrittura.

A parte questo, questa potrebbe essere una grande opportunità per provare a scrivere un programma più modulare con unit test. In questo modo è molto più semplice comprendere il codice se si ritorna ad esso dopo una lunga pausa e aiuta a prevenire errori che si potrebbero accidentalmente introdurre a causa dell'oblio.

Infine, ecco un'opinione sulla saggezza di fare talvolta passi indietro per compiere passi più grandi.

Probabilmente sei ancora nella parte "apprendimento veloce" del tuo sviluppo. C'è una buona probabilità che tra qualche mese scoprirai che il tuo nuovo e fantastico design è orribilmente rotto in modi che non eri nemmeno a conoscenza di quando hai iniziato.

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

È anche importante per poter effettivamente finire qualsiasi cosa. Ricominciare è eccitante, bello, divertente ... ma se solo lo impari, non sarai mai in grado di finire nulla. Ancora una volta, questa non è un'abilità molto utile e in realtà non si sente abbastanza bene come fare qualcosa di utile (o divertente). La vita è breve, il tempo è limitato e non puoi semplicemente continuare a praticare senza risultati tangibili - ne diventerai piuttosto pazzo. 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 per ricominciare. Anche in un ambiente di apprendimento, è molto probabile che siano una cattiva idea. Ciò non significa che è necessario trasportare ogni singolo prototipo in un'applicazione pronta per la produzione, tutt'altro. Ma devi almeno arrivare a una fase di prototipo funzionante: molto probabilmente aiuterà il tuo morale, ed è una caratteristica molto utile per uno sviluppatore di qualsiasi tipo. Fai le cose . E la parte divertente è che vedrai rapidamente 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 ciò che fai ha un costo - almeno, nel frattempo, avresti potuto fare qualcos'altro.

Seguo l' ideologia "Make it Work, Make it Right, Make it Fast" nello sviluppo di 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 significa brutto codice.
2. Rendi corretto : correggi i bug e refatta il codice in modo che sia più facile da leggere, comprendere e mantenere.
3. Renderlo 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. Fallo funzionare prima, quindi puoi preoccuparti di quanto brutto sia il tuo codice. In realtà, la creazione di un prodotto funzionante è una delle cose più difficili da fare per i nuovi sviluppatori, perché sono così coinvolti nel tentativo di rendere il loro codice perfetto la prima volta, e quindi rimangono bloccati in Optimization Hell e non riescono mai a finire implementando tutte le funzionalità. Devi imparare a mettere da parte tutte quelle preoccupazioni relative al refactoring e all'ottimizzazione in modo da poterti concentrare solo sul funzionamento del software. Una volta che avrai un po 'più di esperienza, farai naturalmente più cose giuste la prima volta, quindi è necessario meno refactoring.

Ricorda: l'ottimizzazione prematura è la radice di tutti i mali (vedi questa eccellente domanda su 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 iniziare a provare a ottimizzarlo.

Per citare un grande oratore motivazionale: fallo e basta .

Come sempre, c'è un xkcd rilevante:

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

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

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

Il riavvio da zero di solito è una brutta mossa nei progetti di vita reale, principalmente perché i progetti di vita reale accumulano correzioni di bug di cui uno sviluppatore di nuova conoscenza non è a conoscenza (ad esempio, vedi Cose che non dovresti mai fare , dal blog di Joel sul software ).

Tuttavia, i progetti scolastici non ereditano tale storia e di solito iniziano codificando e progettando allo stesso tempo con una conoscenza parziale dell'informatica e la mancanza di esperienza. Considererei la tua prima versione come un prototipo, usata come una prova del concetto che è fallita, e la butterei via felicemente (vedi Quali sono le differenze tra prototipi usa e getta e prototipi evolutivi? Per una discussione sul prototipo evolutivo e usa e getta ).

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

Non sarei d'accordo con i suggerimenti che riscrivere sia una cattiva idea.

Nel regno del ciclo di vita del software, è generalmente accettato che il tempo e lo sforzo necessari 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 nella progettazione, 100 ore nel test di codifica e 1000 ore come correzione di bug. Quei numeri potrebbero sembrare scandalosi, ma sono accettati nell'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 a considerare un modello di sviluppo guidato dai test usando test unitari strutturati. Sono una seccatura e inizialmente sembrano una perdita di tempo, ma la loro capacità di scoprire errori, soprattutto quando si integra con il codice di qualcun altro, non può essere dichiarata.

Mi hai perso con questa frase:

Il problema è che non ho ancora finito le funzionalità principali del mio programma, quindi non posso veramente rifattorizzare, e mi sento scoraggiato a continuare perfettamente consapevole che il design del mio codice è difettoso.

Credo nel principio (dichiarato in sistematica ) che

• Si scopre che un sistema complesso che funziona si è evoluto da un sistema semplice che funziona.
• Un sistema complesso progettato da zero non funziona mai e non può essere riparato per farlo funzionare. Devi ricominciare da capo, iniziando con un sistema semplice funzionante.

Quindi, la scrittura di un sistema complesso include

• Scrivere un sistema semplice
• 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. Eccetera.

Si noti che il passaggio 3 potrebbe comportare:

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

Inoltre, il passaggio 2 "Test per assicurarsi che funzioni" potrebbe comportare una riscrittura in caso contrario.

Se stavo costruendo su una base di codice marcio non sarei incline ad aggiungere ulteriori funzionalità. Quindi sarei propenso a programmare qualcosa come "semplificare l'implementazione di threading esistente" come prossimo pezzo di lavoro da implementare. Supponendo che tu stia testando mentre procedi, 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 eliminati)

Per inciso, "testarlo per assicurarsi che funzioni" non significa necessariamente "unit test" - quando la struttura del team è semplice, è possibile testare un sistema (semplice) utilizzando (semplici) test di sistema (anziché test unitari) .

Uno dei problemi che stai affrontando quando ti imbatti in un problema come questo, è che 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 che fosse Dijkstra). Ha chiesto al professore di dare un'occhiata al codice su cui stava lavorando da oltre un mese. Il professore gli chiese se avesse fatto un backup, lui rispose di no. Il professore quindi cancellò tutto il suo codice e gli disse di scriverlo di nuovo.

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

Prova a fare una stima onesta sull'opzione migliore nel tempo disponibile per il progetto.

Le 3 scelte sono

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

Sono un programmatore professionista da oltre 10 anni e nella mia linea di lavoro sono giunto a concludere che l'ultima opzione è la maggior parte delle volte quella scelta, ma non è sempre l'opzione migliore.

Sembra che le tue abilità siano cresciute sostanzialmente in quel periodo di tempo. Forse lavorare su quel progetto ha contribuito ad esso. Progettarlo di nuovo come un'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 fare pratica con problemi di spedizione e consegna difettosa, penso che tu sia attualmente in una fase di sviluppo in cui lavorare i tuoi "muscoli del design" si dimostrerebbe fruttuoso.

Nel fare ciò, concentrati sul processo di progettazione e pianificazione e rifletti sulle tue cose esistenti e rifletti su ciò che stai capendo meglio.

Refactor. Refactor. Refactoring! Refactor !!!!

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

Non funzionerà. Se lo fai, la tua applicazione / gioco non sarà mai completata. Invece, prova a dedicare il tuo tempo al progetto in modo che alcune delle tue "attività" siano di refactoring del codice errato. Diciamo, ad esempio, che hai avuto un metodo orribile per salvare il gioco. Continua a lavorare sul gioco stesso, ma trova un po 'di tempo per riformattare (sostituire) quel metodo orribile. Cerca di mantenere piccoli i refactor e non dovrebbe essere un problema.

Quando arrivi a una parte importante dell'applicazione che ha bisogno di un refactor, lo stai facendo in modo sbagliato, sul serio. Rompi quel refactoring in parti più piccole. Cerca di dedicare sette ore alla scrittura del codice e al refactoring di un'ora.

Quando hai finito con il progetto e hai colpito il blocco delle funzionalità, puoi dedicare un po 'di tempo al refactoring. Per ora, finisci il gioco, ma prova ancora a riformattare alcuni. Questo è 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. Cioè, se le tue fondamenta sono buone (nella maggior parte dei casi un design di classe adeguato, un buon disaccoppiamento / coesione ecc., Solo alcune cattive scelte come i fili che hai citato), allora ottieni un 1.0 a ossa nude e poi refactoring come non c'è domani.

D'altra parte, se in realtà è solo un branco di brutti file di testo schiacciati che in qualche modo passano dal compilatore, senza struttura riconoscibile ecc. (In altre parole, un prototipo di apprendimento sul lavoro della prova di concetto), quindi preferirei eliminarlo e ricominciare.

Nella prossima versione, segui un approccio agile: imposta una sequenza temporale fissa ripetuta, ad esempio 2 settimane o qualsiasi cosa si adatti al tuo programma. All'inizio di ogni blocco (chiamiamolo uno sprint), fissati obiettivi raggiungibili in 2 settimane. Vai avanti e falli, fai del tuo meglio per farlo funzionare. Stabilisci i tuoi obiettivi in ​​modo che dopo ogni 2 settimane hai qualcosa che può essere mostrato a un amico, non solo un lavoro interno astratto. "Mischia" di Google e "obiettivo intelligente". Questo è tutto molto facile da fare, se sei solo, solo un pezzo di carta con alcuni punti elenco rapidamente annotati.

Se riesci a farlo, ricominciare da capo è buono. Se sai nel profondo che dopo aver ricominciato, probabilmente finirai dove sei ora, comunque, quindi mantieni il tuo codice e fallo funzionare.

Devi metterti nei panni dei datori di lavoro.

Per la maggior parte dei recruiter, saresti il ​​più prezioso se vai in questo modo: - Completalo con i test al 100% sul nuovo codice che scrivi. - Aggiungi test per il vecchio codice (progettato male). - Rifattorizzalo per ottenere ciò che volevi come design.

Fai tutto questo con un buon processo di versioning, rami e tag.

La riscrittura è spesso un'idea sexy, ma spesso è un'idea che hanno i nuovi arrivati ​​che è un po 'pericolosa nella vita reale. Dimostrare 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 però, ma poi trasformalo in un altro progetto.

Solo per aggiungere un po 'della mia esperienza passata nel mix. Lavoro a un progetto collaterale da oltre un anno, ogni volta che ho qualche minuto di riserva. Questo progetto è passato da un semplice banco di prova a una classe statica a un design sottile e orientato agli oggetti che è ora.

Durante tutte queste modifiche ho mantenuto la stessa funzionalità del codice, escludendo correzioni di bug e vantaggi in termini di prestazioni (deve essere il più veloce possibile). La stessa base di codice sebbene refactored sia rimasta la stessa e come tale l'ho migliorata enormemente senza dover riscrivere il codice da zero e perdere tempo.

Ciò ha significato che sono stato in grado di migliorare il codice a un ritmo più veloce di quanto avrei potuto fare prima. Significava anche che, mentre stavo andando, era più facile dire cosa doveva essere rimosso, cioè classi non necessarie, e cosa poteva rimanere più facile che riscrivere con la vecchia idea ancora nella mia mente.

Pertanto il mio consiglio sarebbe di riformattare il codice e passare da lì apportando miglioramenti, se necessario. Anche se ricorda che se decidi di riscrivere da zero, dovresti prendere le buone idee del vecchio progetto e guardarle attentamente per vedere dove sono imperfette. Vale a dire non solo copiare il vecchio codice nel nuovo progetto.

La risposta dipende da qualcosa che mi piace chiamare il "limite della complessità". Man mano che aggiungi sempre più a una base di codice, c'è la tendenza a diventare sempre più complessa e sempre meno organizzata. Ad un certo punto, colpirai un "limite di complessità", a quel punto i progressi in avanti diventano molto difficili. Invece di cercare di continuare a muoverti con la forza bruta, è meglio eseguire il backup, riorganizzare / riscrivere e quindi continuare ad andare avanti.

Quindi la tua base di codice è così grave che ti stai avvicinando a un limite di complessità? Se ritieni che lo sia, prenditi del tempo per ripulire 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 a rivedere il design esistente e ad aggiungere del tempo a nuove funzionalità.

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

Non so fino a che punto cose come deadlock e rilevatori di gare sono disponibili per C #, ma se esistono, possono essere utili per identificare quali problemi ci sono e per verificare che le tue correzioni stiano funzionando.

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

Se il tuo codice è modulare, dovresti riuscire a finire il resto del codice attorno ai componenti scritti male, quindi riscrivere i componenti scritti male senza influenzare il resto del codice.

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

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

Cosa hai fatto di sbagliato esattamente?

Se qualcosa è così male che sprecherai tonnellate di ore cercando di risolvere il problema, esponendo dati sensibili (password / carte di credito) o causando una cattiva vulnerabilità, quindi forse dovresti modificarlo, ma la maggior parte delle volte puoi prendi quello che hai, finiscilo e risolvi il problema in un secondo momento.

I programmatori adorano migliorare le proprie applicazioni, desiderando che siano "il meglio che possa essere", ma non è l'approccio corretto.

Se rilasci l'applicazione il prima possibile, anche se non è al 100%, i bug e tutti, allora ricevi FEEDBACK da altri, mentre hai il tempo di correggere i bug e altre cose per la versione 1.1. Altre persone saranno in grado di aiutarti a rendere l'applicazione molto migliore e potresti aver perso tempo a fare qualcosa che alla gente non sarebbe piaciuto.

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

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

Dipende da quanto è incasinato il tuo codice.

• Se hai fatto errori n00b reali che rendono il tuo codice eccessivamente complesso o dettagliato, allora consiglierei di riscrivere quelle parti.

• Se pensi di avere gravi bug che dovrai comunque correggere, allora scrivi alcuni unit test che possono verificare se hai corretto il bug (... dato che non puoi ancora avviare il programma). È meglio correggere i bug in anticipo, ed è sicuramente meglio correggere i bug mentre ricordi ancora cosa fa il codice.

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

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

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

Tuttavia, è possibile sfruttare il metodo scientifico qui, eseguendo un esperimento. Innanzitutto, concepisci un'ipotesi. Il mio sarebbe "probabilmente è il momento di riscrivere". Al fine di risparmiare tempo, ridurre il costo del fallimento e in qualche modo limitare la distorsione a priori, prima di eseguire qualsiasi altra programmazione, decidere un periodo di tempo ("time box"). Suggerirei forse 4 ore di orologio da parete. Decidi anche una metodologia per valutare l'ipotesi. Dato che la posta in gioco è bassa, suggerirei come metodologia, chiediti semplicemente: "Sono contento di averlo fatto?" Ora inizia l'esperimento. Dopo il tempo prescelto, qual è la valutazione dell'ipotesi? es. 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'è niente come provare 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 è tutt'altro che l'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 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 i suoi consigli, almeno ascolta. In futuro ci saranno più voci esterne e dovrai esercitarti ad ascoltare il tuo buon senso.
• Sospetto che con una riscrittura, hai maggiori probabilità di modulare maggiormente il tuo codice. Quando crei moduli, hai componenti più riutilizzabili e affidabili che puoi sfruttare per altri progetti. Potresti persino 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, allora potresti scegliere di finire qualcosa finendo un particolare sottomodulo. Potresti impostarlo come primo obiettivo, dopo l'esperimento di cui sopra. Finire non deve ancora significare finire il tuo progetto principale iniziale. Dopo aver completato un modulo, finisci un altro, ecc., Fino a quando non finisci di riscrivere l'intero ambito del progetto originale, se lo desideri.