Hello people,
I have read a few articles over the years on using legacy code, but this one made me think quite differently, so I thought I’d share it. Admittedly it’s quite old (from 2000), but I feel the info is still relevant. I hope you enjoy it as much as I did. Here it is:
Click here to read the article
Please comment. Thanks.
Best regards, Alf.
I nearly fully agree.
He is right in every aspect.
There is however one major exception: If you know you have to maintain the code for several years, and you are not yet released (aka no marketshare/publicity to be lost from having no product for several years) then do a rewrite if necessary.
Yeah, for released products… don’t rewrite.
If you haven’t released yet then sometimes a rewrite is the thing that will keep you out of maintenance hell when you finally do release. But you have to be really wary of the tendency to want to rewrite everything.
Mythruna is 3 years into its rewrite and I still don’t have a function game let alone all of the features of the old one (*). It was still a good idea for me because the requirements had evolved beyond what the old one would easily support… if I’d tried to modify it to meet them, I would still be in the same boat now. In fact, in many cases I cut and pasted entire ‘legacy’ parts over as the new rewrite was mostly an architecture shift.
But beware: we often think “it will go faster this time” and that is almost never the case. The rewrite almost always takes longer than the time it took to write the first up to that point.
(*) to be fair re: the 3 years, I also went from being able to spend 30 hours a week in development to being able to only spend 8 on a good week… in fact part of the rewrite was to make sure it was easier to make surgical changes so that I could still work on the game at all.
I would say that it depends a lot what you rewrite, how you design things and what the code look like and for how long the code should live. Refactoring is a bit easier today than it was in 2000, so you wouldn’t rewrite something if it just had a couple of bad variable or method names, and you don’t need to fix your Emacs macros either, modern IDE:s will do that for you and also extracting methods that look similar, etc.
Refactoring works quite good if you have a lot of unit tests that you can reply on, preferably JUnit together with Mockito or something similar. I know that many here thinks that unit tests are overrated and waste of time, but you can save a lot of time if you can test a small bit of code instead of starting your game and doing manual tests and guess your way forward and hopefully you won’t break your code in the future either.
There are cases when code is written by beginners or poor programmers that write 5000 lines of codes in a single file or even a method and is nesting 10 layers of if statements, etc, and it might be easier to just rewrite everything from scratch if you have a well defined API or interface. I recommend to see components as black boxes that you should be able to replace without the need to redesign the complete system. This is however much more important in an enterprise environment than for a small game project at home. We (at my day job) have more than 300 projects that communicate with each other using well defined API:s, even though they are using an properitary RPC-based protocol based on Java’s Externalizable.
It happens that we need to redesign a component from scratch now and then, sometimes because there are better ways to do things now than it was 15 years ago when the component originally was written (Java 1.3, yay), or that servers today are multi core and not single core as they were 15 years ago, or that old API:s that you are using aren’t maintained any more, and then we have luxury problems; One example is that we were sending 100000 SMS during 2005 and we passed 1 billion SMS during 2015 and you usually don’t plan ahead that much increase in every scenario when you’re writing and designing code for performance and redundancy for the first time.
I think you should think at least one or two times before you decide to rewrite everything, but rewriting small parts of code is just maintenance to me. Remember that no one usually pay you for rewrite all code so there should be a good reason for it (if you expect to get money from it at least).
Rewriting a legacy codebase from scratch is almost never a good idea, although that’s kind of what jME3 is (in comparison to jME2).
When writing jME3, I realized that having a clear break in the API is going to be very important to allow certain features to be added, but I didn’t want to do all the work from scratch. Many parts of jME3 are actualy re-used verbatim from jME2. For example, the math, bounding, and binary export packages were nearly completely unchanged from jME2 to jME3. Additionally, many concepts / ideas were re-used as well (although not the code itself), for example, the scene graph, application structure, app states (which are based on game states), etc.