Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Getting Control of a Codebase

DZone's Guide to

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.

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

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.

Next, I looked at Default.aspx to see how the website worked. The majority of the website code was stored in the database stored procedures. After the tag, there was a <% %> that contained a Response.Write(RunSP.RunStoredProcedure(Parameter1, Parameter2, …) command, which executed a stored procedure. The result of the stored procedure was the HTML code, including any JavaScript that the web page needed to display. I had never seen any code like it. My guess is that the developer was secretly a DBA and wanted to make any web page changes by just changing how the stored procedures work.

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.

Next, I tried publishing my database. SQL CMD encountered a parsing error. The reason for this was my SPs contained javascript eg $(document); SQL CMD uses $(DatabaseName) as variables for a different database, so it was getting itself confused.

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.

Wow, I feel like I have done loads with this code so far, but there's loads more still to do. I need to understand more about the business processes behind the code with a hope to understand why some architectural decisions have been made. I want to refactor the code as much as is possible. I would like to remove much of the HTML and JavaScript from the stored procedures, as I can’t see that there is any advantage to running a website like this. Please correct me if I am wrong.

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:
source control ,devops ,coding ,software development

Published at DZone with permission of Simon Foster, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}