Рекомендации по переносу устаревшего веб-приложения на современный фреймворк

Question

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

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

Они достигли точки, когда они рассматривают масштабное обновление системы. Они хотят улучшить удобство сопровождения базы кода и пытаются перейти на какое-то современное приложение типа фреймворк / MVC. Большая часть системы предшествует XHTML со встроенной стилистической разметкой, вызовами javascript: function (), никаким модульным тестированием, предшествует Hibernate и т. Д. Существует смесь генерации html out.println и вызова jsp из Servlet.

Некоторые приложения, которые они просматривали, включают Wicket, Struts, Tapestry и, возможно, Grails. Проблема в том, что переход к любому из них может потребовать огромного изменения системы, которая уже используется, и они не могут позволить себе начать заново.

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

Некоторые идеи, о которых идет речь, включают:

• написать собственную систему шаблонов, которая будет работать с их текущей инфраструктурой (генерировать страницы согласованным образом)

• код порта для фреймворка, такого как гобелен (многократное использование старого кода)

• переписать систему с нуля, используя современный фреймворк, но копируя логику из старой системы (если это возможно)

• сохранить старую систему как есть и просто обновить интерфейсные страницы, чтобы придать ей более современный вид (лучше всего, учитывая время / деньги и т. Д.)

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

Любое понимание приветствуется.

Answer 1

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

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

Answer 2

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

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

Answer 3

На этот вопрос нет четкого ответа, но мой главный совет - сначала прочитать тему . Читайте книги людей, которые знают, о чем говорят.

Например, Code Complete (Стив Макконнелл), гл. 24 Рефакторинг.

• Сохраните код, который вы начинаете с

• Хранить рефакторинги малыми

• Выполнение одного рефакторинга за раз

• Рефакторинг при добавлении подпрограммы, класса, исправлении дефекта

• Определить интерфейс между чистым и уродливым кодом

• ...

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

Answer 4

это только мое мнение, потому что я думаю, что этот вопрос заключается в том, за что люди платят дорогим консультантам за работу (и обычно заканчивают тем, что просто тратят деньги! См. Примеры на thedailywtf.com).

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

это может быть больно, но хорошее лекарство вредит.

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

Answer 5

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

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