14

I've started a rather large 2D game engine project a few months ago, and I began noticing:

The code from the first one or two months is quite different to the more recent one:

  • The naming of variables feels a bit different
  • Some code style aspects are different
  • I'm sometimes wondering why I named some function that way, and can easily think of a better name
  • The code feels rather messy

  • There are parts where almost instantly a better way of doing it comes to my mind

  • The code seems as if its quality was significantly lower

However, at the time I wrote it, I was watching out to do everything right the same way as I do now.

Now, for my questions:

  • Is this a common situation, even in large commercial-style projects?

  • Should I consider investing (a lot of) time in refactoring and maybe even rewriting the affected code?

  • Is it normal that as a project grows and changes, large parts of code have to be refactored or rewritten from ground up? Is this bad?

Oktstrom
  • 283
  • 1
  • 2
  • 5
  • 1
    See also [“it works-don't touch it” and continues engineering](http://stackoverflow.com/questions/1275287). – ChrisW Feb 22 '11 at 19:19
  • Is this common? Yes Refactor? Only if you need to change the code or if it's completely unreadable. If someone constantly went back and refactored there would be no progress on new features. It's a necessary juggling game so use your best judgment. Is it normal? Yes Is it bad? Nope – Avilo Feb 22 '11 at 19:20
  • Looking back at my projects every year is progressively more embarrassing. It's a learning thing, but it does have diminishing returns (over a long period of time). Yes, you should go back and try to do everything the best it can be, but this is a very arguable point. – GManNickG Feb 22 '11 at 19:21
  • 1
    @GMan: I think that depends what kind of "best" we're talking about. The main benefit of good names, consistent style, and non-messiness is to make maintenance easier and quicker. Spending time on those things, in old code that works, likely defeats that purpose. It *is* additional maintenance work, and in another year when your naming and style conventions have developed you'll do it all again, perhaps without even glancing at the code in the interim. Of course if the code doesn't work, or if it could be much faster/cover more cases/half the size, I'd improve style while I'm in there. – Steve Jessop Feb 22 '11 at 19:33

6 Answers6

9

Is this a common situation, even in large commercial-style projects?

Yes.

Should I consider investing (a lot of) time in refactoring and maybe even rewriting the affected code?

You going to do that again tomorrow too?

No. Not unless you're actually working on the code you want to refactor.

Is it normal that as a project grows and changes, large parts of code have to be refactored or rewritten from ground up?

Yes.

Is this bad?

It would certainly be a lot easier if we where all perfect, yes.

Edward Strange
  • 40,307
  • 7
  • 73
  • 125
  • 1
    I disagree. Why not take the time to do things right? – GManNickG Feb 22 '11 at 19:20
  • 3
    @Gman: Because you'll spend way too much time getting it done and not enough time actually *finishing* the project. – Puppy Feb 22 '11 at 19:22
  • 1
    I agree with this. Don't go hunting for the somewhat lower quality code, but fix it up when you see it (e.g. because it needed to be changed to add a feature, or because you're having to debug through it) – Ben Voigt Feb 22 '11 at 19:22
  • @Dead: And...? I never understood this attitude. Imagine all the broken software you use today. Now imagine if they *had* spent the time getting it right instead of "finishing" the project. (With a pretty broken definition of finish!) – GManNickG Feb 22 '11 at 19:26
  • 2
    @GMan: There would be no software for me to use, because they would still be writing all of it. Badly-written or imperfect code is *not* necessarily buggy or broken. – Puppy Feb 22 '11 at 19:30
  • @GMan: Working (including passing all tests) code that is sloppy != broken code. – Fred Nurk Feb 22 '11 at 19:31
  • @GMan: Consider that if they hadn't finished the project, perhaps you wouldn't have the "broken" software to use. :-) – Bo Persson Feb 22 '11 at 19:35
  • 1
    @GMan: question doesn't seem to be about functionality. I don't give a stuff whether Diablo 3's source code uses consistent whitespace throughout, so that when they read through it they don't think to themselves, "this feels rather messy". I want Blizzard to do whatever will get it passing the tests and on my doormat - if poor style is impeding that they they should fix it, otherwise they should leave it. Existing products with style inconsistencies in the source are better than non-existant products with beautiful style. If it's actually broken, that's a completely different question. – Steve Jessop Feb 22 '11 at 19:36
  • 1
    @Dead @Bo: Over-exaggerations. You really think if we went back and fixed some old code no product would ever be released? And again I'll even say: so what? I'd rather wait an extra year or two for a product that's clean and maintainable then something that crashes or is impossible to fix and improve. So your argument, personally, has no bearing on me. @Fred: Assuming your tests are absolutely extensive in every case, which they aren't. Sloppy code == more difficult than necessary to maintain and easily breakable. – GManNickG Feb 22 '11 at 19:39
  • @Steve @Dead @Bo @Fred: Sorry, I must be misunderstanding the question, then. In my mind, the OP was talking about the code functionality itself, not just formatting. – GManNickG Feb 22 '11 at 19:41
  • 1
    @GMan, I used to think that you should improve code whenever possible. Now I am not so clear on that position. There are clear differences between refactoring for the sake of it (nothing is wrong in the code) and improving the product (make it more robust, stable, correct bugs). Nowadays I just note what parts are good candidates for refactor, and even give it a quick thought, then move on. If I need to extend or correct parts of the code there, then refactor, improve. While @Dead and @Bo are exaggerations on one end, your position seems as exaggerated on the opposite side. – David Rodríguez - dribeas Feb 22 '11 at 19:44
  • @GMan: I suspect we're just arguing different absolutes. We aren't all saying that nobody should ever fix old code - if it crashes, it needs fixing. You probably aren't saying that "some code style aspects are a bit different" should in all cases hold the product up from shipping indefinitely. Question deals in generalities, so it's inevitable people will take different interpretations. – Steve Jessop Feb 22 '11 at 19:45
  • 1
    You have to consider that there is a cost associated with each line of code that is changed (time, money), as well as a cost of not doing it (time, money if you need to work on that later). I believe in investing on refactoring when you need to touch that code, prior to any other maintenance, but I also believe that it is more important to invest that time in tests (automated) to ensure that it is correct (even if ugly), and that if at some point I refactor, regressions will be caought early – David Rodríguez - dribeas Feb 22 '11 at 19:48
  • 1
    Let's look at the past for a lesson on the present: http://www.jwz.org/doc/worse-is-better.html – Paul Nathan Feb 22 '11 at 19:52
  • If development firms spent all their time rewriting functional code that doesn't represent the epitome of excellent design then you'd be buying the "less-than-perfect but works most of the time" version from their competitors because nothing would ever actually get finished. There's actually very few reasons to rewrite something and before you actually DO, you should be pretty much faced with all of those reasons. – Edward Strange Feb 22 '11 at 20:13
