Как лучше всего перенести существующее грязное веб-приложение на элегантный MVC?

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

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

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

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

Это сложнее сделать в приложениях, которые находятся только в режиме обслуживания, потому что трудно убедить руководство в том, что стоит переписать то, что уже «работает». Я бы начал с применения принципов MVC к любому новому коду, над которым вы можете работать (т.е. переместите бизнес-логику во что-то похожее на модель, поместите весь код макета / представления в одно место)

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

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

Лучше всего распечатать код, скомкать и выбросить. Даже не перерабатывайте бумагу.

У вас есть приложение, написанное на JSP длиной более 1000 строк. У него, вероятно, есть ужасная модель предметной области (если она вообще есть), и она не просто СМЕШАЕТ презентацию с бизнес-логикой, она СМЕШАЕТ ее, сидит там и продолжает перемешиваться часами. Невозможно извлечь дрянной код и перейти в класс контроллера MVC и при этом продолжать делать правильные вещи, вы просто получите приложение MVC с анемичной моделью домена или с такими вещами, как вызовы базы данных в коде контроллера вы все еще терпите неудачу.

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

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

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

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

При рефакторинге обратите внимание на части, которые пытаются получить доступ к ресурсам, не предоставленным странице, и попытайтесь передать это контроллеру. Например, все, что обращается к базе данных, должно находиться внутри контроллера, пусть JSP обрабатывает отображение информации, которую контроллер передает ему через пересылку. Таким образом вы разработаете несколько сервлетов или что-то вроде сервлетов для каждой страницы. Я бы предложил использовать для этого рефакторинга фреймворк на основе фронт-контроллера (из личного опыта я рекомендую Spring и его интерфейс контроллера), чтобы каждый контроллер не был отдельным сервлетом, а скорее делегировался из одного сервлета, который отображается соответствующим образом.

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

Я чувствую вашу боль и желаю удачи в этом начинании. Теперь, когда вам нужно поддерживать приложение, которое злоупотребляет Spring Webflow, это уже другая история :)