next »

[Archendrus]

Refactoring can be a trap, one that I learned about the hard way...several times. So personally I don't think it's worth breaking your stride unless your code needs it because of performance issues, or it's code that your going to reuse in many projects.  If it's the second case, I wouldn't start the refactoring process until after the current project is finished.  

A third, more common (for me at least), and harder to plan for case: When your code has become too brittle to work with anymore, and you'd spend less time refactoring than you would getting the code to do what you want as-is. Let a system go without refactoring for long enough, and it tends to harden to the point where it becomes impossible to change anything. There's of course no way to look into the future and see how much time you'll save from refactoring, so you just have to trust your intuition to know when it's time to do it.

True!  Something like that has to taken on a case-by-case basis.  Tough to judge what the speedier solution is.  I suppose that sort of thing comes with experience. 
Though, I've been learning the hard way that a little planning and code and code design can help one avoid getting stuck in that situation.  How the saying go? Weeks of coding can save you hours of planning? lol

[Garthy]

IF
- The current code is causing me problems, or will cause me problems, or may cause future concerns; AND
- After brief consideration I believe that the time spent refactoring will cause the total time to project completion to be reduced or quality to be proportionately increased; AND
- After spending time coming up with a mock design, it is clearly superior to the current implementation, and will save time or improve quality overall; AND
- The existing code is actively annoying me right now; AND
- I would rather solve the underlying problem than work with the existing code any longer

OR refactoring would improve the code quality AND can be done in under a couple of hours

THEN I refactor.

Rough guide.

[Richard Kain]

Yeah, refactoring is a constant temptation. Eventually you have to ask yourself, is it worth it?

I'm refactoring my current project for the third time now. The first time I was using an external library, and din't like having the dependency. The second time I used a native solution, but didn't like a lot of the work-arounds I had employ. I'm thinking this third time is going to be the charm. The solution I'm looking at seems performance-friendly, will be easy to hide behind the scenes, and will work for everything I need to do with it.

[nereke]

As others before me have said, systems are worth refactoring. For instance if you give the player the ability to carry and push blocks as a core mechanic then you want to make sure that it's clean. That way you aren't constantly struggling with strange bugs and confusion when implementing different scenarios further in.

[Muz]

Normally I do the refactoring thing in pauses between projects, like after a major version release and not being in the mood to add other features. Yeah, you shouldn't let it break your stride. But it should be done in between strides, so that you're not forced to refactor later while you're getting good momentum going along.

[mychii]

Usually I make notes on my previous projects (troubleshooting) and apply it for the next program/version iteration. Everything depends on the first architecture you build for the game. This is also works if you have to create the big next version, so you can take time as long as you could have to do your 'great refactoring', while also delivering new game contents in return (say on version change to 3.0 or 4.0, etc).

For example, if you make a game engine, you create it as great you could, as flexible and as loose-coupling as you could, etc2. But when it comes to the game development itself, you really have to let yourself messing the code up (after separating it from game engine codes of course). Why? Because you have to proof your concept, is your game engine architecture good enough to be messed up with when being used? When it is messed up, will the game programmers still able to twist the game if there are changes on the features as quick as they could?

The point is, you create a system so great that even if you or your team mess it up when they use it, you and your other developers can still have the flexibility to understand the code and make changes no matter how big the project is. This way, you don't even need to think of refactoring at all unless you have to integrate a new, super big system, like from single-player to multiplayer to massively multiplayer game.

You don't refactor your game logic, you refactor the system. That's why I think usually the system is done by senior/lead programmers, so that even if junior developers mess it up when using the system to create the game logic, they're still in 'safe zone' of just messing the game code instead of the system.

The system could be the game engine (which includes a lot of systems inside), AI system, inventory system, timeline, etc2.

[Chris Koźmik]

My philosophy is that "refactoring is bad in general, but there are several valid exceptions" or "do not refactor unless there is a very good reason" or "if in doubt do not do it".

[Moczan]

For personal projects I've setup a recurring, weekly task of 'maintaining codebase'. It usually means documenting last changes, but also refactoring small bits of code that were rushed. I try to keep my codebase as clean as possible to avoid huge refactor tasks that would take days or weeks.

