6 Tips For Tackling Inherited Code
When you’ve worked in the digital industry for long enough, eventually you’re going to have to work with code that you’ve inherited from someone else. Whether this is part of a handover process from another company, written by a developer that has since moved on or written by a freelancer, sooner or later you’ll find yourself sifting through line after line of code that you didn’t write.
When this happens it’s easy to slip into a negative mindset. It might be using a structure you are unfamiliar with, seem over-complicated, disorganized, or just different to your regular development approach — it’s rarely plain sailing.
Something built using a slightly different approach can quickly become unmanageable
Below are some tips to help you prepare for and manage inherited websites and see them as something to nurture rather than dread.
1. Ask Nicely for Documentation
Documentation for a site will often exist somewhere in some form. Hopefully! It may be out of date but anything is infinitely better than nothing. When receiving the codebase for a site, always make sure this question is raised early to ensure that any and all documentation is provided during the handover process.
2. Invest the Time Early
Take the time to understand the code you have received. Don’t just glance at it. Invest the time to really look at the file structure, CMS, task runners and whether or not the site is relying on any template engines.
Older sites…can often carry a lot of excess baggage
This would be a good time to start some documentation for the site if it doesn’t already exist, or add your own notes to any existing documentation.
You won’t be able to successfully carry out updates to a site you don’t understand. The result will be obfuscated, bug-ridden code that will only lengthen the time required to carry out even the smallest of tasks.
3. Tackle Unknown Functionality
Don’t wait for it to break! Take a look at any scary functionality on the site and make sure you’re fully aware of any and all complex API integrations. Make sure these are understood and documented clearly.
When working with this functionality, add or update comments in the code to make it clear what functions are doing what and why; saving yourself and others from having to figure it out every time the project is picked up.
4. Keep it Consistent
Learn the system and adjust your code writing habits to fit the current style. Familiarize yourself with reusable classes and functions so you aren’t duplicating any code. This will help reduce overall bloat, increase longevity and improve readability if the site is passed on to another development team.
Adding your own coding methods to an inherited site will make it much harder for other developers to pick up; so although adapting your approach might seem counter-intuitive, a willingness to be flexible is really beneficial here.
5. Spend Some Time in the Analytics
It’s important to familiarize yourself with as much of the site as possible, and digging around in the analytics can give you a lot of useful information. Get to know what devices users are viewing the site on and which browsers require support. Having this knowledge early on means you are prepared when new work comes through and know what fallbacks to put in place and can be prepared for testing.
6. Don’t Use “Someone Else Built it” as an Excuse
We need to get ourselves out of the habit of writing bad, lazy code because ‘it’s already a mess’. Creating a nightmare project is not something your wider team will want to touch. We’ve all written code we weren’t particularly proud of at some point, often for reasons outside of our control.
We’ve all written code we weren’t particularly proud of…
Tight deadlines, scope creep, and difficult clients are just a few factors that can affect the quality of a site build. Move away from looking for someone to blame and focus on ways you can improve what you have. Always take pride in your work.
The time and effort you put into any site, whether building from scratch or inheriting, pays off in the long term as it creates a readable, maintainable project. You, the team around you and the client will benefit enormously from having a positive attitude towards inherited sites.
So the next time you find yourself having to pick up someone else’s code (before you roll your eyes and start muttering obscenities to yourself) run through these tips and you may just turn a potential nightmare project into a breeze.