Если MVP против MVC является вашей основной проблемой, вы, вероятно, можете свободно выбирать.
На это решение влияют три фактора: ваш предыдущий опыт, поддержка вашей инфраструктуры / библиотек и то, что лучше соответствует существующей кодовой базе.
В моем опыте оба паттерна подходят для унаследованных приложений на C ++, таких как cat puke на свадебном торте. Ваши основные проблемы будут:
- Ничего не ломая. Черт, это, вероятно, не все ломает
- Заметив, что вы на самом деле движетесь вперед
- Выполнение этого с небольшими изменениями, не требующими переписывания некоторых компонентов в течение трех месяцев
Остальное очень общее для работы с устаревшими приложениями, не связанное со спецификой вашего вопроса. Я оставлю это здесь, так как у вас также есть общая часть.
Rewrite vs. Refactor Вы уже заявили о своем решении, поэтому я просто выдвинул аргументы pro rewrite для рассмотрения: если у вас есть четкая спецификация и вы понимаете, как нынешние пользователи используют это приложение, переписывание может быть быстрее и дешевле, когда 30% или более кода требуют изменений. (Это не означает «переписать все», это может также означать, что приложение будет сокращено до логического уровня, а затем добавлен новый слой представления поверх него)
Предполагается, что вы перейдете на рефакторинг:
Определите свои цели Зачем вам вообще нужен рефакторинг приложения? У веских причин может быть много новых функций, которые нужно реализовать, слой презентации нужно заменить, или глючить, чтобы оставаться в здравом уме. Исходя из этого, решите, что нужно изменить, а что может остаться таким, как есть.
Вы уже выбрали свою цель: MV *. Я просто хочу, чтобы вы подумали о преимуществах для клиента и владельца кода в долгосрочной перспективе.
Прочитайте код . Нет, действительно, не торопитесь, чтобы привыкнуть к основам кода. Пройдите через это с помощью отладчика. Постарайтесь понять, что происходит. Делайте заметки об улучшениях, которые, по вашему мнению, вы должны сделать.
Создать тесты - в основном регрессионные тесты для желаемого в данный момент поведения. С устаревшими базами кода они чаще всего ручные, поэтому создайте протоколы испытаний, которым может следовать идиот, и попытайтесь заполучить не столь идиот, которые могут время от времени запускать эти тесты для вас. Попробуйте получить варианты использования от существующих пользователей.
Придерживайтесь небольших, обратимых изменений Если этап рефакторинга идет не так, он должен быть достаточно маленьким, чтобы его можно было отбросить без колебаний. Иногда это непросто, мои типичные шаги наихудшего случая:
- решить, какую функциональность заменить. Составьте план того, как должен выглядеть новый код.
- переместить существующий код за интерфейс, который также работает для нового кода
- тестовое задание
- заменить функциональность новым кодом
- тестовое задание
- иногда интерфейс является «окончательным», иногда вы можете удалить / уменьшить его
Всегда улучшать Не принимать функциональные ошибки, которые «могут быть исправлены позже».