Dopo aver scritto il codice, perché sento che "avrei scritto meglio" dopo un po 'di tempo? [chiuso]

Question

Dopo aver scritto il codice, perché sento che "avrei scritto meglio" dopo un po 'di tempo? [chiuso]

#1 da (17 voti)
#2 da (3 voti)
#3 da (2 voti)
#4 da (2 voti)
#5 da (2 voti)
#6 da (2 voti)
#7 da (1 voti)

12

Ho lavorato al mio progetto di hobby in C ++ per più di 2 anni. Ogni volta che scrivo un modulo / funzione, lo codifico con molto pensiero. 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);

Qui 'X' è qualsiasi modulo (sia piccolo / grande / medio). Sto osservando che, questo accade non importa quanto sforzo ho messo durante la codifica. Quindi per lo più, mi astengo dal vedere un codice funzionante. :)

Questo è un sentimento comune a molte persone? Questo fenomeno è specifico della lingua? (Perché in C ++ si può scrivere la stessa cosa in modi diversi).

Che cosa dovrei fare se ricevo questo re-factoring sentimento per un codice di produzione del mondo reale, dove cambiare il codice di lavoro non mi farà guadagnare molti elogi ma piuttosto potrebbe invitare problemi se fallisce .

self-improvement refactoring c++ coding

posta iammilind 22.01.2012 - 12:40

fonte

7 risposte

3

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 tuo codice è completamente testato, puoi ridimensionare il tuo codice in tutta sicurezza.

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

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

In sintesi, è una sensazione comune nella mia esperienza, ma non è negativa.


risposta data 22.01.2012 - 21:32
fonte

2

Ogni modulo / funzione nasce e si evolve in un mondo di priorità. Una volta che è sufficiente per servire gli obiettivi dei mondi esterni, spesso viene lasciato a ristagnare. Alla fine è tutto impalcatura in servizio per lo scopo più alto. Sì, abbiamo bisogno di essere ossessivi riguardo al codice, e sì, questo può farci anche stagnare. Forse sarebbe una buona mossa per te spostare l'attenzione dal codice stesso un po ', e riflettere più sui processi che accadono dentro di te, il produttore del codice.


risposta data 22.01.2012 - 13:44
fonte

2

Is this a common feeling for many people? Is this language specific phenomena?

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

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


risposta data 22.01.2012 - 14:06
fonte

2

Ho sempre pensato che una persona prendesse una lezione di matematica per rafforzare le proprie abilità nella lezione precedente. L'algebra sembrava dura, finché non hai preso Algebra II; Poi le abilità che hai imparato in Algebra sono diventate utili. È la stessa cosa in programmazione, scrittura, lavorazione del legno o qualsiasi altra cosa.

Durante un corso di programmazione hai imparato a conoscere If-then-else, che ha fatto un sacco di cose fino a quando non hai imparato a conoscere le opzioni. Quando stai imparando qualcosa di nuovo passi attraverso questa progressione, lo fanno tutti.


risposta data 22.01.2012 - 16:55
fonte

2

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 il tuo stile di conoscenza e codifica è migliorato nel corso degli anni.

Per quanto riguarda la modifica del codice di produzione, questo è un grande no-no a meno che non si siano individuati bug ovvi. Non solo perché potrebbe essere una perdita di tempo, ma soprattutto perché la maggior parte dei bug software creati sono del tipo che viene introdotto quando vengono apportate modifiche ai programmi rilasciati. Statisticamente è probabile che introdurrà bug imprevisti. Se non è rotto, non aggiustarlo.


risposta data 23.01.2012 - 16:13
fonte

1

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

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

Hai ancora lo stesso livello di competenza.

Il tuo codice è già perfetto (improbabile).

risposta data 01.02.2012 - 23:36
fonte

Leggi altre domande sui tag self-improvement refactoring c++ coding

Come diventare un ingegnere del software? [duplicare] Dovremmo rinominare i metodi sovraccaricati?

score 17 · Accepted Answer

Questo fenomeno è molto comune e non specifico per i programmatori. Ogni volta che svolgi un'attività intellettuale, noterai dozzine di punti in cui potresti migliorare: dopo hai ottenuto una certa distanza. Chiedi a qualsiasi saggio (uomo) che abbia mai scritto una tesi e ti diranno una cosa: "Non guardarla, troverà un errore a prima vista".

Ci sono fondamentalmente due cose da evitare per il ciclo di refactoring:

Durante la scrittura e la progettazione, cerca di ottenere una prospettiva lontana il prima possibile. Chiedi a un collega di guardare il tuo design / codice. Guarda di nuovo dopo un fine settimana. Guardalo quando sei ubriaco o alto (ma fai attenzione: non cambiare nulla fino a quando non è sobrio).

vivi con l'imperfezione. Se è semplicemente non bello, ma funziona bene (leggi: fa un buon lavoro nel soddisfare tutti i requisiti, inclusa l'estensibilità e la leggibilità), lascialo in piedi e accontentati del buon lavoro che hai svolto, senza sforzarti per il lavoro perfetto.