Experiences With Refactoring In Vb Classic

From RefactoringInVbClassic:

I'm also starting to get into RefactoringInVbClassic, though only in a limited sense. I have a big program which is mostly written in Forms and Modules right now, and I confess that I wrote almost the whole thing myself over a four-year period, so I really don't have anybody else to blame. Our next version is planned to be in Java, but we expect to maintain this version for a while yet.

I am not doing strict refactoring right now, since I still haven't gotten my head around UnitTesting (how do you write unit tests for hundred-line functions?), but I am using the same principles, like ExtractFunction?, MoveMethod, and ExtractClass.

What I'm really doing, of course, is ConvertProceduralDesignToObjects?, but I'm having trouble with the first step. Almost as a footnote, the RefactoringBook says to turn each table in your RelationalDatabase into a DumbDataObject. But the way our system is designed, many of our tables can be customized by the users to add and remove many of the fields (though not all) by editing the data dictionary. Even then, I am trying to figure out how to convert a Recordset to a DumbDataObject. That's a refactoring I really need right now.

Check out http://huizen.dds.nl/~w-p/article/wrtabrec.htm It is my view of encapsulating tables and records in collections and objects. -- WillemBogaerts

I can only strongly encourage you to write UnitTests. I agree that the big functions are often hard to test, but the small routines you extract out of it should be much easier. I can only encourage TestFirstDesign too, as it makes your code more testable and therefore better "pluggable" to the rest of your code.

I personally do not use any of the VbUnit libraries, but have developed my own (VbUnit just wouldn't install when I started unit-testing). If you want to see some examples of unit-tested projects, look at http://huizen.dds.nl/~w-p/download.htm.

Good luck! -- WillemBogaerts

...how do you write unit tests for hundred-line functions?

Start easy and then work your way up. Go through the code and correct the structure. Find elements inside some of those functions which repeat parts of themselves, or share parts in common with other functions. Build smaller functions to take care of those tasks, unit test first. Find groups of methods and put them into classes. Fix the scope of their variables and then begin testing the classes. Just start by building unit tests for your new functions, and then by the time the original functions work their way down to a more digestible size they'll be ready for testing. Build all the smaller functions up around the idea that 'a function does one thing', and they'll be easier to test and integrate with existing functions. -- Aaron Cumming

CategoryVbClassic CategoryRefactoring