C++: Code from the beginning of my project of significantly lesser quality [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I've started a rather large 2D game engine project a few months ago, and I began noticing:开发者_Go百科

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?

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.

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.

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.

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.

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.

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.