1

As developers we are always eager to learn new things and better ourselves at what we do.

You've all had moments when you look at your old code and get that feeling:

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

Well, when it comes to long term projects that you're working on, what do you do when you look at your old code? You probably have learnt new techniques that you didn't use when you started the project. So you probably are very eager to refactor or restructure, or swap out modules in your project.

But when is the right time to do this, and how often do you do this? Also, there are risks involved if you do some major refactoring. There's also budget constraints so you may have the urge to make changes but your project manager won't give you the time to do so. How do people approach such situations?

Telastyn
  • 108,850
  • 29
  • 239
  • 365
Prem
  • 119
  • 2
  • When is the right time to refactor? Almost never. If your code is currently working, then refactoring will take valuable time and almost certainly introduce new bugs. – Simon B Aug 14 '14 at 14:10
  • 1
    Vote to close. Good question but in reality there's a spectrum of doing the 'right' thing meaning doing nothing to completely re-writing significant portions. What the 'right thing' to do will depend on too many factors to list here but include product, purpose, timeframe for use, mode of use, user base, types of users, length of proecjts, etc. etc – Michael Durrant Aug 14 '14 at 15:00
  • @SimonBarker - I cannot disagree strongly enough. Refactoring is likely to take time and introduce bugs, but how much more effort is spent and bugs introduced by shoddy code? – Telastyn Aug 14 '14 at 15:17
  • Not a duplicate. The question "Refactor or Concentrate on Completing App" asks about refactoring vs getting the project done. That is refactoring code before completion. This question asks about refactoring old code, supposedly working. – Florian F Aug 22 '14 at 11:36

2 Answers2

10

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs, with no new requirements and adequate performance - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
6

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

The right time is when the old and bad code is actually causing problems, or is becoming so difficult to maintain that the cost of not refactoring is greater than the cost of refactoring, which thankfully does not happen often (at least not in my experience).

Generally, if it ain't broke, don't fix it. Changing working code simply for the sake of making it "nicer" is risky.

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

Yes. If you change your code siginificantly, you must ensure that it works the same as before. Automated unit tests can help with this.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176