Dopo aver scritto il codice, perché sento che "avrei scritto meglio" dopo qualche tempo? [chiuso]

Ho lavorato al mio progetto di hobby in C ++ per più di 2 anni. Ogni volta che scrivo un modulo / funzione, lo codice con molta riflessione. Ora vedi il problema,

do {
  --> write the code in module 'X' and test it
  --> ... forget for sometime ...
  --> revisit the same piece of code (due to some requirement)
  --> feel that "This isn't written nicely; could have been better"
} while(true);

Ecco 'X'qualsiasi modulo (sia esso piccolo / grande / medio). Lo sto osservando, questo accade indipendentemente dallo sforzo che ho fatto durante la codifica. Quindi, soprattutto, mi trattengo dal vedere un codice funzionante. :)

È un sentimento comune per molte persone? Sono fenomeni specifici di questa lingua? (Perché in C ++ si può scrivere la stessa cosa in modi diversi).

Cosa dovrei fare, se provo questa sensazione di re-factoring per un codice di produzione del mondo reale, in cui la modifica del codice di lavoro non mi farà guadagnare molti riconoscimenti, ma potrebbe anche invocare problemi se fallisce.

Questo fenomeno è molto comune e non specifico per i programmatori. Ogni volta che esegui un compito intellettuale, noterai dozzine di luoghi in cui potresti essere migliorato - dopo aver ottenuto una certa distanza. Chiedete a qualsiasi uomo saggio (wo-) che abbia mai scritto una tesi, e vi diranno una cosa: "Non guardare Puoi si trova un errore sul primo sguardo."

Esistono sostanzialmente due cose per evitare il ciclo di refactoring:

1. Durante la scrittura e la progettazione, cerca di ottenere la prospettiva distante il più presto possibile. Dai a un collega il tuo design / codice. Guarda di nuovo dopo un fine settimana. Guardalo quando sei ubriaco o alto (ma attenzione: non cambiare nulla fino a quando non è sobrio).
2. Vivi con imperfezione. Se semplicemente non è carino, ma funziona bene (leggi: fa un buon lavoro nel soddisfare tutti i requisiti, inclusi estensibilità e leggibilità), lascialo stare e accontentati del buon lavoro che hai fatto, non lottare per il lavoro perfetto.

Il refactoring continuo è la strada da percorrere. La modifica del codice di lavoro non causerebbe problemi e dovrebbe essere incoraggiata se eseguita correttamente. Se il codice è completamente testato dall'unità, è possibile ricodificare il codice con sicurezza.

L'unica cosa che puoi prevedere sul codice di produzione del mondo reale è che cambierà. Non provare a indovinare come cambierà, quali nuove tecniche imparerai domani. In breve, non provare a rendere il tuo codice "perfetto". Renderlo il meglio possibile con le tue conoscenze attuali. Inoltre, assicurati che il tuo codice sia accuratamente testato ed estensibile.

Passo il 20% -30% del mio tempo a refactoring del codice esistente. Lavoro in un'azienda tecnologica e il "management" non si è mai lamentato della modifica del codice esistente. Tuttavia, mi rendo conto che questo può essere un problema in alcune aziende. Martin Fowler ha anche una sezione su di esso nel suo libro di refactoring .

In sintesi, è un sentimento comune nella mia esperienza, ma non è negativo.

Ogni modulo / funzione nasce e si evolve in un mondo di priorità. Una volta che è sufficiente a servire gli obiettivi del mondo esterno, spesso viene lasciato ristagnare. In definitiva, sono tutte le impalcature in servizio per lo scopo più elevato. Sì, dobbiamo essere ossessivi riguardo al codice e sì, ciò può causare anche una stagnazione. Forse sarebbe una buona mossa per te spostare un po 'la tua attenzione lontano dal codice stesso e meditare di più sui processi che avvengono dentro di te, il produttore del codice.

È un sentimento comune per molte persone? Sono fenomeni specifici di questa lingua?

Ciò significa che stai ampliando le tue conoscenze e opinioni.

Se non hai compiti con priorità più alta, dovresti sempre tornare indietro e migliorare il tuo codice.

Ho sempre pensato che una persona seguisse una lezione di matematica per rafforzare le proprie abilità nella lezione precedente. Algebra sembrava difficile, fino a quando non hai preso Algebra II; Quindi le abilità apprese in Algebra sono diventate utili. È la stessa cosa nella programmazione, nella scrittura, nella lavorazione del legno o in qualsiasi altra cosa.

Durante un corso di programmazione hai appreso If-then-else, che ha fatto molte cose fino a quando non hai appreso gli switch. Quando stai imparando qualcosa di nuovo, attraversi questa progressione, lo fanno tutti.

Ho la stessa sensazione ogni volta che leggo la maggior parte del codice scritto da me stesso in passato. Questa è una buona cosa, significa che la tua conoscenza e il tuo stile di codifica sono migliorati nel corso degli anni.

Per quanto riguarda la modifica del codice di produzione funzionante, questo è un grande no-no a meno che tu non abbia individuato bug evidenti. Non solo perché potrebbe essere una perdita di tempo, ma soprattutto perché la stragrande maggioranza dei bug del software creati sono del tipo introdotto quando vengono apportate modifiche ai programmi rilasciati. Statisticamente è probabile che si introducano bug imprevisti. Se non è rotto, non ripararlo.

Sviluppare un'applicazione significa migliorarla e migliorarla; questo è un processo continuo, quindi durante la programmazione acquisisci più esperienza e conoscenza. Significa anche che stai sviluppando, quindi quando guardi indietro al tuo vecchio codice potresti scoprire che può essere migliorato.

Se non hai questa sensazione, significa una delle due cose:

1. Sei ancora allo stesso livello di abilità.
2. Il tuo codice è già perfetto (improbabile).