Что влияет на результат ремонтопригодности для Sonarqube?

Question

Я сталкиваюсь с огромным "кодом спагетти" с известным отсутствием документации, отсутствием покрытия тестами, высокой сложностью, отсутствием правил проектирования, которым необходимо следовать, и т. Д. Я позволил анализировать код с помощью сонарного сканирования по умолчанию, и на удивление для меня надежность обслуживания очень хорошая, техническая задолженность составляет 1,1%! Реальность показывает, что почти каждое изменение вносит новые ошибки

Я довольно озадачен, и мне интересно, могут ли некоторые особенности в реализации объяснить эту оценку... У нас, например, довольно много интерфейсов (например, 4-5 Интерфейсов для 1 реализации), используется шаблон рефлексии и поиска сервисов.

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

Answer 1

Рейтинг ремонтопригодности - это произведение предполагаемого времени на исправление всех проблем типа Code Smell в вашей кодовой базе и ожидаемого времени на написание кода в его текущем состоянии.

Вы также должны взглянуть на ошибки и уязвимости в коде базы.

Что касается ваших конкретных точек (и предположим, что мы говорим о Java):

• Известное отсутствие документации - в профиле по умолчанию есть правило, которое ищет Javadocs. Вы можете прочитать его описание и значения параметров, чтобы увидеть, что он делает и не находит.
• отсутствие тестового покрытия - в настоящее время в этом обнаружении есть "дыра"; если для класса нет покрытия, то этот класс не учитывается при вычислении линий, которые могут / должны быть покрыты, и, следовательно, при расчете процентов покрытия. Это должно быть исправлено "скоро". Первые шаги появятся на стороне платформы в 6.2, но для вступления в силу потребуются сопутствующие изменения в языковых плагинах.
• высокая сложность - для этого есть правила. Если они не находят то, что, по вашему мнению, они должны, посмотрите на их (регулируемые) пороги.
• отсутствие правил проектирования - единственное правило, которое может решить эту проблему (архитектурное ограничение),
  1. осуждается
  2. намечено для удаления
  3. не включен по умолчанию удалено из последних версий плагина
• использование отражения - в настоящее время нет доступных правил, чтобы обнаружить это