Pinderkent

Everyone faced with a large and practical software system knows that there are parts of their system that could be vastly improved. For some projects, we get to the point where the cost and risk of making even minor changes far outweighs the benefits that such changes will bring. So whenever possible, it's important to avoid getting to this point. This is where code refactoring comes in.

Today I was reading an article from somebody who is in just that sort of a situation. He is trying to decide how and when to refactor a particular Web site's JavaScript code. I think the answers to those questions are simple. You have to start refactoring the moment you start implementing the software, and you have to continually refactor it.

Code refactoring isn't something that you should just do every so often, when the situation gets really bad. That sort of refactoring, while possible and often done, comes with a higher degree of risk. It's a much better idea to make numerous small improvements, rather than several large rewrites of critical code. Small steps come with less risk. Likewise, the smaller scale allows for changes to be isolated in a way that allows for more effective debugging. And depending on the software's architecture, smaller changes may very well be easier to deploy.

One company I consulted at had a day set aside each week for refactoring the previous four days' work. While initially developing the code, they began to see where they were making mistakes and doing things wrong. By the fifth day, they were usually in a position to rectify these mistakes. This resulted in one of the cleanest codebases I've seen. By continually refactoring their applications, they just never got to the point where development became difficult or awkward.

Again, I must stress, it is ideal to refactor continually. If a development team can work it into their development philosophy and routine, many problems will be prevented outright, with others being caught and rectified very early on. This keeps the team's code clean, their level of risk low, and ideally results in a high-quality software product.