How do I refactor a WinForms application?

Question

I'm going to bugfix a WinForms application (.NET 2.0) in the near future. Looking through the source code I find large code files (more than 2000 lines) most of them are generated dialogs with lots of code-behind.

Has anyone tips for me to share? Any war stories or best-practices for bug fixing or refactoring WinForms applications?

Answer 1

I'd start by writing some unit tests. You're going to need those to keep your sanity if the code is fairly dense.

They'll give you some confidence to be fairly aggressive in your refactoring.

Answer 2

• First try to understand the code and the logic behind it.
• Once you understand some of the code try to model the necessary classes for the business objects
• Use some kind of layer approach in your new design (3 layer is the classic): Interface layer, Business Layer, Data Access Layer (or some other service layer).
• Lots of patience and document everything!

I think this is the basic stuff. A lot of people here must have lots of suggestions. Good luck!

Answer 3

Couple of things from top head :

• Put all generated code to a partial class or region (I use regions)
• Move all code from the actions to a separate region or class as functions
• Write a unit test for each function
• Do common refactoring patterns after this point, combine same/similar functionality into one function
• Ensure that different buttons don't use different functions to do the same thing (especially in VB.NET this is quite common and design, so you can spot in your application)
• Use sender object properly where possible instead of hardcoding the control name in control event handlers
• If you see any of this code can be coverted to a nice class, do it. Get rid of all non-GUI code from the WinForms. Sometimes it's required to refactor the original class to make it possible work with GUI, write your unit tests and refactor them. (generally even without a unit test you should be fine)

Answer 4

The short version:

Buy Michael Feathers' book, Working Effectively with Legacy Code.

The longer version:

The biggest challenge when maintaining (changing) such an application is doing it without breaking something. This means you need to understand the behaviour of the application, and the easiest way to do this is to get tests around it. As you've noted, this can be daunting at first, but it is not impossible. It requires discipline and patience.

You don't have to start with unit tests. It's usually easier to get an automation framework, such as NUnitForms or White, to drive the application as a black box first. Build up a suite of tests around the area you need to change to give you enough confidence to change it without breaking something. Then go in and start refactoring towards unit testability.

If it's anything like the application I'm working on, it mainly involves:

• deleting unused code (it's a distraction).
• removing public static method calls and replacing them with interfaces (Dependency Injection is a key technique here).
• extracting duplicated code into classes.
• hiding file handling, network IO, and user interface code behind adapters (these can be very thin wrappers at first, just enough so that you can replace them with stubs when testing).
• looking for opportunities to extract behaviour into small classes.

Sometimes it will be easier to rewrite sections of the code rather than refactor them, but that requires an understanding of the behaviour, either through testing or by referring to a spec (if one exists).

Apart from any practical advice, if you're part of a team working on this make sure you are working together. It will make the work easier, more enjoyable and ensure that changes you make today aren't undone tomorrow by someone who didn't understand what you were working on.

I could write all day on this topic, but Mr Feathers is much better at it, and I'm hungry. Good luck!