Software development while working with legacy code can be difficult, but usually inevitable if you don't start the project from scratch. And that means you need a good way to work with it.
What is the legacy code?
The classic definition
It's every code kept by someone who didn't write it.
New definitions
Any code you don't understand that's hard to change.
This may refer to code inherited from someone else or from an earlier version of the software. The phrase may also refer to code without unit tests.
Working with legacy code in the software development process is a challenge!
The biggest challenge when working with an old code base can be your assumptions about it.
If you feel that the code is bad, you would write it better yourself, and whoever created it didn't know what he was doing, you must be careful not to fall into a trap yourself. Usually there is a reason why the code looks the way it does, and if you didn't write it, you just might not know it.
Therefore, when improving the existing code base, one should be careful. The fragment we change may contain dependencies that we are not yet aware of. It is important to know when to maintain and when to change the current code base.
How to work with legacy code
You certainly won't improve the old code base in one night. Focus on gradual but thoughtful steps to improve it.
Whether you're just starting out with your existing code base or have been working on it for some time, we give you eight tips on how to improve it:
-
Test the code
One way to understand the code is to run characterization tests and unit tests. You may also run a static analyzer on your code to find possible issues.
This way, you're going to understand what the code really does. And it should expose any potentially troublesome areas. When you grasp it, you can make improvements more confidently.
-
Review the documentation
Revising the original specifications documents will help you understand where the code comes from, which can, in effect, provide insight about how to develop it without sacrificing the program. Apart from these crucial steps, you may inadvertently make adjustments that would lead to inappropriate behaviour.
-
Rewrite the code only when necessary.
It may be tempting to rebuild an old code base, but it's typically a mistake, as it takes so much time and costs a lot of money to rebuild it all. And if you plan to do so, rewriting the code will render new bugs or delete secret functions.
-
Instead, refactor the code.
Refactoring is the method of modifying the structure of the code without altering its features. It cleans the code and makes it easier to understand. It also prevents possible errors. So it's best to refactor the old code base than to rewrite it. This is achieved gradually:
- Reactivate a code that has unit tests, so you know what you're working on.
- Start with the deepest point of the code-it's the easiest thing to refactor.
- Test after refactorization to make sure you don't spoil things.
- Have a safety net, e.g. Continuous integration-so you can get back to the previous edition.
-
Make changes to the different revision cycles
Should not make too many changes at once. This is a bad idea to make improvements again in the same review cycle as functional improvements.
Moreover, it makes it easier to revisit the code-the isolated changes are far more noticeable than their accumulation.
-
Cooperation with other programmers
You may not know the code base very well, but some of your fellow programmers certainly do that. And, if you can, consult with someone who knows more about it than you do. A second look at the code will help you better understand it and speed up the process.
-
Keep the new code clean
Writing a new code based on best practice would make it less troublesome. You can't monitor the consistency of your current code base, but you can clean up your newly developed code.
-
Do further research
Operating with the old code base would become simpler with time. A younger programer does not understand why the code base has not been reworked (and may be eager to rework it), but the older developer will know when not to push it.
You will develop it if you know more about the code base.
A good starting point is "Working Effectively With Legacy Code" by Michael C. Feathers, which contains some good examples of how to make changes to the code base in the process of software development.
Another source is "Refactoring: Improving the Design of Existing Code" by Martin Fowler. This book contains many tips for effective code refactoring in software development.
Software development - tools to work with an existing code
You're usually going to have to work in or around the old code base. In the end, there's certainly a code for some reason.
There are also legitimate reasons to make improvements to the code. This can include adding features, fixing bugs, or improving the design.
In the perfect scenario, you keep rebuilding the old code base until it is completely erased. But this might not be realistic.
So you need to figure out what you're going to change and leave the rest alone.
Statistical code analysis and legacy code
One way to do this is to use a static code review tool. You can set the base level and then test the new code to make sure it's clean. You may also remove the tests from the current application database.
For eg, the Helix QAC makes it very simple to do this.
Analyse legacy code
Helix QAC will test the current code base for compliance with the law, usually from the coding standard, so you can get a diagnosis of violations. By prioritizing them, you will concentrate on addressing the most error-prone parts of your current code base.
Determination of baselines
You can also set the current code base as a guide if, for example, the code is fine and you don't want to modify it. Setting the benchmark ensures that the existing code base will not be used in the diagnosis. Instead, you should concentrate on finding issues with the new code and making sure it's safe.
Use Suppressions
You can use suppressions to make exceptions to the current code base, so that you can effectively ignore violations in it. You may limit attenuation to particular rules or infringements within a certain category.
Ensuring compliance
In certain instances, you might be able to reuse the old database from one project to another. Many of them, however, are not based on coding norms. When you need to comply (e.g. with MISRA), this will cause issues. Using Helix QAC from MISRA, it's easy to see where there are errors in the code.
► If you need help in software development, contact us!