Preparation

These are the standard steps I follow when I prepare to work on an existing program.

 

Usually, this is to add new features to a program, or fix/change existing features. But, in this case, I’m focusing on “refactoring” an existing project.

The only changes I’ll make in this series will be to improve the quality of the code – to make it easier to make future changes.

 

The first few articles in this series will cover preparation and planning. Then, I’ll go into details of each change I make – including the C# code for the change.

The project I’ll use is the SuperAdventure project from my C# tutorial series. I wrote the tutorial to introduce beginning programmers to the basics of C#. So, I did not go into more advanced programming techniques – techniques that would make the code easier to change and expand.

The solution has two front-ends projects: Windows Forms and Console.

 

Put the project in source control

The first step is always to put the existing project into a source control repository.

A common problem with lower-quality code is that changes have unexpected side effects. Even if we make a “good” change, it may break something in another part of the program.

We’re going to make many changes to the program, and some of them may not work. Source control management gives us a way to quickly undo our changes, in case the change breaks anything.

I’ll use TortoiseSVN (Subversion) as my local source control.

 

 

Achieve a successful build

Many times, when I’ve started working on an old program, it doesn’t build the first time. You need to install a library, build a database, or make some configuration settings.

So, the second step is to get the program to the point where you can run it.

This is an easy step to skip – especially when you only plan to make a small change. And sometimes, skipping this step doesn’t cause a problem. But, I’ve wasted time in the past trying to find out why my change broke the build, when the real problem was that the program didn’t build before my change.

So now, “achieve a successful build” is always the second step on my checklist.

If you need to do any setup, to get the program to build, create a document with the steps you had to perform. Include this somewhere with the project, to make it easier for the next person who needs to work on the program.

Fortunately, SuperAdventure already successfully builds.

Leave a Reply

Your email address will not be published. Required fields are marked *