How to proceed to refactoring / rebuilding a WPF application developed in the style of WinForms

Question

I am working on Wpfapplication, designed in the style of WinForms; I say this because the application consists of

• UserControls has over 2000 lines of code (without any regions, members, scattered throughout the class). No problem sharing at all.
• UserControls has ~ 1000 lines of code and the corresponding ViewModel, which has another 1000 lines of code.
• UserControls has many event handlers (some have> 25).
• UserControls with nested classes.
• UserControls implements INotifyPropertyChanged and has a DP.
• A lot of unused classes / code (although they are referenced / used in the code, but do nothing);
• Over 30 MultiValue converters and 40 value converters.
• Sample instances are often used in the code behind / VM.
• Multiple MultiValue Converters
  • contains hundreds of lines of code (several of which contain up to 400 lines of code).
  • with business logic inside them.
  • creating instances of ViewModel.
  • with nested classes.
  • disclosure methods used by user controls in code.
  • Display the properties used by user controls in the code behind and view models.
  • the presence of static methods that return observable collections / lists used by other converters and view models.
  • Displays events signed by UserControl and the viewing model.
  • The implementation of IDisposable.
• Transformers are widely used to create / set DataContext and ItemSources controls / ListViews / DataGrids:

like this -

<Editor:EditorControl.DataContext> <MultiBinding Converter="{StaticResource EditorControlModelConverter}"> <Binding ElementName="UserControl" Path="RefId" /> <Binding ElementName="UserControl" Path="CollectionView.SelectedScenario" /> <Binding ElementName="UserControl" Path="ParentComponentName" /> </MultiBinding> </Editor:EditorControl.DataContext> 

and this -

 <ListView.ItemsSource> <MultiBinding Converter="{StaticResource ItemsSourceInsertConverter}"> <Binding ElementName="EditorControl" Path="EditorControl.ContextListEnabled" /> <Binding ElementName="EditorControl" Path="EditorContainer.ParentComponent.Model.ModelList" /> <Binding ElementName="EditorControl" Path="EditorContainer.ParentComponent.Model.CategoryModelList" /> <Binding ElementName="EditorControl" Path="EditorContainer.ParentComponent.Model.ItemSortOrder" /> <Binding ElementName="EditorControl" Path="IsItemSourceMatrixInsertConverterSuspended" /> <Binding ElementName="EditorControl" Path="EditorControlModel.IsUpdating" /> <Binding ElementName="EditorControl" Path="EditorControlModel.ContextListEnabledInitialized" /> <Binding BindsDirectlyToSource="true" ElementName="listView" /> <Binding ElementName="EditorControl" Path="EditorControlModel" /> <Binding ElementName="EditorControl" Path="EditorContainer.Plugin.FeatureManager.EditorCategoryFeatureEnabled" /> <Binding ElementName="EditorControl" Path="EditorContainer.Plugin.FeatureManager.EditorMatrixFeaturesEnabled" /> </MultiBinding> 

The list goes on ... Have any of you encountered a similar situation and how did you deal with it? What approach should be used to reorganize such an application to improve performance and ease of maintenance?

---

Update:

The answer to Andrew V's question “Why do we need to reorganize this”:

• Performance - we are not happy with the performance of our application and believe that it should be better (given the functionality and usability).

• Improved extensibility: we are still in the early stages of our product and we know that in the future it is necessary to add many new features; but looking at the current code base, it looks tough and can break old functions.

• Improved maintainability: in the future it will be difficult to maintain compatible with non-standard / complex / hacked code (this is very bad, since we see that this product works for many years).

Answer 1

I would ask why you need to reorganize this? if the answer is “So its standards are compatible,” “It looks better,” or “So our development team is happy,” then I would seriously review it.

If the answer is “Because we cannot satisfy the needs of the business because of the complexity of changing / updating our application”, then you have a valid business reason.

I worked on many projects in which my first instinct was to write and rewrite it. Many of those whom I actually actually collected and rewritten, only to find out halfway that the original developers, while they did not do this, like I (or even had bad coding standards), fixed many problems that I would never have been seen!

In the same way, I worked on one or two, where the rewriting or deep refactor had a strong business reason, and the result was successful. However, it is always painful for him to make these changes.

So. In conclusion, if I had to do this because of a strong business need, I would probably start by creating a script test (manual testing) or, better yet, automatic tests (UI or UNIT tests, it doesn’t matter) that roughly check the functionality of your application.

Then I would take Views in turn and create ViewModels for them, moving the functionality to ViewModels. For example, moving dependency and INotifyPropertyChanged properties to a virtual machine.

Then I look at Injection Dependency, for example. StructureMap for binding the dependencies required in these view modes, or some other method to keep the connection low.

These methods and others are described in Brownfield Application Development in .NET .

Finally, I would look back at my beautiful code, which does half the functions that the old application performed. Joke! It’s good that this last part was grandiose, I think there are many reasons why this is a very good thing (refactoring), but I learned from bitter experience not to take these decisions lightly.

Yours faithfully!

Answer 2

I would start by commenting on unused code. Then start copying windows one by one.

In addition, work in the branch and check often so that you can return to known good points.

No free lunch - just get to work and stop complaining about it!