I am about to do a code rewrite, but I'm not sure how an expert programmer does it. I would like to follow any sort of conventions to rewriting codes, if there exists any, and hopefully know how to do such tasks with confidence. It's not lanuage-specific, I'm just asking generally.
So, I put up a poll so as to narrow down some of the actions done to do a rewrite. Thanks for polling.
Update: There's a follow-up. link.
Poll: There's a big piece of code in need of a rewrite, do you create a new file and work from there, or refactor old code in old file?
I don't know of any actual conventions to rewriting code as rewriting is a situation you want to avoid in most of the cases, unless you're actually doing a general update of an application.
Personally I try not to break compatibility with the earlier version of the system when rewriting larges systems. An actual rewrite for me mostly starts out on paper by fleshing out what the system is supposed to do and how it achieves its goal right now. Then I flesh out the new approach I want to use in detail so the actual implementation becomes quite trivial. Depending on the system I either create a separate branch of the project where I completely replace the old system with the new one, or I create 2 parallel code paths with both the old and the new system in place (if possible).
When that's done you can start adapting the rest of the project to this system if needed. Once the new system has been properly tested you can get rid of the old one.
This is for larger complex systems of course, if it's a small rewrite I would just do it in place providing you have backups of the old code so you can revert to that if something goes wrong.
Personally I try not to break compatibility with the earlier version of the system when rewriting larges systems. An actual rewrite for me mostly starts out on paper by fleshing out what the system is supposed to do and how it achieves its goal right now. Then I flesh out the new approach I want to use in detail so the actual implementation becomes quite trivial. Depending on the system I either create a separate branch of the project where I completely replace the old system with the new one, or I create 2 parallel code paths with both the old and the new system in place (if possible).
When that's done you can start adapting the rest of the project to this system if needed. Once the new system has been properly tested you can get rid of the old one.
This is for larger complex systems of course, if it's a small rewrite I would just do it in place providing you have backups of the old code so you can revert to that if something goes wrong.
From my very limited experience i can say that if a piece of code is a mess, you should just rewrite it or else the new one will still have a messy large scale structure.
Either way is fine, it just depends on how you go about the re-factoring Sometimes it is nice to create a new file so you can keep the old one open for reference. If you decide to just rewrite the file without creating a new one just make sure you have a backup (if you are using a version control system you are good to go).
I am about to do a code rewrite, but I'm not sure how an expert programmer does it. I would like to follow any sort of conventions to rewriting codes, if there exists any, and hopefully know how to do such tasks with confidence. It's not lanuage-specific, I'm just asking generally.
So, I put up a poll so as to narrow down some of the actions done to do a rewrite. Thanks for polling.
1. Why am I rewriting the code? If the software works and there are no changes needed, then leave it alone.
2. If I have to make a minor tweak to the software, then I'll try to find it in the existing code base (costs less time).
3. If I have to make major changes to the code, then I treat it as a new project/version and go through the software development lifecycle. If the code base is poorly formatted, poorly commented, poorly architected, then I'm very tempted to just start from scratch. However, it really depends on my personal assessment of what would take the least amount of time.
4. If I have to rewrite the code from scratch, I will use the existing software and code as a source for eliciting requirements and business rules.
First off I need to know why I am touching it.
Since I have version control in place, I know I can always back out my changes if necessary, so there are no qualms about working in place.
Never touch working code. If it already works, then any changes are bound to make it worse.
If I am fixing a bug, I want to touch as little of the file as possible to fix the bug.
If I am adding a feature, I will perform whatever automated refactorings I can to preserve behavior and cleaning it up. That means moving functions around, extracting or merging functions as necessary, commenting, and doing whatever else I need to get a solid understanding of the code. Once I understand it, I will make minimal functional changes to meet the requirements.
The only other reason I can think of to touch the code is for performance. In that case, after doing the necessary steps to understand the code (see above), take new accurate timing measurements, comment out the low-performing section, write (in place) the code I believe will perform better, and take a second set of timing measurements. After repeating a few times, and the new code meets the required metrics, I'll optionally remove the commented out original --- although sometimes it makes sense to leave it in so people understand the optimized version --- and submit that.
Since I have version control in place, I know I can always back out my changes if necessary, so there are no qualms about working in place.
Never touch working code. If it already works, then any changes are bound to make it worse.
If I am fixing a bug, I want to touch as little of the file as possible to fix the bug.
If I am adding a feature, I will perform whatever automated refactorings I can to preserve behavior and cleaning it up. That means moving functions around, extracting or merging functions as necessary, commenting, and doing whatever else I need to get a solid understanding of the code. Once I understand it, I will make minimal functional changes to meet the requirements.
The only other reason I can think of to touch the code is for performance. In that case, after doing the necessary steps to understand the code (see above), take new accurate timing measurements, comment out the low-performing section, write (in place) the code I believe will perform better, and take a second set of timing measurements. After repeating a few times, and the new code meets the required metrics, I'll optionally remove the commented out original --- although sometimes it makes sense to leave it in so people understand the optimized version --- and submit that.
It depends.
Does the interface need to remain, or is that being changed?
What percentage of the code file is changing?
Is it one code file or many?
Do I need to test the results of the refactor vs the existing version?
What language am I working in (some languages make including the new file onerous)?
What's the risk if I screw up the refactor?
How difficult is the refactor?
Am I working in source control?
Does the interface need to remain, or is that being changed?
What percentage of the code file is changing?
Is it one code file or many?
Do I need to test the results of the refactor vs the existing version?
What language am I working in (some languages make including the new file onerous)?
What's the risk if I screw up the refactor?
How difficult is the refactor?
Am I working in source control?
Never rewrite from scratch.
If you do need to refactor code, first make sure the existing code is adequately tested. The level of testing will depend on the criticality of the code. Get the unit tests into a good shape. Then carefully refactor the existing code, noting any breakages to the tests.
If you do need to refactor code, first make sure the existing code is adequately tested. The level of testing will depend on the criticality of the code. Get the unit tests into a good shape. Then carefully refactor the existing code, noting any breakages to the tests.
All the code is in version control.
If your code is in version control, and regularly committed each time you have stable, working code, then you don't have to worry about losing code, or whether you'll wreck things irretrievably - If you do, simply revert.
If it's not in version control, it doesn't exist.
Code that's not in version control is your theory on what might make the code better. But until it's tested, passed quality checks and committed, it's just that - A theory.
If it's not in offsite backup, it could vanish at any time.
Your code should be stored in at least three places. These are three possibilities:
1) In your local working copy.
2) In your local RAID array or backup hard-drives. Note the plural.
3) In offsite backup. (I use two of these)
If your code is in version control, and regularly committed each time you have stable, working code, then you don't have to worry about losing code, or whether you'll wreck things irretrievably - If you do, simply revert.
If it's not in version control, it doesn't exist.
Code that's not in version control is your theory on what might make the code better. But until it's tested, passed quality checks and committed, it's just that - A theory.
If it's not in offsite backup, it could vanish at any time.
Your code should be stored in at least three places. These are three possibilities:
1) In your local working copy.
2) In your local RAID array or backup hard-drives. Note the plural.
3) In offsite backup. (I use two of these)
As others have said, it depends.
If it's a clean up then in place.
It it's a top down performance rewrite (such as C++ => intrinsic based vectored code) then depending on the size either in place or I'll copy the old code out to notepad++ on another monitor and replace.
If it's a self contained function then I'll keep the old function and write a new one with a name which indicates the difference and direct the code there (such as a recent 'calculate SHParameters' which became 'calculateSHParametersSIMD' once I rebuilt it.
If it's a clean up then in place.
It it's a top down performance rewrite (such as C++ => intrinsic based vectored code) then depending on the size either in place or I'll copy the old code out to notepad++ on another monitor and replace.
If it's a self contained function then I'll keep the old function and write a new one with a name which indicates the difference and direct the code there (such as a recent 'calculate SHParameters' which became 'calculateSHParametersSIMD' once I rebuilt it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