4

Yes, this is a common pattern with my projects as well. ABR: Always Be Refactoring. When I feel a new pattern emerge, I try to update older code to match it as well. As a project grows, your experience working in the problem domain influences your style and it's a good idea to be updating older code to match it as well.

As a corollary, if your first project commit is still in your project unchanged a few months later, something is going wrong. I view development as an exploratory practice, and a big part of that is updating old code and ironing out your style. No one knows their final design/API before they start coding. Find any large open source project and walk up its commit history; it happens everywhere.

If you've been working on a drawing or a painting for a while, your style develops sophistication the longer you do it. Also, your first layer or first few sketches are rarely the inked lines that appear in the final result.

yan
  • 20,644
  • 3
  • 38
  • 48
  • This is only true if you were inexperienced when starting the project. I suspect most painters won't have a significant learning experience or change in style during the course of a single canvas, unless they're specifically trying out a new technique. – Ben Voigt Feb 22 '11 at 19:26
  • No, but their initial pencil sketches to develop the use of space will not show through. – yan Feb 22 '11 at 19:27
  • "Always Be Refactoring" - sometimes I wonder whether English-Prime might have its benefits after all. – Steve Jessop Feb 22 '11 at 19:52
3

A big takeaway lesson from this experience: you're getting better. Or, at least, you're changing. Certainly, from today's perspective, the code you're writing today looks better to you. If the code you wrote back then looks bad today - make it look better. Your responsibility today is not just the code you write today; it is the entire code base. So make it right - and be glad you're getting better.

Carl Manaster
  • 39,912
  • 17
  • 102
  • 155
3

Yes, this happens. I would even say that it's expected and typical as you delve further into your solution.

Only update your code when you go back and touch it. Don't forget to write unit tests before adjusting it.

It's very tempting to rewrite bad code for no reason, particularly when you don't have a deadline looming. You can easily get stuck in a loop that way.

Remember, shipping is a feature.

Paul Nathan
  • 39,638
  • 28
  • 112
  • 212
2

Is this a common situation, even in large commercial-style projects?

I must confess here that my belief is that if you design first and code later you can avoid many issues. So I would say here it depends. If one starts with a good design has some company standards in place to ensure the code based on the design follows the same important rules no matter who wrote it then at least you have a chance to avoid such situations. However I am not sure if this is always the case :-).

Should I consider investing (a lot of) time in re-factoring and maybe even rewriting the affected code?

Making things better can never hurt :-).

Is it normal that as a project grows and changes, large parts of code have to be re-factored or rewritten from ground up? Is this bad?

I would say yes and re-factoring should be normally considered to be a good thing when the resulting code is better than the old one. The world never stays the same and even if something was appropriate at some point in time it just may be that it doesn't stand up to the needs of today. So I would say it would be bad if the company you work for would say to you: "you cannot re-factor this code. It's holy". Change (if it is for the better) is always good.

ds27680
  • 1,993
  • 10
  • 11
1

Fred Brooks wrote, "Build one to throw away, you will anyway." While it's not as true as it used to be, it is far from uncommon to not really understand the problem until you start working on it.

quillbreaker
  • 6,119
  • 3
  • 29
  • 47