Как выполнить рефакторинг / перестройку приложения WPF, разработанного в стиле WinForms

Question

Я работаю над Wpfapplication, разработанным в стиле WinForms;Я говорю это потому, что приложение состоит из

• UserControls, имеющих более 2000 строк кода (без каких-либо регионов, члены разбросаны по всему классу).Никакого разделения интересов.
• UserControls, имеющие ~ 1000 строк кода и соответствующие ViewModel, имеющие еще 1000 строк кода.
• UserControls, имеющие много обработчиков событий (некоторые имеют> 25).
• UserControls, имеющие вложенные классы.
• UserControls, реализующие INotifyPropertyChanged и имеющие DP.
• Много неиспользуемых классов / кода (хотя на него ссылаются / используют в коде, но ничего не делают);
• Более 30 многозначных преобразователей и 40 преобразователей значений.
• Экземпляры преобразователя часто используются в коде позади / VM.
• Несколько многозначных преобразователей
  • с сотнями строккода (немногие имеют до 400 строк кода).
  • с бизнес-логикой внутри них.
  • создание экземпляров ViewModel.
  • с вложенными классами.
  • Предоставление методов, используемых пользовательскими элементами управления в коде позади.
  • Предоставление свойств, используемых пользовательскими элементами управления в коде позади и просмотра моделей.
  • со статическими методами, возвращающими наблюдаемые коллекции / списки, используемые другими конвертерами и моделями представления.
  • отображение событий, подписанных UserControl и моделью представления.
  • Реализация IDisposable.
• Конвертеры широко используются для создания / настройки DataContext и ItemSources элементов управления / ListViews / DataGrids:

, как это -

<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>

иэтот -

<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>

Список можно продолжить ... Кто-нибудь из вас сталкивался с подобной ситуацией и как вы с ней справились?Какой подход следует использовать для рефакторинга такого рода приложений для повышения производительности и удобства обслуживания?

---

Обновление:

Ответ Эндрю Q - «Почему нам нужнорефакторинг это ":

1. Производительность - мы не довольны производительностью нашего приложения и считаем, что оно должно быть лучше (учитывая функциональность и удобство использования).

2. Лучшая расширяемость: мы все еще находимся на ранних стадиях разработки нашего продукта и знаем, что в будущем необходимо добавить множество новых функций;но, глядя на текущую кодовую базу, она выглядит жесткой и может сломать старую функциональность.

3. Лучшее сопровождение: будет сложно поддерживать нестандартный / хитрый / хакерский код в будущем (это очень важно, так как мы видим, что этот продукт работает в течение многих лет).

Answer 1

Я бы задала вопрос , почему вам нужно провести рефакторинг этого? если ответ «Так что его стандарты соответствуют», «Это выглядит лучше» или «Так наша команда разработчиков довольна», я бы серьезно пересмотрел это.

Если ответ «потому что мы не можем удовлетворить бизнес-потребности из-за сложности изменения / обновления нашего приложения», то у вас есть веская деловая причина.

Я работал над многими проектами, где мой первый инстинкт был переписать и переписать его. Многие из тех, что я сделал, на самом деле записывают и переписывают, только чтобы выяснить, на полпути к этому первоначальные разработчики, хотя они делали это не так, как я (или даже имел плохие стандарты кодирования), исправили много проблем, которые я никогда не рассматривал!

Точно так же я работал над одним или двумя, где переписывание или глубокий рефакторинг имели вескую деловую причину, и результат был успешным. Тем не менее, это всегда больно вносить эти изменения.

Итак. В заключение, если бы мне пришлось сделать это из-за сильной потребности бизнеса, я бы, вероятно, начал с создания сценария тестирования (ручное тестирование) или, еще лучше, автоматизированных тестов (UI или UNit Tests, не имеет значения), которые грубо тестируют функциональность ваше приложение.

Тогда я бы по очереди взял Views и создал для них ViewModels, перенеся функциональность в ViewModels. Например, перемещение свойств зависимости & INotifyPropertyChanged в виртуальную машину.

Я бы тогда посмотрел на инъекцию зависимостей, например. StructureMap для связывания зависимостей, требуемых в этих моделях представления или каким-либо другим методом для поддержания низкого уровня связи.

Эти и другие методы описаны в книге Разработка приложений Brownfield в .NET .

Наконец, я бы с восхищением оглянулся на свой красивый код, который выполняет половину функций, которые делало старое приложение. Шутка! Хорошо, эта последняя часть была оскорбительной, я думаю, что есть много причин, почему это очень хорошая вещь (рефакторинг), однако из горького опыта я научился не принимать эти решения легко.

С наилучшими пожеланиями!

Answer 2

Я бы начал с комментирования неиспользуемого кода.Затем начните переписывать окна по одному.

Кроме того, работайте в филиале и часто регистрируйтесь, чтобы вы могли вернуться к известным хорошим моментам.

Бесплатного ланча нет - просто приступайте к работе и перестаньте жаловаться на ТАК об этом!