Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Rewriting Code From Scratch

Since Visual Basic applications don't automatically port well to VB.Net, is this a case where rewriting code from scratch makes sense?

Note: Joel usually advises against this:

Chi Lambda
Wednesday, November 20, 2002

Since I had the pleasure of managing and coding two complete re-writes (HP BASIC -> VB 3.0, VB 3.0 -> VB 6.0) I have a few observations.

What I would do is use VB 6 first to re-factor your code.

You want to do is use ActiveX DLL and Interface to separate out the different levels of your code.

You will need the following (examples for software controlling a metal cutting machine)

Core (points, path, sheet, job )
UI Interface (IJobScreen, ICADScreen, ICutScreen) Application (jobs, job screen, cad screen, etc).
Commands (cut sheet, make path, new job)
UI (frmJobScreen, frmCADScreen, frmCutScreen).

Your core is the data structure, your application organizes the data structure in a meaningful way.

Now the most critical aspect is your UI Interface. All your commands should interact with forms through the UI interface not the form directly. Your form implement the interface. When your application starts each of your form will set itself to it's corresponding variable.

So frmJobScreen implementing IJobScreen will set itself to JobScreen and when commands need to either get or set something they use JobScreen instead of frmJobScreen directly.

Because you are re-factoring your application you test each change to make sure the functionality of your application has not change.

Now when it is completely re-factor what you can do is move each section over to .NET writing dummy code to probably test each transfer.

With the form behind interface you are facing a lot less work because all you need to do is get a WinForm to implete the interface. The Commands that call that interface doesn't need to change.

When you design your refactorings you want to make the change friendly to .Net as you can. For example when I got the .NET specs midway in my conversion from VB 3.0 -> V6.0 I re-factored all my drawing methods to accept a ICanvas object that was built similar to a .NET graphics object. Now when I do the dot net conversion I will just make a CanvasGraphics that can be assigned a .NET graphic object and implements ICanvas. Thus done of my drawing routines need to change.

Rob Conley
Wednesday, November 20, 2002

The critical factor is whether or not your application was designed using object-oriented principles.  If it's not, now is a great time for a rewrite. 

If it is, you should have no problems bringing the code into VB.NET and making minor changes (e.g. string functions, removing Windows API calls where possible, etc.).

Joe Paradise
Wednesday, November 20, 2002

If you're re-writing anyway why on Earth would you port to VB 6 first & then to VB.NET - seems like an immense waste of time to me. Go straight to VB.NET. As for re-writing in general I would do what Joel advises - refactor line by line to VB.NET (assuming your overall design is sound).

Jason Wellnitz
Wednesday, November 20, 2002

He's not porting to VB6 first, he's refactoring in VB6 first, *then* porting to VB.NET. Rob has an interesting approach for breaking the form to business object binding through interfaces. Although, if the application was written well in the first place, there shouldn't be any logic in the form code at all. Ie, events should call methods of business objects etc. So it may be overkill for many projects.

I think the point to take away is, it's easier to refactor the current version of a product in it's current language (or version/environment) and then port it to a new language. If you refactor and port (the manager friendly way of saying rewrite...) at the same time, you're only compounding the instances of introducing errors into the code.

Refactoring in the same language at least allows you to concentrate on the process of refactoring, ignoring the pitfalls of learning a new language and the errors that will introduce as you go.

Geoff Bennett
Wednesday, November 20, 2002

If it works well, why port it over at all? .NET's COM Interop lets you reuse the VB6 code to a certain extent.

The fact is, eventually the VB6 compiler will not be supported, so I would definitely go with refactoring the code in sections.

Thursday, November 21, 2002

As for the re-factoring in VB6 because VB Forms != Winforms. Debugging and correctly behavior difference is a mountain of work in it's own right. With a refactoring in VB you avoid that to focus where everthing operates through interfaces.

Then when you port you can then figure out how to make the Winforms work like the original.

It is worth it but if you don't do the proper steps it will devolve into a death march project. Which is the reason I delayed converting VB 3.0 to VB 6.0 for so long. The behavior of the two wasn't the same (In my case VB 3.0 to VB 4.0 32-bit) and there was no compelling reason to change until we had enough requirements that VB 3.0 couldn't be made to do. Then we did the re-write.

However this time I had read about re-factoring and design patterns so made flexibility through interfaces a goal from day one.  The conversion to .NET will be much easier for my company because of this.

Rob Conley
Saturday, November 23, 2002

Use .NET Com Interop assumes you are using interfaces already. If you are then great which means you don't have to redesign to .NET but rather re-factor.

Rob Conley
Saturday, November 23, 2002

If it is, you should have no problems bringing the code into VB.NET and making minor changes (e.g. string functions, removing Windows API calls where possible, etc.).

I want to stress that is almost never true for any application of moderate or better complexity. After completed two total conversions I can say the little differences are what kill you.

The solution is to isolate complexity and you start by refactoring in the original until you get to a point to where everything is done through an interface (or the closest thing you can fake if the languarge is not object orient). Then you can transfer you code AND YOUR TESTS piece by piece in little chunks and get it working.

Even after my latest conversion I still have plans to re-factor down the line as my original design was lacking or not flexible enough. The one benifit that .NET has taught me is that my original design for the UI did not have enough abstraction between the execution of the commands and the actual forms. So one of the goals in my next major version is have UI re-factored into Form implementing UI interface -> UI Objects -> Commands -> UI Interfaces.

Rob Conley

Rob Conley
Saturday, November 23, 2002

*  Recent Topics

*  Fog Creek Home