Importance Of Keeping Your Software Up-To-Date

The craft of software development, laid out on strong fundamentals and well established best practices, is constantly evolving and is sometimes challenging to keep up with. Programming languages being updated with new features, new tools incorporated in our daily workflows, libraries we use in our codebases updated to new versions, code depreciation and general ecosystem evolution all contribute to the challenge of keeping our craft and software up to date and relevant.

Why couldn’t our software be like fine wine? As it matures and stands the test of time it gets better or up to date with little or no intervention. For now, we can only imagine the aforementioned scenario as something the future may bring. The reality is, our software is somewhat like cars. It needs regular maintenance and checkups from the time it has left the salon. It can become obsolete but still running. It’s used daily. We have the need to replace it with a newer one once it’s outdated or make it better with upgrades, more economical, with more equipment and better safety features – a more performant one. Even with the one that pollutes less and costs us less money in exploitation down the line. This post will focus on practical advice on how to keep your codebase and software up to date and how to avoid pitfalls of large migrations at-once and big rewrites.

Since our specialty is PHP ecosystem technologies the focus will be on those.

Project upgrade using PHP and MySQL with Symfony and Doctrine

Not long ago, we had to upgrade our project built using PHP and MySQL with Symfony and Doctrine on top. The first version of our application was written in PHP 5.3 with Symfony version 2.4. One of our major clients was given a proposal to upgrade existing codebase to support PHP 7.3 and Symfony 4.4. We were determined to persuade the client to accept the proposal since we knew the benefits the upgrade would bring. Benefits in both further development and client satisfaction in terms of agility and general impression. The proposal was as reasonable as it gets since the application codebase is fairly large and it’s a long term project. Benefits of the upgrade are therefore obvious: PHP version that runs code faster than the previous, more programming language features like type hints for eventual refactorings, new features, etc. Gladly, the client accepted.

The transition from PHP 5.3 to PHP 7.3 was relatively painless since code was written and structured well enough to make it so. It is mostly compliant with SOLID principles and best practices as such. There are some tools to help make this transition smoother and not exclusively manual so to speak. Basically, to automate it. Rector is one of them and is well worth mentioning. It is a tool to automate the process of upgrading your codebase to newer versions of PHP from 5.3 up. Additionally, it provides instant refactoring. For everything else that Rector doesn’t pick up there is manual refactoring. Also, the official PHP manual offers a migration overview for this particular case and is worth checking out before diving into work.

In theory, if the first step goes smoothly the second most important upgrade, Symfony version and all of the dependencies version upgrade, would be a matter of running a command in terminal thanks to the awesome Composer package manager. Upgrading a framework to a major version with all of the dependencies often comes with the side-effect of breaking your application code. Understandably, it happens since there are places in your codebase where some features or syntax is deprecated and not supported anymore by package backward compatibility principle. That’s why it’s very important to look more closely to the framework or package roadmap or release cycles if possible.

For instance, Symfony has a detailed release overview which served us as a guideline to choose the appropriate version. It’s extremely important to consider so-called LTS (long term support) versions. The benefits of choosing LTS version over some other are I believe obvious but come with a slight disadvantage. Upgrading between LTS versions can be tricky since there is a fairly large gap. For example version 2.6 and 4.4 can be considerably different in terms of concepts, syntax and even have different directory structure. That’s why the general rule of thumb is: upgrade as often as possible and choose wisely! 

Composer is your friend and running composer update often is desirable. It ensures that your dependencies are updated to the latest stable version and those versions should not contain any backward-incompatible changes. Often upgrades to minor versions also ensure that you get depreciation notices every time you end up using deprecated features. This allows you to act fast and replace those with up to date features. Generally, these are general rules to follow:

• Use stable as the minimum stability level in your composer.json file (use the @dev suffix as a suffix if one of your dependencies is not stable yet).
• Define good version constraints in your composer.json file.
• Run composer update with confidence whenever you want to upgrade your project dependencies to their latest stable version.

When the time comes to adapt your codebase after upgrading packages we are offered another opportunity worth mentioning. In this step, we will probably come after code no one has seen or touched a long time ago. Maybe it’s even code written by yourself. If you can think of another, better way of writing that piece of code in a reasonable amount of time which can result in negative diff(yay!) in your version control commit and make the code more readable, delete that strayed new line, rename misspelled variable, delete dead code or remove unnecessary comments now is the time to do it. Because small steps, made over time, move mountains. You don’t have to move a mountain but developers working with or after you will be grateful down the line. This principle is also known as Boy Scout rule and it says: “Always leave the campground cleaner than you found it”. It’s explained in more detail in Uncle Bob’s (Robert C. Martin) book “Clean Code”.

Another excellent safety net in major upgrades and software lifecycles, in general, is having your codebase covered with automated tests. Be it unit, functional or some other types of tests, anything is better than nothing. Codebase doesn’t have to be 100% or 70% covered – the tests should cover the most vital parts of your codebase. Of course, a higher percentage is favorable in most cases. 

Conclusion

Doing a major upgrade to a codebase can be a daunting task but if we keep in mind and apply a few of these basic principles continuously we can reduce stress developers and project owners’ experience. Upgrades, in general, offer large benefits and the downsides are easily outweighed. 

Upgrade often and happy coding!

If you are looking for a strong development and design team or you have some questions for us, give our team a shout!

Or browse through our services.

We look forward to helping your businesses grow through digital excellence.