Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have been hired as a junior programmer to work on projects that extend existing functionality in a very large, complex solution. The code base consists of C#, ASP.NET, jQuery, javascript, html and xml.

I have some knowledge of all these in addition to fair knowledge of object-oriented programming and its fundamental concepts of inheritance, abstraction, polymorphism and encapsulation. I can follow code up through its base classes, interfaces, abstract classes and understand a large part of the code that I read while doing this.

However, this solution is so humongous and so many things get tied together whenever I navigate through the code that I feel absolutely overwhelmed. I often find myself unable to fully follow everything that is going on with objects being serialized, large amounts of C# and javascript operating on the same pages and methods being called from template files that consist mainly of markup.

I love learning about code, but trying to deal with this really stresses me out.

Additionally, I do know that a significant amount of unit testing has been done but I know nothing about unit testing or how to utilize it.

Any advice anyone could offer me regarding dealing with a large code base while using Visual Studio 2008 would be greatly appreciated. Are there tools that I can use to help get a handle on what is going on? Perhaps there are things even in Visual Studio that I am not aware of. How can I follow the code to low level functionality in order to get a better grasp of what is going on at a high level?

share|improve this question

closed as too broad by MichaelT, Snowman, Scant Roger Nov 19 '15 at 6:08

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

You sound a lot like me when I was a junior. I have problems with anxiety in all aspects of my life as do a lot of other people. I have a dog that when I take him into a new fenced in area or house, he will get really anxious and frantically snoop around until he has seen and mapped out every area. He will not calm down and relax until he has explored unfamiliar territory near him. You and I are not so different. You feel anxious not because of the code but because you don't understand it completely. Over time you will start seeing patterns and you will feel comfortable. – maple_shaft Jul 1 '12 at 2:55
Let the code be as complex as it gets, the question here is what is your task? I don't assume that you are responsible to work on the entire system by yourself. Focus on the problem at hand. When a mechanic is sent to fix the wheel of an airplane, he does not take out the cockpit dashboard and follow the wiring, just focus on the few skills needed to work on your part, ask questions and ask for help from those who may be willing to help. Don't by shy, you never told them that you are MVP. – NoChance Jul 1 '12 at 9:01
up vote 6 down vote accepted

Stepping through the code can be great at determining functionality. But I have found the more complex an application is, the more likely you are to be bounced around in the debugger and get completely lost.

I would focus on understanding the business rules of a particular piece of functionality of the application. Ideally, focus on the simplest part. For example, if your web site has users, focus on how the users are registered. What is required for them to register? Email? Zip Code? Blood type? If the code is not clear, then there is no harm in asking other developers specific questions about the business rules (well unless they are jerks).

Once you have a set of business rules nailed down, look at the code and determine how they are enforced. Is the input validated on the server? Client? Where is that validation stored? Then look how the data gets inserts/updated/delete/selected from the database/repository? What class libraries are invoked? The unit tests are also an excellent place to help figure out business rules.

Unless the other developers are insane, most of the other aspects of the applications will follow a similar process.

As for unit testing, one book that really helped me get a good grasp on unit testing is The Art of Unit Testing. It lays a good foundation and will give a good start on how to do it correctly. The best way to learn unit testing is to start doing it. As you read the book create a test application to try out some of the techniques.

share|improve this answer
Thanks for the tips. I have the Art of Unit testing in my cart at Amazon with plans on ordering it next, but I have just started working through a book called Refactoring with Microsoft Visual Studio 2010. – Darren Jul 1 '12 at 20:14

Most overwhelming systems, in my experience, have at least a few key parts that seem scariest. I pick one and try to understand just that one. Knowing that key part makes it easier to understand its related parts.

My favorite approach to doing this is to use a sequence diagram. To me, a sequence diagram provides me with the picture I need to understand how a key part works.

Keep in mind too that your anxiety & stress may mean that the system isn't architected and/or documented very well, so don't beat yourself up for being confused.

share|improve this answer

Like you, I always step through the lines in the code base to get a basic feel.

I know how you feel, one time I got hired in the 10th iteration of a large scale web project. Its architecture was one of the prototype's for . So it was totally new and we we're using commerce server 2007 too, no one in the country had experience with it! I was thrown in the deep end, writing Rhino Mocking Tests which I too had no clue how to do at the time.

If you're a new starter they will give you three months to prove yourself and you're a junior so aren't expected to know everything.

The trick is do the initial research on anything your tasked with and be prepared to answer: When other developers see you putting in effort and how your thinking works they will be more likely to give you a hand.

The initial research also requires examining the source control system, as all the info is likely in the history, checkin comments & work items.

share|improve this answer

How can I follow the code to low level functionality in order to get a better grasp of what is going on at a high level?

Short answer: you can't.

Longer answer:

Any non-trivial application is going to be too big very soon for you to try and understand it in a bottom up manner. This gets worse as soon as a framework and/or patterns like observers are involved. You are either going to miss a lot just reading the code (How the heck did they do this? Where the heck is that coming from?), or will be bounced around in the debugger through heaps of framework code and you will quickly lose track of for which part of your functional code you have entered that piece of framework code.

To get a feel for the application and find your way around the code: focus and don't try to understand the whole thing. At least not all at once.

  • Start from the user interface.
  • Identify major chunks of functionality.
  • Break these up even further. Preferably into what could be considered user stories or use cases. For example listing and filtering 's, entering a , registering a user, listing users, authorising users, loging in, etc.
  • Take a top-down approach to see how they have been implemented.
  • Try and map user interface stuff to files in the solution. For example an application page to its html equivalent(s).
  • Figure out which classes are involved in the implementation of that part of the application.
  • Ignore any cross-cutting concerns (logging, exception handling, printing, even database operations). They are usually implemented in some kind of framework or library anyway and can "safely" be ignored if you are tracking the actual functionality of an application. If you need to use them, you can make them a seperate subject of your investigation.
share|improve this answer

ASP.Net is a complicated stack to understand as you have C# and OOP (which you are already familiar with) but you will also have to grasp the web specific technologies like Page Lifecycle, HTML, CSS, HTTP and Javascript/jQuery. So it is natural to be overwhelmed and it seems the application is not properly designed as well. But that is the reality in most software systems.
I would approach it in two directions first learn the technical areas you are weak (like jQuery, unit testing) on its own outside the application and second try to trace/debug one transaction end to end from UI to DB. Also try to understand the unit tests, they can be very helpful if written properly. Code navigation using Visual Studio is quite OK but if you can get a tool like Resharper it is better. ASP.Net has built in tracing to spit out diagnostics as well.

share|improve this answer

protected by gnat Sep 9 '14 at 12:57

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.