What To Do When Inheriting A Code Base: Part 1 Inspecting the code

Hey Everyone,

I’ve been on more than one occasion on the situation in which I inherit a gigantic code base and its my job to support it and write some new functionality for it. I want to outline a few steps and practices I like to follow in order to get to the point that I’m confident making changes to the system in place. Note is that I use MS products in most of my development so I’m doing the article with those in mind.

My Steps are the following and I will discuss them in different articles.

1.Inspecting the code

2.Understanding the system

3.Preparing to make changes.

1.Inspecting the code base
A.Create A New Branch

Making a new branch allows you to be able to check out files and work with them in a manner that is easy to see the changes you have done. When you actually got something that is worth you can reverse integrate into the main branch and delete yours.

B.Make sure the code compiles on the first download or lets you know how to set up the machine.

If the projects has a dependency check script run it. If it does not this is the first thing that needs to be done create a script that looks into the build machine and makes sure that all the dependencies that are needed for compilation are install and in the right place in reference with the script. By dependencies I mean libraries or GAC dll’s or simply cross compile configurations in your settings. In the case that the script is not provided a bit of investigative work will have to occur inside of the compilation errors which leads to the next point.

Make sure that all the projects that I have been given compile. It’s my practice to actually have a local compile script. This script just makes an entire build of all the project one for VSTF using batch could look as follows:

  for /R %%i in (*.sln) DO (
REM echo %%i
msbuild /clp:ErrorsOnly /nologo "%%i"

In the case that compilation is not occurring I make a list of all the problems and try to see which ones group together for example a library is missing. An important part during this step is to look out for orphaned solutions. If proper procedure are not followed sometimes in the branch you can find solutions that are no longer used. There is no easy way of finding this out. Except opening the projects and see duplicated projects in a solution.

C.Make sure that the leftover solution bindings in visual studio are correctly installed.

Try editing a file in each of the projects that are relevant and see if you get auto check out in the IDE if it does not work. You need to refresh the bindings.
Todo this follow this steps :
Open the solution
Go File>SourceControl>Change Source Control Remove the bindings
Then Go back to the same location and on the screen that lets you bind per project do binding for each one of them and the solution

D.Make sure the unit test runs
You can do it by following the steps to compile but using the mstest tool on the mstest projects the files should be the same is normal that some dependencies on the test project might be broke and some investigation will need to happen.

E.Create a dependency script Now that you went through all the work and figure what needs to be installed in a machine make it easy for everyone else. My example of that script in batch checking for Pex to be installed.


SET /a NumberOfErrors = 0

SET /a NumberOfErrors +=1

Echo %NumberOfErrors%

del temp1.txt temp2.txt


reg export HKEY_CLASSES_ROOT\Installer\Assemblies\Global temp1.txt

find "Microsoft.Pex" temp1.txt





@ECHO PEX NEEDS TO BE INSTALLED DOWNLOADED FROM http://research.microsoft.com/en-us/downloads/d2279651-851f-4d7a-bf05-16fd7eb26559/default.aspx

SET /a NumberOfErrors +=1


del temp1.txt temp2.txt

In the next part I will address how to find information about your system when no documentation is there.

Leave a Reply