English | EN 
You just inherited someone else’s code and you feel like the task is going to be impossible. You are overwhelmed by the lack of documentation, you also find out that there are no tests in place and you wonder how on earth you will make the requested changes without breaking things. Yes you are scared!
I’ll try to help you with these 4 guidelines:
You will come out stronger from this experience.
As humans, we find ourselves in this never-ending learning journey… take a moment for yourself, calm down and be sure that you’ll get something in return after you conquer the inherited code or application.
Perhaps, you don’t know anything about the business the application is intended for. Grasp anything you can and expand your knowledge base. You never know when those key things you learnt will come up handy in another situation, project or even landing your dream job.
Maybe it’s your lucky day and the code, you just inherited, was written by a more experienced developer, and therefore you’ll learn new ways of doing things … yes, I know … sometimes it can be difficult, frustrating, and confusing, but believe me, once you finish the job you’ll have more things in your toolbox so when the next project knocks on your door, you’ll have different ways to approach it.
In the worst case scenario, you’ll find yourself trapped in the middle of some serious spaghetti code … in such a case you’ll learn that you have a responsibility to those who follow, because you don’t want anybody complaining about your code, or do you?
Understand The Big Picture.
You’ve just become responsible for a code base, you know nothing about. So where do you start? Let’s remember that Agile, SCRUM, PMP ITIL, etc… all begin with some sort of planning or assessment as described in the Deming PDCA cycle.
You need a plan, you need to know where you and the current code are standing. Don’t jump into those first keystrokes before making your point that is important to step back for a moment to get a glimpse of the project, an overview of what the software is supposed to do. Ask for any available documentation, functional requirements, user stories, anything that stakeholders may have that will help you plan where and how to start.
Don’t act like a robot, ask what the expectations are and document your findings. Once you have a good understanding of the big picture, you are a step closer to working your way through the code.
Don’t start over.
I know that feeling. You look at the screen, you curse in any language you know and the first thing that comes to your mind is: I’ll start from scratch.
For instance, in this stage you probably can’t know all about the business rules or knowledge embedded in the code base and therefore you cannot be sure your “new” software will work or perform better than the first.
Unless you are making a major architecture or technological change, work with the legacy code, as long as you can. Fix whatever you find is not working as expected, and just start to think about rewriting when you have tests in place to assure that you’ll not break existing functionality.
Debug it and Test it!
Master the art of debugging. Go step by step through that code you don’t understand. Use breakpoints, watch variables and learn what the code is intended for. Once you get the picture, of what the code is doing and what it is supposed to do, you are clear to start with your changes.
“… Even if your code was written yesterday, if there are no unit tests to characterize or define the behavior of the code, then the code is legacy, and will be difficult to change without introducing bugs…”
Do create tests for your code. Sometimes you’ll find it difficult because of many types of constraints (i.e. time, budget) but make your case, remember you don’t want anybody reading this article because they just inherited your code!
Hope it helps!
Blog contributed by Carlos Mendible ( Ex-SogetiLabs Member & Sogeti Employee)
