Какую статистику собирает ваша компания для определения качества кода / программного продукта

Question

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

Однако большинство хороших программистов могут почувствовать качество, как только начинают вмешиваться в код. (Верно?)

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

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

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

Answer 1

Просто быстрое напоминание:

Качество кода:

• не определено по одному критерию: в качество кода вовлечено несколько групп людей: разработчики, руководители проектов и заинтересованные стороны , и все они должны видеть качество кода по-разному.

• определяется не одним числом из одной формулы, а трендом этого числа : «плохая» нота сама по себе ничего не значит, особенно если это устаревший код, но плохая заметка, которая становится все хуже ... это вызывает беспокойство;)

Answer 2

На одном сайте клиента мы использовали метрику CRAP, которая определяется как:

CRAP (м) = комп (м) ^ 2 * (1 - cov (м) / 100) ^ 3 + комп (м)

Где comp (m) - цикломатическая сложность данного метода, а cov (m) - уровень охвата модульных тестов для этого метода. Мы использовали NDepend и NCover, чтобы предоставить необработанную информацию для вычисления метрики. Это было полезно для поиска определенных областей кодовой базы, на которые следует обратить внимание. Кроме того, вместо того, чтобы указывать конкретное значение в качестве цели, мы стремились к улучшению с течением времени.

Не идеально, но все же полезно.