Анализ кода и назначение задачи в java

Ответ 1

Там Crucible от Atlassian, но это платная.

Ответ 2

Sonar 2.7 добавила дополнительную интеграцию с SCM, чтобы теперь вы могли видеть, какой разработчик последний раз коснулся конкретной строки кода. http://www.sonarsource.org/sonar-2-7-in-screenshots/

Хотя это ручной процесс, используя плагин Sonar Eclipse, можно быстро создайте задачу непосредственно из вида нарушения, щелкнув правой кнопкой мыши на нарушении, и некоторое поле ошибки будет предварительно заполнено. Надеемся, что будущие обновления плагина Sonar добавят последнюю коммиттер-информацию из SCM, чтобы заполнить назначенное поле в ошибке/задаче.

Update:

Sonar 2.8 и 2.9 добавили функциональность для ручного запуска обзоров сонара. http://www.sonarsource.org/sonar-2-8-in-screenshots/ http://www.sonarsource.org/sonar-2-9-in-screenshots/

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

Обновление 2:

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

Используя эту точку расширения, последний плагин JIRA (1.0) позволяет вам создать/связать проблему JIRA для нарушения, вызванного Sonar. Подробнее в проблема JIRA и информация о плагинах.

Я еще не видел планов по интеграции в другие системы отслеживания проблем.

Ответ 3

У нас есть довольно успешный процесс, который может делать то, что вы хотите.

У нас есть большое административное приложение, состоящее из примерно 20 + модулей.

• все под подрывной деятельностью (любой scm будет делать)
• каждое изменение кода должно проходить через Jira (но вы можете использовать что угодно, от богомола до bugzilla).
• вам нужно поставить idira jira в свои коммиты; блоки блокировки pre-commit фиксируют, кто этого не делает, поэтому все фиксации соответствуют правилу
• непрерывная интеграция Хадсона (опять же, вы можете использовать другие продукты)
• Разделы DEV/TEST/QA/PROD
• через пользовательские скрипты, hudson может принимать одну или несколько проблем jira, создавать патч и применять его к QA, компилировать и развертывать; PROD - это копия проверенного ветки QA (строгие правила проверки)
• настраиваемые поля в Jira, чтобы сделать процесс автоматическим: например, вы можете запустить патч, указав, что вы хотите его в Jira.

Было бы неплохо, если бы некоторые script проверяли последние билеты/коммиты, запускали PMD/Checkstyle/Findbugs и т.д. и открывали новые проблемы в Jira, когда это было необходимо (или добавляли какое-то настраиваемое значение поля на существующие билеты, вы решаете), Вы определяете правила для всего процесса, поэтому вы можете блокировать патчи или релизы на основе состояния проблемы с jira. Вы можете реализовать то, что хотите (и многое другое) таким образом.

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

Ответ 4

Другие упомянули Sonar, но никто, кажется, не объяснил, что, начиная с 2.8 Sonar теперь поддерживает обзоры кода вручную: http://docs.codehaus.org/display/SONAR/Manual+Reviews

В сочетании с плагином SCM это звучит очень близко к тому, что вы ищете.

Ответ 5

В моей новой компании мы начали использовать GitHub для проектов SCM. GitHub предоставляет замечательный интегрированный инструмент для проверки кода (на основе фиксации). Просто перейдите к любой фиксации и добавьте свой отзыв по строке, файлу или всей фиксации.

Ответ 6

Честно говоря, я очень удивлен тем, что никто не упомянул Review Board. Хотя это не инструмент анализа кода (но вы можете автоматически запускать PMD/CheckStyle/FindBugs), это позволит вам делать то, о чем вы просите.

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

В принципе, если бы я должен был создать процесс регистрации, я заставил бы всех пользователей запускать автоматические тесты (а не только модульные тесты, а также тесты пользовательского интерфейса и интеграции), FindBug и CheckStyle с выбранным набором правил, а затем, если это является чистым, код будет рассмотрен человеком (на данный момент он будет определенно синтаксически правильным и не будет вводить проблемы, но не обязательно иметь смысл) с Советом по обзору.

Ответ 7

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

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

Поэтому мне кажется, что для описанного процесса Scrub подходят только крошечные суммы точно правильных предупреждений анализатора кода (например, циклов пакетов):(

Поэтому я считаю, что лучшим решением является не полностью автоматизировать эту отчетность об ошибках, а решительно поддерживать обзоры кода, которые вручную также учитывают предупреждения анализаторов. Используя инструмент, в котором вы можете легко упаковать крошечные обзоры кода в проблемы, действительно помогает в этом. FogBugz делает это очень хорошо (см., Например, это видео: http://www.youtube.com/watch?v=r5HNI9aMzOE&feature=player_embedded).

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

Ответ 8

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

Ответ 9

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

В чем недостаток ReviewClipse отсутствует, это процесс/поддержка, что недостатки, обнаруженные в обзоре, будут не только записаны, но и действительно исправлены.

Ответ 10

Я однажды рекомендовал бесплатный инструмент анализа кода stan4j (http://stan4j.com/) в SO. Но его бесплатная версия сообщества поддерживает только 500 классов. Она не может выполнять назначение задачи, а только анализ кода.

Каково увлечение метриками кода?

Также в этом посте. Другие люди рекомендуют кодовые метрики.