photo credit: erix!

In my last post, See the Code, Be the Code, I compared agile development to the game of golf. But how does one truly “see the code” as the software grows in size and complexity? On one hand, you could ignore the fact that software is developed over many iterations and try to build a very complex system all at once that does everything under the sun, or you can keep the design simple and focus on the iteration at hand knowing that as our understanding increases we will refactor the code.

Refactoring is the process by which you modify the behavior and appearance of the code to ensure that code is up-to-date with current system requirements or changes in the system environment. It gives the development team an opportunity to continuously improve code quality for long term readability and maintainability. The easier the code is to follow, the less time it will take for current and future development teams to make changes as the system matures. It can also help the development team take advantages of improvements to existing frameworks and other software used to develop the application. These improvements can be realized through better performance and reusability of existing and future code. In short, it helps keep your code from become stale and mildewy.

So we are developing a custom desktop application that utilities a third party PDF library. Our team has developed the core tools for marking up documents using simple shapes – lines, rectangles, circles and polygons, calibration of a document to a specific scale – 1/4 in = 1 ft, and more complex shapes that using the scale to compute the shapes length, area, perimeter, etc. Now we are working on hole 10 of the software development golf course and one of the user stories requires multiple scales per document.

Upon inspection of our code base, we decided that we could meet the user requirement by restructuring the code contained within the ViewPort class. This class was originally designed to allow a single scale for the entire document, and contains methods for setting and updating the scale and basic properties for accessing the scale information for use by markup that requires calibration.  The ViewPort still needs a single, default scale that’s used for entire document but should support scales for specific areas/zones of the document.  Below shows the current and proposed refactored ViewPort class and new ScaleZone class.

Now that we have an idea of how we want to refactor the code, we need some unit tests.

Unit Testing is just as important as refactoring because it helps to ensure unchanged code isn’t affect by improvements to other parts of the applications,  it helps document how to use new or updated functionality, and confirms the accuracy of our changes. So before we start changing the coding, we create a few  Unit Test. For example AddScaleZone method: we want to test calibrating a blank document and adding a new scale zone. We should save the document and reopen and assert that new scale zone exist with the correct data.

[Test]
public void AddScaleZoneTest()
{
  string fileLocation = FileUtil.GetFileLocation(FileUtil.BlankDocument);
  docModel = new DocumentModel(fileLocation);

  CreateDefaultCalibrationViewPort(docModel.Document);

  docModel.SaveAs(savedFileLocation);
  docModel.Close();

  MeasurementProperty scaleZoneMeasurementProperty = GetScaleZoneMeasurementProperty();

  savedDocModel = new DocumentModel(savedFileLocation);

  // Create the scale zone and add to viewport
  ScaleZone scaleZone = new ScaleZone(new RectangleInfo(25, 25, 425, 425), 1);
  scaleZone.SetScaleZone(scaleZoneMeasurementProperty, "ScaleZoneUnitTest");
  savedDocModel.AddScaleZone(scaleZone);

  int scaleZoneCount = savedDocModel.GetScaleZoneCount();
  savedDocModel.SaveAs(savedFileLocation);
  savedDocModel.Close();

  ValidateCalibrationViewPortSaved(savedFileLocation);
  ValidateScaleZoneSaved(savedFileLocation, scaleZoneMeasurementProperty, new RectangleInfo(30, 30, 90, 90), 1, scaleZoneCount, scaleZone);
}

We know the project won’t compile until we add the new ScaleZone class and refactor the ViewPort class. Let’s also not forget that our existing unit tests can become stale and out-of-date; it’s just as important to update the existing ViewPort Unit Tests base on the new requirement.

The point here is that code regardless of purpose needs refreshing. Don’t let it mildew! Refactor your code!

Share/Bookmark