Quanto spesso ti rifattori o ristrutturi il tuo codice in progetti a lungo termine? [duplicare]

Question

Quanto spesso ti rifattori o ristrutturi il tuo codice in progetti a lungo termine? [duplicare]

#1 da (6 voti)
#2 da (4 voti)

0

Come sviluppatori siamo sempre desiderosi di imparare nuove cose e migliorare noi stessi in quello che facciamo.

Hai avuto tutti momenti in cui guardavi il tuo vecchio codice e provavi quella sensazione:

"WTH, I can't believe I used to write code like this"

Bene, quando si tratta di progetti a lungo termine su cui stai lavorando, che cosa fai quando guardi il tuo vecchio codice? Probabilmente hai imparato nuove tecniche che non hai usato quando hai iniziato il progetto. Quindi probabilmente sei molto desideroso di refactoring o ristrutturazione, o di scambiare moduli nel tuo progetto.

Ma quando è il momento giusto per farlo, e quanto spesso lo fai? Inoltre, ci sono dei rischi se si fa qualche importante refactoring. Esistono anche vincoli di budget, quindi potresti avere l'esigenza di apportare modifiche, ma il tuo project manager non ti darà il tempo di farlo. In che modo le persone si avvicinano a tali situazioni?

design refactoring architecture

posta Prem 14.08.2014 - 15:19

fonte

2 risposte

Leggi altre domande sui tag design refactoring architecture

Informazioni insufficienti in Bug / Ticket [duplicate] State dichiarando variabili STL in una definizione di classe troppo rivelatrice?

score 6 · Answer 1

what do you do when you look at your old code

Quando guardo quel codice e il codice funziona in produzione, senza errori, non faccio nulla. Mai!

Quando devo mantenere o evolvere quel codice, a causa di bug o nuovi requisiti, seguo il regola boy scout : lascia il codice sempre in uno stato migliore rispetto a quello in cui era prima.

La parte (a volte) difficile è la seguente: decidere quanto dovrebbe essere applicato il refactoring, quanto deve essere grande l'ambito del refactoring e quanto è sufficiente. Per ottenere questo è giusto ciò che fa la differenza tra un programmatore inesperto e un esperto. Non approfondirò questo aspetto qui, dato che ci sono già molti post e articoli sul web in cui questo argomento è stato discusso in dettaglio, vedi per esempio qui:

score 4 · Answer 2

But when is the right time to do this, and how often do you do this?

Il momento giusto è quando il codice vecchio e cattivo è in realtà che causa problemi, o sta diventando così difficile da sostenere che il costo di non il refactoring è superiore al costo del refactoring, che fortunatamente non accade spesso (almeno non nella mia esperienza).

Generalmente, se non è rotto, non aggiustarlo. Cambiare il codice di lavoro semplicemente per renderlo "più bello" è rischioso.

Also, there are risks involved if you do some major refactoring?

Sì. Se cambi il tuo codice in modo originale, devi assicurarti che funzioni come prima. I test unitari automatizzati possono aiutare in questo.