[Kate, one of our developers at SoftArtisans, was pulled onto a project to do consulting work. Below, Kate discusses her work and how she learned to handle inherited code. Read about the lessons she’s learned after being gifted a whole new project of code.]
Recently, I inherited the code for a pretty large project, and anyone who knew the application wasn’t around when I took it over. Learning a brand new application is a daunting task – doubled if you have to learn it without any outside resources. As I tried to familiarize myself with the application, I picked up a few tricks to handling inherited code. These are a few of the things I learned along the way that will hopefully save you hours on your next undertaking.
1. Resist temptation
It can be really hard to ignore glaring implementation flaws when you look at code for the first time. Unfortunately, there are often reasons that the junky code exists in the first place. It might not be the best solution, but if it works, just leave it. Until you fully understand what each piece of code does, you might break something unintentionally by trying to fix it. Now you’ve lost time and still don’t understand the code any better. Unless it’s necessary for your current scope of work, make a tech debt note about why it’s bad code, and back away slowly.
2. Check the docs
I learn by immediately messing around in the code and doing as much damage as possible before rolling back. This isn’t really great, but hands-on learning is so natural for most technical things that we forget about reading. You. Yes, you. You are a developer so reading seems really unnecessary. Unfortunately, we still haven’t found a way to automate it, so you’ll have to do the reading yourself. Look at any documentation that might be around. It’ll suck. It won’t make a bit of sense. Then in 6 months, you’ll look at a weird method and remember that the docs said why it was like that. And you’ll think to yourself, “Ah, well, Old Fellow, looks like that reading did more than a mite bit of good!” and you’ll laugh and light up a cigar with your adoring fans swooning and giggling. Unless, you know, you’re a normal person and not a caricature of an old famous British man. Which brings me to 3…
3. Be a caricature of an old famous British man. No. Kidding. Don’t do this. (But if you do this, let’s be friends.)
3. Check the change log
It’s useful to see what might have been done recently, what kinds of issues have been encountered, and where those fixes lie. If there’s bug tracking, change logs, general progress docs, find them all. You don’t have to memorize every issue, but go over some known problems and keep yourself from making the same mistakes.
4. Be a user
It’s a lot easier to understand the code if you take some time to use the actual application. Use it like a user would, ask users (or consult the people who already did), find out why this is the way it is. There might be a good reason that all the buttons are yellow and labeled “Do not click.” It might help the users’ workflow. Make sure you know, because ultimately if the people who need this hate what you’ve done, someone else will be inheriting this code from you.
5. Just ask
When you inherit code blind, it’s awful. I mean, of course, the last ten people to look at this have all left the company/country/planet, and you’re all alone and in the dark. However, it doesn’t hurt to ask around and find out if anyone else knows what’s up. Alternately, if you have someone who knows the code, don’t get stuck in “Am I seriously doing this wrong?” hell, and just ask the question. 9 times out of 10, the code is confusing because it’s confusing code.
6. Look before you implement
It’s great when you can finally work on the code you’ve inherited. But don’t jump right in unless you’re sure that what you’re working on is necessary. Don’t start coding until you’ve searched everywhere for the functionality you’re about to create. There may already be a GetData method, but it’s called “FindData,” “GiveMeData,” “_getData,” “oGetData” (this is very wrong), or “Eric.” You just never know. If something has already been implemented, you don’t want to write it all over again. Same goes for anywhere the code is touching. Does this happen at the database level? Is everything you need in a web service you haven’t explored? You don’t know until you know, so, you know, KNOW you know.
7. It’s not all in the code
It sounds simple, but keep in mind that before you start working on inherited code, you need to understand how it’s tested, where it lives, how to run/deploy/build it. The code is only part of it. It’s easy to start working on something and then realize you have no idea how in the world to test it. (I just did this for a few weeks. Unit tests and I are not on good terms right now.) If you can’t do anything with it, what’s the point? If this is mystery code and no one really knows, your first goal should be to find out the whole life cycle of developing on this nonsense.
8. Maintain consistency
You name all internal variables _objectName, but the developer before you used objectName. Maybe you like setting strings to “” and the developer before you used string.null. Whatever. Get it together. Make sure that if you make a formatting change it’s consistent across the project. If it’s too big a change to make, then you’ll have to adopt some new formatting standards for now. Put it in tech debt and move on. It’ll be okay one day.
9. Break it.
The best part! Mess around, comment things out, print stuff to console, step in until you get to system classes. Just break the thing. Implement something fake. Ruin all the tests. Do whatever weird hands-on thing you do to learn the code. It’ll be a lot faster with all this background handled. Oh, and roll back to a working version once everything is broken.
10. End the cycle
Honestly, I hate documenting code I’ve inherited. I had to learn this on my own, let the next person suffer. However, spite aside, it also means you are no longer the only resource for the project. Yes, it’s nice to never have to write things down (why did I even bother learning to code if I still have to read and write?), but it’s nicer to not have to field tons of questions (oh right, because if there are docs, no one will try to talk to me while I’m working). Keep track of it for the next guy, because that next guy might be you. Okay, not really. You’re not going to inherit code from yourself, but it makes it a lot nicer for the next person who has to work on it. What would you liked to have found when you started working on this?
I’ve reached the point where I’m passing along the code to someone else. I’m not sure I’ve actually ended the cycle, but hopefully I’ve helped a little. (Steph, I hope you’re reading this.)
Follow