Рефакторинг унаследованного приложения толстого клиента

Самый полезный шаг - создать очень надежный и полный набор регрессионных тестов, независимо от того, какой шаблон вы выберете.

Чтобы выбрать между MVP и MVC, просмотрите их различия в этом вопросе SO:

Что такое MVP и MVC и в чем разница?

Если MVP vs. MVC - ваша основная проблема, вы, вероятно, можете выбирать свободно.

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

В моем опыте оба паттерна подходят к унаследованным приложениям на C++, как кошачья блевотина к свадебному торту. Ваши основные проблемы будут заключаться в следующем:

• Ничего не сломать. Черт возьми, вероятно, не ломать все
• Заметить, что вы действительно двигаетесь вперед
• Делать это с небольшими изменениями, которые не требуют трехмесячного переписывания некоторых компонентов

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

Rewrite vs. Refactor Вы уже высказали свое решение, поэтому я просто приведу аргументы "за": если у вас есть четкая спецификация и вы понимаете, как текущие пользователи используют это приложение, то переписывание может быть быстрее и дешевле, когда 30% или более кода требуют изменений. (Это не означает "переписать все", это также может означать сокращение приложения только до логики, а затем создание нового презентационного слоя поверх него)

Предполагая, что вы решитесь на рефакторинг:

Определите свои цели Зачем вам вообще нужно рефакторить приложение? Хорошими причинами могут быть: много новых функций, которые нужно реализовать, презентационный слой нужно заменить, или слишком много ошибок, чтобы оставаться в здравом уме. Исходя из этого, решите, что нужно изменить, а что можно оставить как есть.

Вы уже выбрали свою цель: MV*. Я просто хочу, чтобы вы подумали о преимуществах для клиента и владельца кода в долгосрочной перспективе.

Читайте код. Нет, правда, не торопитесь привыкать к кодовой базе. Пройдитесь по ней с помощью отладчика. Постарайтесь понять суть происходящего. Делайте заметки об улучшениях, которые, по вашему мнению, следует внести.

Создайте тесты - в основном регрессионные тесты для желаемого поведения. В унаследованных базах кода они чаще всего проводятся вручную, поэтому создайте протоколы тестирования, которым может следовать и идиот, и постарайтесь найти не такого уж идиота, который сможет время от времени проводить эти тесты для вас. Попробуйте получить примеры использования от существующих пользователей.

Придерживайтесь небольших, обратимых изменений Если шаг рефакторинга пошел не так, он должен быть достаточно мал, чтобы его можно было отбросить без колебаний. Иногда это нелегко, мои типичные шаги в худшем случае таковы:
- решить, какую функциональность следует заменить. Составить план, как должен выглядеть новый код. - перенести существующий код за интерфейс, который будет работать и для нового кода - тестирование - заменить функциональность новым кодом - тестирование - иногда интерфейс является "окончательным", иногда его можно удалить/сократить

Всегда улучшайте Не принимайте недостатки функциональности, которые "можно исправить позже".

Вам следует взглянуть на «Эффективная работа с устаревшим кодом» Майкла Фезерса. В книге рассказывается, как превратить существующий код в тестовую систему, а также как безопасно разорвать зависимости в коде.