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

Question

Я присоединился к новой компании около месяца назад. Компания довольно небольшая по размеру и имеет довольно сильный "стартап" чувствую к этому. Я работаю Java-разработчиком в команде из 3 человек. Компания в основном продает услугу бизнесу / людям бизнес-типа, чтобы использовать их в общении друг с другом.

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

Повторяющееся и растущее разочарование, которое я испытываю здесь (и я в целом доволен работой в целом, так что это не «о нет, мне не нравится мой пост») - это отсутствие любой большой дизайн или архитектура для этого веб-приложения. Приложение состоит из нескольких десятков JSP-страниц, и в Servlets, Beans или в любом другом фреймворке практически не существует логики. Многие страницы JSP состоят из тысяч строк кода, они jsp: include других страниц JSP, бизнес-логика смешана с HTML, часто используемые фрагменты кода (например, подключение к веб-службе) вырезать и вставлять, а не использовать повторно и т. д. Другими словами, приложение представляет собой беспорядок.

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

У вас есть приложение, написанное на JSP длиной более 1000 строк. Вероятно, у него ужасная модель предметной области (если она вообще есть), и она не просто представляет MIX-презентацию с бизнес-логикой, она ослепляет ее, сидит там и продолжает болтать часами. Невозможно извлечь код, который является дрянным, и перейти в класс MVC Controller, и при этом все еще делать правильные вещи, вы просто получите приложение MVC с моделью анемичного домена или приложение, имеющее такие вещи, как вызовы базы данных. в коде контроллера вы все еще терпите неудачу.

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

Answer 7

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

Answer 8

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

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

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

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