How to deal with legacy code

deal with it At the company I work for we are currently developing a new web application that aims to replace the variety of applications developed over the last 10-15 years. Many of these applications were built with some technologies that have fallen into disuse, such as VB6. As the company seeks to improve the solutions it offers to its customers, becomes increasingly necessary to build products using the latest technologies.
In the last year and half I have been "spared" to the difficult task of maintaining the legacy code of these older applications, but in the last two weeks, due to a rotation policy in the development team, I have been assigned some tasks to do some fixes in these applications.
And well, this was my first “hardcore experience” dealing with legacy code. I did some “kids' stuff” with VB6 some 7 years ago but I almost knew nothing about it. For example, for who’s coming from a long background in Java like me, it’s a little bit weird that when I use the <> operator I was expecting to get either True or False when comparing an object to Null. But in this particular case it neither returns True or False, but Null. This kind of details are very important to know but it's impossible to catch it all on the first lines of code...
So, If you're in a simillar situation, I think i can give you a few advices:

  • First, understand the problem. Try to get all the information that's passed to you by your boss, or your client, or whoever that assigns this new task to you. Take notes, because you might not remember everything later.

  • Don't annoy the "older guy" every 5 seconds. Ok, you don't know the code, you're facing spaghetti code that's almost unreadable, and you're under pressure because it can't go into production worst than it was before but, who likes to be annoyed by someone that asks the same question over and over again? Unless you're really stuck, try not to interrupt your colleague everytime you don't understand something.

  • Don't ask for solutions. Ask for advices. This bullet follows the same line as the previous one. When you need to talk with the more experienced dev about some problem you're having, try to show a few solutions and ask for which one is better, instead of asking for a solution that you didn't even tried to think about. I use google before asking dumb questions

  • Google is your friend. You don't know the framework, don't know the language... Welcome to the jungle baby! But here's Google to save your day. A simple search with the right keywords can save you precious time.

  • Ctrl+F is also your friend. So, you modified a function and you think your job is done. Wrong, you didn't checked every single place where's this particular function is being called. In Eclipse you have a very usefull shortcut to find every place where's a method or a variable is being used. But in older IDEs like the Visual Basic 6 IDE you don't have this kind of features and you're forced to use Ctrl+F in the whole project.

  • Draw! Make schemes or graphs, it'll help you understand the problem before and after starting to code. It will also help you when you have to explain a particular situation when you're in trouble and someone's helping you.

  • Comment your code. You're cursing the developer that wrote the spaghetti code that's melting your brain during the last hours and now you're doing the same!? FACEPALM

  • Test it well. What else is there to say?

  • Ask for a code review before committing the code and take notes. That's very important. If you have a more experienced developer in your team, ask him to do a simple code review. Take notes of his advices so you can do better and faster next time.

Some of the previous points may seem too obvious for you. That's good! But believe me, unfortunately there's some "developers" out there that wouldn't do half of this stuff unless you really told them to.