Обычные значения метрик кода (C #, Visual Studio) для производственных проектов

Question

Здесь есть несколько вопросов о метриках кода, особенно этот о значениях целей. Однако я ищу то, что «обычно» в реальных производственных проектах. Может быть, это только я, но ни один проект, над которым я когда-либо работаю, никогда не задумывался об этом, поэтому, когда я запускаю ReSharper Code Issues или Visual Studio Code Metrics, кажется, что я первый, поэтому значения всегда меня удивляют.

Примеры из моего текущего назначения SharePoint:

Maintainability | Cyclomatic cmplx. | Inher. depth | Class coupl. | LOC
67              | 6,712             | 7            | 569          | 21,649
68              | 3,192             | 7            | 442          | 11,873

Обновление: Итак, вопрос в том, какие значения вы обычно видите "в дикой природе"? Помимо оптимальных ценностей и передового опыта, какие ценности обычно встречаются?

Answer 1

Я предполагаю, что указанные значения находятся на уровне сборки. Если это так, Цикломатическая сложность и Строки кода являются наиболее полезными на уровне метода. Глубина наследования должна рассматриваться в первую очередь на уровне класса. Связывание классов дает более полезную обратную связь при поиске сначала на уровне метода, а затем на уровне класса.

В дополнение к рекомендациям, содержащимся в ссылке переполнения стека , которую вы включили, в Code Complete 2nd Edition есть то, что можно сказать о методе Cyclomatic Complexity, стр. 458:

• 0-5 Процедура, вероятно, в порядке.
• 6-10 Начните думать о том, как упростить рутину.
• 10 + Разбейте часть процедуры на вторую процедуру и вызовите ее из первой процедуры

В реальных проектах то, что приемлемо, вероятно, будет зависеть от типа процесса разработки, который вы используете. Если команда практикует TDD (разработку через тестирование) и стремится написать код SOLID , то эти показатели должны быть близки к оптимальным значениям.

Если TAD (тестирование после разработки) или, тем более, код без модульных тестов, то ожидайте, что все показатели будут выше оптимальных, так как вероятность наличия большей связности, более сложных методов и классов и, возможно, более продуктивных наследование может быть повышено. Тем не менее, цель должна заключаться в том, чтобы ограничить случаи наличия «плохих» метрик, независимо от того, как был разработан код.

Answer 2

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

Большинство людей использует следующий некорректный процесс:

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

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

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

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

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

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