On learning new code

In college, most of the programming projects I worked on were those that I built on my own (with the few exceptions of some group work).  For my senior project, I was selected to be a part of the first CS Senior Design project at CSULA (for those of you who are curious, you can check out my notes for the Winter 2009 and Spring 2009 Quarter for this project).  This was a great experience as I was able to work with 3 other CS students in adding new features to the application (something that I had not ever done before). One of the challenges of this project for me was figuring out a way to familiarize myself with the code base of the application.  Below you will find some pointers that helped me achieve this.  I am writing this because I wanted to share my experience in hopes that it may help someone out there!

Asking Questions
Probably the most important things you can (and should do) at the beginning of a new project is to ask questions!  I recall the first day when our team met the developers at Aerospace, myself and the other group members asked a lot of questions.  The questions raised dealt with high level stuff such as what’s the main purpose of the application and how users actually used the application to help them with their everyday task.  It’s important to know how the everyday users of the application actually use the application.  With this knowledge I was able to familiarize myself with the application (I also read the user manual provided to us) which helped me accomplish my tasks.  In addition, I also asked some low level questions such as what technology was being utilized (2d drawing, threads, gui, etc.) to make sure I brushed up on these topics!  Our team was also fortunate enough to have a member who was quite familiar with the code base as he had been working on it for a few months before we did and as a result he was an invaluable resource to help us out!  During the whole project, we also did ask questions of the two main developers at Aerospace as well.  No questions was too silly to ask (at least that’s the attitude I took).  One piece of advice I will give you is to not just ask questions for the sake of ‘asking questions’.  If there is something you’re stuck in, or something that you are not sure about make sure that you have done some research on your own.  If your research has not yielded anything, then go ahead and ask!  Asking questions without having done any research on your own doesn’t really help you out that much when familiarizing yourself with a new code base (see my note below on breaking things for more on this).

Break Things
In order to really start learning the code base the best advice I can give you is to just go ahead and start breaking things. What I mean by breaking things is simple, as you browse the code comment out some lines and see what happens when you do this.  Your goal is to break things so that you can get an understanding of what the line(s) you just commented did.  This was a common thing I did during the duration of this project.  Although our task was not to become intimately familiar with the code base, doing so made me much more productive and allowed me to implement the majority of the features I was given.  How many things to break, and what to break will be different for each code base.  Just make sure that you don’t break too many things that you can’t trace yourself back to the original working state of the application!  If you do ever find yourself in this situation, become familiar with the ‘revert’ feature of the source control management tool you are using (please make sure you are using source control … see more below).

Print to Console
When you want to find out what’s going on with values in your object, put in a print statement that will show you the state of your object.  Don’t know when one of your objects is created?  Put in a simple print line statement inside of your constructor? If your code breaks the application and the error stack trace is just too long (and maybe even too intimidating) print out some of the values of what you think  is causing the object!  This saved me so many times, I also noticed that the other developers utilized this same approach.  Just one last note on this topic, once you are done fixing your code make sure you remove the print statements so that the code doesn’t clutter up the source code!  Believe me, your fellow developers will like you even more if you remove your print statements!

Learn to use (and love) a Debugger
Using print statements can also help you fix some nasty little bug that may have been introduced by your code.  However, using print statements may not be enough some times to really dig deep in your program to help you fix the bug.  To dig deeper in not only learning code but to fix those nasty little bugs, learn (and may I even suggest to love) to use a debugger to help you out.  At first, debuggers are a bit intimidating, my advice to you is to just jump in and start learning how to set break points and run your code and explore the state of the program.  Even if you don’t have any bugs, this is too a great way to learn what the objects in the program are doing!

Source Control Management
In any major project you will most likely be using some sort of source control management system to help in the development process.  This was also true for our little project.  Becoming familiar with the basic concepts of source control management is such an important thing.  And my familiarity with Subversion (which was what the team used) came in handy!  I originally set up the SVN repository in one of the CS servers at school and helped the rest of the team connect to the repository.  One of the main goals of source control management is to keep a history of all of the changes made to the files in your project.  But you can also use to see the how the file(s) you are interested in have changed.  This is a great way to learn why and how some features work!  I always looked at the changes made by the other developers, this in turn helped me to become more familiar with their code which in turn allowed me to better understand my the work I was doing and how it would affect their work!

Don’t Work in Isolation
As I stated before, working on this project was my first time working with other people on a programming project.  As such, communication was an important key to the success of the goals of our project.  Our team communicated constantly thru e-mail (some of our e-mail messages would have 30 or so replies … this was not that uncommon!) but we also met once a week to discuss our work that we had done.  Working in isolation would have been a bad thing as I found that by talking to the other developers about the work I did (and vice versa) I got a better understanding of the code base!