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

Question

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

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

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

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

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

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

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

Редактировать:Я добавлю к этому два детектора мертвого кода : UCD и DCD

Answer 1

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

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

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

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

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

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

Ты не хочешь переписывать?

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

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

Answer 2

На самом деле они не будут платить за полное переписывание, потому что :

• Это рецессия, затраты на то, чтобы вы переписали ее с нуля, будут высокими

• Возможно, они пытаются продать компанию как можно скорее

• Руководство ничего не понимает в разработке программного обеспечения

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Обновить:

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