Как фундаментально перепроектировать систему, сохраняя при этом функциональное поведение?

Question

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

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

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

Спасибо!

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

Answer 1

IMHO Самое важное, что нужно сделать, это разработать множество хороших тестов, которые охватывали бы всю функциональность, которую вы хотите сохранить.

Я знаю, что письменные тесты чрезвычайно трудны в грязной кодовой базе, но это все еще возможно с помощью некоторых методов нарушения зависимости. Я бы порекомендовал "Working effectively with legacy code", так как это все о практической стороне рефакторинга.

Answer 2

Я бы полностью согласился с piotsrz's answer - хороший, комплексный набор модульных тестов - именно то, что вам нужно, чтобы помочь сохранить поведение при рефакторинге. Добавьте эти тесты в систему непрерывной интеграции, чтобы вы получали быструю обратную связь от каждой фиксации от каждого разработчика.

Другая полезная книга на эту тему: Refactoring to Patterns, которая описывает несколько итерационных методов архитектурных преобразований, которые сохраняют поведение.

Answer 3

Это очень больно, но первый большой вопрос: действительно ли вам нужно сделать эту перестройку? Если дизайн базы данных более или менее хорошо, вы можете вместо этого создать новый материал и оставить старое в покое? Каждый рефлекс жаждет убрать беспорядок, но с точки зрения бизнес-пользователя, какой уровень инвестиций необходим и какова окупаемость?

Вы уже определили итеративное изменение как подход. Для этого это означает, что в системе есть определенный уровень детализации, который позволяет вам изменять некоторые части, не затрагивая других. Предположительно, ваша идея доставляет некоторые новые бизнес-ценности и одновременно очищает часть приложения, эффективно амортизируя стоимость изменений во многих ценных продуктах, «налог на сбор мусора» при доставке новых вещей. Является ли этот «налог» приемлемым?

Поэтому я считаю, что предположение о гранулярности - это то, что вам нужно проверить. Определите небольшой кусочек. Попробуйте рефакторинг. Вы считаете, что это будет как отдельное изменение, как вы надеетесь? Была ли стоимость, как вы ожидали? и что важно ... какие там стороны? Существует некоторая вероятность того, что ваш код работает не так хорошо, как существующие хранимые процедуры. Развитие «налога» - это одно, а выполнение «налога» - это совсем другое дело.

Answer 4

Решайте бизнес-логику хранимых процедур и пользовательского интерфейса отдельно. И возьмите сначала SP.Поочередно:

• написать процедуру, которая вызывает СП
• тест чёрта из него
• перенаправить код с SUT для вызова этой процедуры вместо SP
• Написать бизнес-логики в этой процедуры (продолжение пройти все испытания, конечно)
• уронить SP

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

Я сторонник не, написание множества модульных тестов, а затем рефакторинг; скорее, тест-обложку кода, который будет реорганизован сегодня. Несколько модульных тестов, небольшой рефакторинг; пена, промыть, повторить. Вы можете прерывать в любое время и иметь лучшую систему, чем при запуске; нет большой задержки между проведением изменений и наблюдением за результатами.