[saluk]

Writing code and editing code are two different cognitive functions. I'm most productive when I am doing that task which most suits my current cognitive state. If I am having trouble thinking of what to add next and not feeling very creative, sometimes taking some time to clean things up that bug me free my brain to focus on new things. Similarly, going to crazy with a refactor can be draining at times, and in those moments its better to add a crazy new feature that's not too attached to whatever mess in the code is giving me a headache.

[bateleur]

I refactor a lot when I'm coding unimportant things and very seldom for work stuff. The reason is simple: refactoring almost always makes your code better, but it almost never saves time.

[heisenbergman]

oh hey, this is my first post here on tigsource

I've just recently started learning video game programming using Java and have been working on a learning project for the past several weeks.

Last weekend, I got to the point of a "logical break" having just completed a particular functionality, and noticed that I had too much repeated code and similar functions that I felt I needed to refactor. This question also crossed my mind - to refactor or not to refactor - but I eventually came to the conclusion that nipping sloppy code in the bud and making the structure of my game more sound was the way to go... so I refactorred.

Lo and behold... I loved cleaning up the code I had some classes for objects I was using that had so many similar functions, so I just created parent classes for them and extended those classes... put repepetitive logic into methods, etc, etc, etc... in the end it felt like looking at a clean house after an afternoon of housekeeping.

It was fun. I plan to do it periodically as I progress with my game

[colinshark]

Refactoring IS expensive. First, I look at the prospective lifetime of the code.

If it's a couple days or weeks, I write trash code.

If it's a couple years, I spend a little more time, and then refactor only when necessary.

If it could be MANY years or decades (professional setting), I do more up-front design and clean the code base most aggressively.

It all depends on what you are doing. When the cruft is getting too big, and you can barely go on without dozens of copy-pastes, you know it's time to refactor.

[Walt Destler]

I'm going to go out on a limb here and say that, unless you're close to a hard deadline, refactoring is essentially always a good idea. By "refactor" I mean basically "make simpler".

Here are my reasons:

• Refactoring code to make it simpler makes future bugs far easier track down and fix. Simpler code is easier to understand and grock, so it's quicker to fix. If you've ever spent hours or even days trying to track down a hard bug, it was probably because the codebase was difficult to understand.
• Simplifying now is better than fixing later. If you have janky systems, then there will come a time when they will break, and it's much cheaper to clean them up now than to fix them later.
• Simplifying keeps your game expandable and your design flexible. If you have cruddy systems then you will be resistant to making design changes that require changes to those systems. Even if you think you're willing to rewrite dirty code to accommodate new ideas, dirty code subconsciously limits the design ideas that you will come up with and consider.
• Refactoring makes refactoring cheaper. Refactoring is most costly when the code you want to clean up interacts with other complicated systems. If those other systems were simpler (because you refactored them earlier), then your own refactor will be that much easier.
• And this is the most important reason: Refactoring systems is the quickest way to become a better programmer. It's much more educational to refactor now than it is to take a few notes and say "I'll do it better next time." You'll learn a lot more by putting simpler code into working production instead of just theorizing about how you'll do it in the future. The best practices you learn by refactoring will applied to all your future projects, and you'll have less need to refactor in the future, because it will be better code from the get-go. Becoming a better programmer will save you immeasurable time compared to the time you actually spent refactoring. Consider that, even if refactoring won't make your product better, it will make *you* better.

The key to refactoring is to do it *constantly*. If you see a little bit a code that could use some clean up, take the 5 minutes and do it. If there's a larger system that's become unwieldy, buckle down and re-structure it before you write another single line of code that touches it. By constantly refactoring as-you-go, no refactor becomes too big to consider, and the cumulative advantages of all those little refactors multiply up. While an individual refactor may add a small amount to your development time, a simpler codebase will decrease all future development by a percentage, and it won't take long for that percentage to become greater than the initial refactor cost. The advantages of refactoring for both your current and future projects are exponential, while the costs are merely additive.