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

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

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

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

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

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

Некоторые из рассматриваемых идей включают:

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

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

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

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

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

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


person kgrad    schedule 20.02.2009    source источник


Ответы (5)


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

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

person Morendil    schedule 20.02.2009

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

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

person matt b    schedule 20.02.2009

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

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

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

  • Делайте рефакторинг небольшим

  • Делайте один рефакторинг за раз

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

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

  • ...

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

person eljenso    schedule 20.02.2009

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

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

person Eric Petroelje    schedule 20.02.2009

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

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

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

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