What does Legacy Code mean to you?
Do you imagine a perfectly organised project, well documented using standard design patterns – or an undocumented mess, one huge block diagram that will take hours to unravel and make sense from?
In my experience probably the latter. I’m usually asked to help out with legacy code when there is a serious problem to be fixed, it’s an old code base, added to over several years and has often become out of hand with no design pattern applied. Working with legacy code can be daunting, risky and a less than enjoyable experience.
What’s it like to work with Legacy Code?
Coding in LabVIEW should be fun and enjoyable, one of my favourite things is adding new features to code that will do something cool, and that my customers will really appreciate by making their life a little bit easier, or allowing them to do something new and challenging.
Wouldn’t it be great if you could have the same experience and enjoyment when adding features to a legacy code project? I want to feel excited to add a cool new feature to that legacy project when I pull it out of source control, rather than a feeling of impending doom of hours spent scratching your head trying to bug fix a behemoth.
What are you trying to achieve?
I think it’s always worth thinking through what you are trying to achieve before getting started. Ultimately you have to make an assessment to use the existing code, or abandon it and start from scratch. To help make that decision, think about
- Are you fixing a bug, improving the performance or adding a feature?
- What stage is the project at when you are called in, what’s happened before, and how long is expected to be left in the life cycle of the project?
So when making the decision of which path to choose, consider the risk involved in each option. In modifying existing code, this is usually related to your understanding of the code, and the likely hood of undesirable actions occurring because of the changes you have made.
Preserving Behaviour
When working on legacy code, we want to change or add some behaviour, but we want to preserve much more. So we have to focus on changing a small area, and ensuring a large area does not change, and this involves more than just leaving the code alone. Our challenge is that we often don’t know how much of that existing behaviour is at risk when we are making changes. Understanding is the key thing we need to make changes safely.
Preserving behaviour is a challenge, and when doing so, these questions need to be answered
- What changes need to be made?
- How do we know they have been done correctly?
- How do we know existing behaviour hasn’t changed?
Cover & Modify
Cover & Modify means Cover your code with Unit Tests, then perform modifications. You can then quickly run the Unit Tests to get immediate feedback on the effects of those modifications. Think of this as working with a safety net – tests that will catch any oversights you make.
Use the following steps to implement the Cover & Modify method when making modifications to an existing code base
- Identify a section of code
- Develop Unit Tests
- Run Unit Tests
- Make Modifications
- Run Unit Tests again
- Debug
Unit Tests in LabVIEW
A unit test should ‘Isolate each part of the program and show that the individual parts are correct‘ (Wikipedia)
Within LabVIEW, the Unit Test Framework Toolkit helps you to implement Unit Testing, and if you are a Developer Suite subscriber, it’s already included in your LabVIEW license. This toolkit makes developing and running tests easy and fast.
Unit Tests are created within the LabVIEW Project, and you create a Unit Test for a single VI. Here, I’ve made a Unit Test for a simple VI ‘Calculate Sequence Percent Complete.vi’. This performs some simple math to calculate the % complete of a test sequence.
Using the Unit Test configuration window, you can go to create all of the test cases for this function. For a more detailed walk-through of using the Unit Test Framework Toolkit see this link.
Sounds like a lot of effort?
This method is often more work upfront than just diving in and making some changes. It’s more of an investment in the lifetime of a project and will pay dividends in the future when making further modifications and changes to the project.
Over time, more and more islands of code should come under test, making changes more reliable and safer.
Good luck working on that legacy code project, and have fun making software do great things!