Какой лучший подход при проверке большого веб-приложения java/j2ee

Мне нужно провести аудит большого веб-приложения Java/J2ee, которое эволюционировало по нескольким года. Это было написано какой-то другой компанией, а не той, над которой я работаю. В нынешнее состояние стало трудно развиваться и поддерживать, новые функциональности трудно добавить и часто приводят к ошибкам, которые когда-либо появляются в производство. Кажется, что есть какой-то скопированный/вставленный код, который привел к дублированию кода. Текущее приложение - это своего рода интернет-магазин с каким-то cms-подобным контентом здесь и там. Это в основном Struts и некоторые Spring в новых частях кода, возможно, некоторые ejbs, которые были добавлены для хорошая мера. Есть некоторые модульные тесты, но их не так много. Это вещи, о которых мне сказали, я еще не видел фактического кода.

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

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

проверить "основные" вещи - обработка исключений, регистрация
проверьте уровень слоев (виды, контроллеры, слой dao).
измерять фактический охват модульных тестов
может быть запущен некоторый Checkstyle, Findbugs и PMD над проектами
...

Итак, реальный вопрос заключается в том, какие еще вещи следует принимать во внимание /check/measure/etc?

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

Я буду благодарен за любую идею, предложение, прокомментирую это.

Изменить: я добавлю в детектор два детектора кода: UCD и DCD

Ответ 1

У меня было два веб-приложения с аналогичными настройками. Я прекратил использовать FindBugs и Checkstyle, поскольку они показали более 10.000 проблемных точек. В приложениях используется доступ к данным уровня JDBC, JSP для презентации и пользовательская инфраструктура для отправки запросов. К счастью для меня, эти настройки низкого уровня позволили мне делать расширения и исправления на средней сложности. В течение 3-летнего проекта осталось около 20% исходного кода. Рано или поздно все остальное нужно было либо изменить, заменить или удалить (и, наконец, я смог использовать FindBugs и Checkstyle).

Мы тоже столкнулись с дилеммой полной перезаписи. Однако против него было несколько факторов:

Не уверен, что клиент оплатит полную переписку.
Отсутствие функциональной и технической документации позволяет рискованно выполнять полную переписку.
Человеческие часы, чтобы полностью понять полное приложение, были слишком высокими. Заказчик потребовал внесенные изменения раньше.
Пользователи, настроенные для представления и поведения страницы. Казалось, трудно убедить пользователей использовать новый интерфейс для старых функций.
Если мы сделаем полную переписку, нам необходимо предоставить полную документацию. Для обновления нам нужно было документировать только нашу часть.
Трудно убедить руководство (владельца и клиента) переписать, если программа работает (более или менее)
У компании были свои правила PMD, и код не прошел. Было проще утверждать, что достаточно пройти новые испытания.

Это сводится к тому, что вы хотите сделать на самом деле.

Вы хотите переписать, несмотря на сложность?

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

Вы не хотите переписывать?

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

Если вы хотите попробовать код, попробуйте добавить Hello World! функции/экрана для приложения. Это говорит о том, насколько сложно и насколько быстро вы можете внедрять новые вещи.

Ответ 2

Вы сосредотачиваетесь на ремонтопригодности и расширяемости, которые находятся на месте.

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

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

Ответ 3

Фактически они не будут платить за полную переписку, потому что:

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

Сначала я бы сказал несколько простых фактов:

Используйте инструмент для отображения SLOC проекта
Запуск, как вы планировали FindBugs и в конечном итоге PMD, просто оценить недостатки
Сделайте быстрый сеанс профилирования
Проверьте различные слои
Посмотрите, как обычно закрыты ресурсы (потоки, спящий режим или соединения JDBC и т.д.).
Посмотрите, используются ли технологии там, где они не применяются (EJB, веб-службы и т.д.).
Посмотрите, как они обрабатывают исключения и протоколирование
Посмотрите, есть ли слишком много или недостаточно абстракции.
Посмотрите, можете ли вы добавить некоторые базовые классы для уменьшения дублирования кода.

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

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

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

Ответ 4

Мне очень нравится ваш список. Я думаю, у вас есть отличный план атаки, чтобы начать.

Я бы посмотрел на стандартизацию на Spring или EJB 3.0, но не на обоих.

Я не читал его сам, но мне интересно, есть ли книга Майкла Перса "Эффективно работающая с устаревшим кодом" имеет хорошие идеи

UPDATE:

Возможно, вы можете помочь, поставив их на автоматическую сборку и непрерывную интеграцию - Cruise Control, Hudson или Team City. Если вам нужно сделать какой-либо рефакторинг, это поможет.