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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With