Рефакторинг старого кода C в дизайн MVC

Question

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

Существующий код довольно запутанный и свободно перемежает логику GUI с бизнес-логикой и логикой доступа к данным.Единственное, что спасает, это то, что это НЕ спагетти-код, и что он модульный (как это обычно бывает с кодом 70-х годов).

Мой вопрос таков: может ли кто-нибудь дать мне руководство о том, какприступить к рефакторингу кода в MVC (кстати, я также перемещаю код с C на C ++, выполняя эту задачу - но это меньше всего меня беспокоит, так как я довольно разборчив в обоих языках).

BTWЯ полностью осознаю, что это не тривиальная задача.Я просто хочу знать, каковы шаги от перехода от модульного кода, который смешивает DBAL / BL / GUI к более чистой реализации MVC.

Answer 1

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

Я согласен с @Jesus Ramos, что выяснение стратегии тестированияключ здесь.Вероятно, проблема для вас заключается в том, что код в настоящее время не может быть проверен модулем, потому что фактически нет «модулей», мы не можем проверить бизнес-логику, скажем, без тестирования пользовательского интерфейса.

IЯ бы очень серьезно подумал о переписывании этой вещи, а не о рефакторинге.

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

Answer 2

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

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

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