Как провести аудит проекта Java EE?

Question

Я должен проверить качество и удобство сопровождения архитектуры кода (в конце концов, чтобы убедиться, что у нас есть то, за что мы заплатили) веб-проект Java EE, основанный на JSF / CDI / EJB3.0 / JPA (просто назвать несколько задействованных технологий).

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

Оцениваете ли вы все это (сборка, развертывание, тестирование)?

Answer 1

На более низком физическом уровне / уровне реализации мне нравится использовать maven в качестве инструмента сборки, а затем настраивать расширенные отчеты maven для создания веб-сайта, заполненного различными метриками кода.

• Для начала существует плагин maven checkstyle , который может сообщать о соответствии кода указанному стандарту, согласованность в стандартах кодирования имеет много очевидных преимуществ, большинство проектов просто примут один из предварительно настроенных стандартов, например, солнце или апач.
• Плагин findbugs перечисляет потенциальные ошибки программирования
• Существует выбор отчетов о покрытии кода, я использовал cobertura . Они показывают строку за строкой в ​​приложении, какие части покрыты модульными тестами. Maven поддерживает модульные тесты в жизненном цикле сборки, выполняя их как часть сборки. Это спасло меня несколько раз.
• Плагин PMD идентифицирует дублированный код и выделяет области, которые могут нуждаться в рефакторинге.

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

Многие из отчетов имеют пороговые пределы, которые могут быть настроены на сбой при сборке, если он нарушен, т. Е. Более n% ошибок в стиле проверки приводят к сбою сборки.

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

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

См. Некоторые примеры отчетов по этой ссылке
http://maven.apache.org/plugins/maven-dependency-plugin/project-reports.html

Answer 2

Чтобы помочь в аудите на уровне кода и, вероятно, в работоспособности проекта, можно также использовать одно программное обеспечение - SONAR ... очень просто настроить только некоторые команды maven, поставляется с множеством проверенных стандартов кода, таких как качество кода, возможность повторного использования, измерения плохой практики и так далее ...

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

Он также использует все те плагины maven и maven, перечисленные в другом ответе, как cobertura, поиск ошибок и т. Д. *

http://www.sonarsource.org/

Просто скачайте и укажите свой репо.

Answer 3

Чтобы понять вашу архитектуру, вы можете попробовать JavaDepend , которая дает возможность запрашивать код с CQL, например, SQL для базы данных, с более чем 82 метриками и множеством интерактивных представлений, чтобы углубиться в ваш дизайн, архитектуруи реализация.

Answer 4

Обязательно разбивайте его на проблемные области и обращайтесь к ним индивидуально.Области, о которых я могу подумать:

1. Соответствие указанным требованиям (надеюсь, они специфические)
2. Производительность / масштабируемость
3. Качество кода (включая требуемые соглашения)затем)
4. Тестовое покрытие
5. Лицензии плагинов / библиотек

Похоже, что другие обращались к пунктам 3 и 4. Поскольку вы задаете вопрос сейчас (предположительно)после того, как вы получили продукт) 1 и 2, вероятно, придется выполнять вручную, если у вас уже нет автоматизированных тестов функциональности (или вы хотите автоматизировать тесты, чтобы вы могли проверить будущие версии того, что вы купили).5 - элемент, который иногда упускают из виду, но может быть ОЧЕНЬ важным.Вы, вероятно, не хотите, чтобы код GPL был подключен, если вы собираетесь перепродавать это программное обеспечение.Вам необходимо просмотреть лицензии каждой включенной библиотеки и решить, какие из них соответствуют вашим целям.

Answer 5

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

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