Getting Control of a Codebase
Getting Control of a Codebase
In this article, Simon Foster describes his experience of walking into a nightmare code scenario and cleaning up the mess.
Join the DZone community and get the full member experience.Join For Free
Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market.
Recently, I started working on a new codebase. I will be honest; when I first saw it, it was a mess. Here are a few of the things I did to try and regain control.
I was given access to the source code on Visual Studio Team Services. However, this consisted of a single commit three months ago. When I looked at what was running on the production server, it was clear that changes were being made live with no regard for source control.
The first thing that I did was commit everything that was running live into source control.
Next, I created an SQL Server Data Tools (SSDT) project to keep track of all the database objects. Previously, there was a folder with some stored procedures in it, but these did not match with what was currently running.
I now had in source control the current state of the website and the database, so I knew that I could get things back to this state if I made some bad changes.
Let's start by looking at the website code I had. There was no solution file; the only way to look at the website was to set up my local IIS to run what was in the website folder. I could then use Visual Studio to open my local IIS website and attach to process to debug it.
This meant that the website was not going to do anything without a backup of the database running and that my SSDT project was going to be vital. However, the database was in a bad state; it consisted of a fair few broken objects and SSDT would not build.
Using find, I went through each of the broken database objects to find where in the code they were being used. Luckily, most were referenced in commented-out code, so I just removed all the broken database objects. The database could now be built. However, there was a dependency on the user table of another database. (This was the developer's solution to sharing logins between websites.) As I was using SSDT, I added a database dependency Problem solved! ...for now.
My solution was to use find and replace to replace all the $ with ‘ + CHAR(36) + ‘
So, I now have an SSDT project that builds and publishes but still no website project.
To get the website running from Visual Studio, I started off creating a .Net 4 website project and added Entity Framework 5 and MVC 3 via NuGet. I then copied all the website code into the new project, and with a bit of work, I got it to build. Most of the work was relating to namespaces and referencing the correct one and moving the EF model from AppCode to a custom named folder. A bit of trial and error later, I had a version of the website that could be run from Visual Studio.
I have not deployed my new version of the website as it needs further testing. No automated testing or even a smoke test checklist currently exist.
As my source code is hosted on Visual Studio Team Services (VSTS), I can get VSTS to build each commit and check I haven’t broken the build. This is not that helpful at the moment. Hopefully, one day I will have automated tests that can be run here as well.
Published at DZone with permission of Simon Foster , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.