Friday with Filip – Joining new projects

Posted by Filip Ekberg on 05 Oct 2012

Welcome to this week's Friday with Filip!

The last three Fridays we've looked at how to become more productive, how to increase security in your web applications and how to adapt to a real testing strategy. This week I want to talk about how I get deep into the new projects that I join, fast. The projects that I'm referring to are those that have been developed on before. The customer never really wants to pay for you to spend too much time learning the code base and the actual project, so you'll have to use tools that will help you do so fast.

What I do when I first get the project on my table

The first thing that I obviously try to do, is get the project running or get all the tests to give me green lights. This assumes of course that there are tests written for the system! Just imagine that you need to join a project that has been developed for hundreds or thousands of hours and there's no tests and no documentation; this is much more common than you might think. That's why the following quote is what everyone should be feeling when writing code.

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

As soon as I've gotten the project running, or the tests are all OK. I can move on to understanding the code base. Normally when you get a project on your hands, there's something that is needed to be done, let's say that you need to implement a feature.

The first thing that I try to do, is get an overview of the complexity and what is depending on what. To do this, I'm using NDepend (which I've written about in C# Smorgasbord). NDepend will give you great reports and help you find complexity in many forms. Here's an overview that shows what is connected to what and the size of the boxes indicate the complexity:

When I find something that I think is too complex, I try to identify if there's a test for that by analyzing the code coverage. If the code coverage is bad, I try to start writing some tests, this will help me get custom to the project. I don't worry too much if the tests fail; this means that I need to debug the tests which will force me to step into the complex parts of the system and analyze them further.

To get a great overview of my testing, I use the built in (not in VS2010 Express versions, but in VS2012!) MS Test tooling.

Break & Fix the code

When I've come as far as starting to write tests for complex parts that are already in the system; I try to refactor small parts, break stuff to understand the business logic. This all helps me get a great idea of what the particular parts do.

In order to help me get an idea of what is covered by tests and not when browsing around the code, I use NCrunch. NCrunch is great, I configure it to add black dots everywhere to indicate statements that are not covered by tests. Then when they are tested, the dots go green and this is updated in real time!

At this time I can normally start looking at the actual task that I need to perform. Depending on how large the project is and how complex it is, the above process might be short or long. But at least for me, it's a great way to get my head in a new project.

tl;dr

So you've got a new project that you need to implement features in, here's what I recommend:

• Analyze the complexity of the code with tools such as NDepend
• Write tests for un-covered code to understand the flow of the application
• Use NCrunch to annoy yourself with black dots so that you'll write more tests and get a better knowledge of the code base
• Break the code and fix it again -- then refactor!

What are you doing to spend less time understanding a system and more time actually fixing the problems?

Follow @fekberg