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

Question

Я недавно наблюдал за interesting talk о том, как часть Лаборатории реактивного движения делает свой обзор кода.

По существу они имеют инструмент (Scrub), что:

1. прогонов различные анализаторы кода на код
2. Спички проблемное линию против застройщика, который совершил
3. Создает задание/ошибка для этого разработчика ,

Затем разработчик может:

а) согласен (исправить эту проблему - она ​​уходит) б) не согласен с) Обсудить

инструмент хранит след всех разговоров. Затем на своих еженедельных встречах они обсуждают только Не согласны/Обсудите элементов.

Мне было интересно, если кто-нибудь сталкивался с подобным инструментом в Java?

Например, я могу использовать Sonar для анализа кода, но нет возможности автоматически создавать задачи или отслеживать цифровые разговоры.

Любые предложения приветствуются! Спасибо.

Answer 1

Существует Crucible от Atlassian, но это платная.

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Обновление:

сонара 2.8 и 2.9 добавили функциональные возможности, чтобы вручную вызвать отзывы от Sonar. http://www.sonarsource.org/sonar-2-8-in-screenshots/ http://www.sonarsource.org/sonar-2-9-in-screenshots/

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

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

сонар 3.1 добавило точку расширения для связи внешнего отслеживания нарушений сонара & обзора процесса (feature details).

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

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

Answer 8

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

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

Answer 9

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

What is the fascination with code metrics?

Также в этом сообщении. Есть рекомендации других людей о кодовых метриках.

Answer 10

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

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

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

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

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