Комментарии 20
всё это здорово, но… хотябы несколько конкретных примеров и их метрики для сравнения…
Нуу… 15 сантиметров лучше чем 10… в некоторых ситуациях… :-).

В том-то и проблема, что к примеру размер функций (цикломатическая сложность кода) высчитать можно. Будет 73. А много это или мало? Ответа нет. Так что с примерами получается как раз не очень очевидно.

Другими словами посчитать можно много (количество классов, переменных и т.п.), а что с этим числом делать — никто не знает.
Думаю, метрика нужна для сравнения и т.п. Сама по себе может значить мало.
Все верно. Но если сравнить 10 и 15 сантиметров еще понятно как, то как сравнить цикломатическую сложность — большой вопрос. То есть да, мы понимаем, что одна функция сложнее другой. Но что с этим знанием сделать?
Например, на основе анализа сделать какие-то основания для направления рефакторинга (например, «с чего начать»))
Неплохой повод определить: кто из программистов работает над более сложным кодом. Или кому таковой дать на разработку.
Выступлю тут «адвокатом дьявола». Очевидно, что сложный код надо давать более «крутому» программисту. И не в метриках дело.

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

P.S. Я всего-лишь таким комментарием показываю противоречивость метрик. Я не против них.
Подобные метрики в первую очередь хороши в динамике. У меня на одном из проектов считались несколько из перечисленных метрик (я, как интегратор, отвеал за их автоматический сбор). Для той же цикломатической сложности был выведен определенный порог внутри организации. Для новых функций он не должен был превышать определенного значения. И что важнее — со временем сложность не должна была расти. Наоборот, с большой куче legacy-кода важно было эту сложность уменьшить. То есть именно диманика придавала смысл метрике.
В динамике также интересно смотреть и количество строк кода. Вот в продукт заинтегрировали новую большую фичу — и теперь посмотрим, сколько она добавила строк и как это повлияло на размер занимаемой памяти.

Однако следует сказать, что метрики — удел в первую очередь относительно больших проектов. Большинство же работая над небольшими направлениями, на метрики смотрят как на что-то громоздкое и ненужное. Вот, например, опрос по области моих интересов:
habrahabr.ru/blogs/pm/69536/
Хоть Хабр — сообщество разношерстное, однако результат очень показателен.
Подобные метрики в первую очередь хороши в динамике


абсолютно согласен.
Метрики сравнивать очень опасно. Особенно для разных проектов.
Сравните какой проект больше?
1) A — 5000 строк кода, B — 6000 строк кода
или
2) A — 500 классов, B — 300 классов

Метрики Холстеда — трижды опасный инструмент, т.к. был придуман еще во времена фортрана.
Метрики штука хорошая и важная, но, на мой взгляд, было бы гораздо интереснее ознакомиться со списком решений для их подсчета. Для популярных языков. Я вот, например, до сих пор не знаю решения дешевле 1000$ для подсчета цикломатической сложности кода на C++. Может, Вы знаете? :)
Представление формул у Вас ужасно, как будто заставляете читать книгу по матанализу в txt.
Метрики — опасное оружие. Это граната для обезьяны. Они убили больше проектов, чем способствовали развитию. Не давать в руки менеджеров, опасно!
Использование метрик в наказательных целях — опасно. Использование метрик в информационно-вспомогательных целях — полезно.
Но обезьянам не стоит давать гранату даже, если думаете, что она использует ее в информационно-вспомогательных целях.
ерунда какая-то
это на четвертом курсе преподают на предмете метрология, сертификация и стандартизация ПО
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
США
Сайт
www.intel.ru
Численность
5 001–10 000 человек
Дата регистрации

Блог на Хабре