Чем увлекаются метрики кода?
В последнее время я видел несколько вопросов, связанных с "метриками кода" на SO, и мне интересно, что же это за увлечение? Вот несколько недавних примеров:
- какие метрики кода убеждают вас, что предоставленный код является дрянным
- когда, если когда-либо, число строк кода является полезной метрикой
- написание тестов качества
На мой взгляд, ни одна метрика не может заменить обзор кода, хотя:
- некоторые показатели иногда могут указывать места, которые необходимо пересмотреть, и
- радикальные изменения в метриках за короткие промежутки времени могут указывать места, которые необходимо пересмотреть
Но я не могу думать об одной метрике, которая сама по себе всегда указывает на "хороший" или "плохой" код - всегда есть исключения и причины для вещей, которые измерения не могут увидеть.
Есть ли какое-то волшебное понимание, которое можно получить из метрик кода, которые я пропустил? Неужели ленивые программисты / менеджеры ищут оправдания не читать код? Люди знакомятся с гигантскими базами кода и ищут место для старта? В чем дело?
Примечание. Я задавал некоторые из этих вопросов в конкретных темах как в ответах, так и в комментариях и не получил ответов, поэтому я подумал, что мне следует задать вопрос сообществу в целом, так как, возможно, я что-то упустил. Было бы неплохо запустить пакетное задание по метрикам, и на самом деле не нужно больше читать код других людей (или мой собственный), я просто не думаю, что это практично!
РЕДАКТИРОВАТЬ: Я знаком с большинством, если не со всеми обсуждаемыми метриками, я просто не вижу их смысла в отдельности или в качестве произвольных стандартов качества.
18 ответов
Ответы в этой теме довольно странные, поскольку они говорят о:
- "команда", как "единственный бенефициар" из указанных показателей;
- "метрики", как будто они что-то значат в себе.
1 / Показатели не для одной популяции, а для трех:
- разработчики: они заинтересованы в мгновенных статических метриках кода относительно статического анализа их кода (цикломатическая сложность, качество комментариев, количество строк, ...)
- руководители проектов: они занимаются ежедневными показателями живого кода, полученными в результате модульного тестирования, покрытия кода, непрерывного тестирования интеграции
- бизнес-спонсоры (о них всегда забывают, но они являются заинтересованными сторонами, платящими за разработку): их интересуют еженедельные глобальные метрики кода, касающиеся архитектурного проектирования, безопасности, зависимостей,...
Все эти метрики, конечно, могут просматриваться и анализироваться всеми тремя группами населения, но каждый вид предназначен для лучшего использования каждой конкретной группой.
2 / Метрики сами по себе представляют собой снимок кода, а это значит... ничего!
Это комбинация этих метрик и комбинаций тех разных уровней анализа, которые могут указывать на "хороший" или "плохой" код, но, что более важно, это тенденция этих метрик, которая имеет значение.
Это повторение этих метрик, которые дадут реальную добавленную стоимость, поскольку они помогут менеджерам бизнеса / руководителям проектов / разработчикам расставить приоритеты среди различных возможных исправлений кода.
Другими словами, ваш вопрос о "увлеченности метриками" может относиться к разнице между:
- "красивый" код (хотя это всегда в глазах смотрящего кодера)
- "хороший" код (который работает и может доказать, что он работает)
Так, например, функция с цикломатической сложностью 9 может быть определена как "красивая", в отличие от одной длинной извилистой функции с цикломатической сложностью 42.
Но если:
- последняя функция имеет постоянную сложность в сочетании с охватом кода 95%,
- тогда как первый имеет возрастающую сложность в сочетании с охватом... 0%,
можно поспорить:
- последний представляет "хороший" код (он работает, он стабилен, и если его нужно изменить, можно проверить, работает ли он после модификаций),
- первый - "плохой" код (ему все еще нужно добавить некоторые случаи и условия, чтобы покрыть все, что он должен делать, и нет простого способа сделать некоторый регрессионный тест)
Итак, подведем итог:
единственная метрика, которая сама по себе всегда указывает [...]
: не так много, разве что код может быть более "красивым", что само по себе ничего не значит...
Есть ли какое-то волшебное понимание, которое можно получить из метрик кода, которые я пропустил?
Только комбинация и тенденция метрик дают реальную "магическую проницательность", к которой вы стремитесь.
У меня был проект, который я выполнял как работу одного человека, измеренную по цикломатической сложности несколько месяцев назад. Это было мое первое знакомство с такими показателями.
Первый отчет, который я получил, был шокирующим. Почти все мои функции не прошли тест, даже (imho) очень простые. Я справился со сложностью, переместив логическую подзадачу в подпрограммы, даже если они были вызваны только один раз.
Для другой половины рутины моя гордость как программиста началась, и я попытался переписать их так, чтобы они делали то же самое, просто проще и удобочитаемее. Это сработало, и я смог максимально приблизиться к порогу yclomatic сложности клиентов.
В конце концов я почти всегда мог придумать лучшее решение и намного более чистый код. Производительность от этого не пострадала (поверьте - я параноик по этому поводу и проверяю разборку выходных данных компилятора довольно часто).
Я думаю, что метрики - это хорошая вещь, если вы используете их в качестве причины / мотивации для улучшения вашего кода. Однако важно знать, когда остановиться и попросить грант за нарушение метрики.
Метрики - это руководство и помощь, а не самоцель.
Лучшая метрика, которую я когда-либо использовал, - это оценка CRAP. http://www.artima.com/weblogs/viewpost.jsp?thread=215899
По сути, это алгоритм, который сравнивает взвешенную цикломатическую сложность с автоматическим тестированием. Алгоритм выглядит так: CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)где comp (m) - цикломатическая сложность метода m, а cov (m) - охват кода теста, предоставляемый автоматическими тестами.
Авторы вышеупомянутой статьи (пожалуйста, прочитайте ее... она того стоит) предлагают максимальный балл CRAP 30, который разбивается следующим образом:
Method’s Cyclomatic Complexity % of coverage required to be
below CRAPpy threshold
------------------------------ --------------------------------
0 – 5 0%
10 42%
15 57%
20 71%
25 80%
30 100%
31+ No amount of testing will keep methods
this complex out of CRAP territory.
Как вы быстро видите, метрическая система поощряет написание не сложного кода в сочетании с хорошим тестовым покрытием (если вы пишете юнит-тесты, и вы должны это делать, а не измеряете охват... ну, вам, вероятно, понравится плевать на ветер также).;-)
Для большинства моих команд разработчиков я очень старался получить балл CRAP ниже 8, но если у них были веские причины, чтобы оправдать добавленную сложность, которая была приемлемой, если они покрывали сложность достаточным количеством тестов. (Написание сложного кода всегда очень трудно проверить... своего рода скрытая выгода для этой метрики).
Большинству людей изначально было сложно писать код, который будет соответствовать баллу CRAP. Но со временем они написали лучший код, код, в котором было меньше проблем, и код, который было намного легче отлаживать. Из любой метрики это та, которая имеет меньше всего проблем и приносит наибольшую пользу.
Для меня самым важным показателем, который идентифицирует плохой код, является цикломатическая сложность. Почти все методы в моих проектах ниже CC 10, и ошибки неизменно обнаруживаются в устаревших методах с CC более 30. Высокий CC обычно указывает на:
- код, написанный на скорую руку (т. е. не было времени, чтобы найти элегантное решение, а не потому, что проблема требовала сложного решения)
- непроверенный код (никто не пишет тесты для таких зверей)
- код, который был исправлен и исправлен много раз (т. е. пронизан комментариями ifs и todo)
- главная цель для рефакторинга
Хороший анализ кода не заменит хорошего инструмента статического анализа, который, конечно, не заменит хороший набор модульных тестов, теперь модульные тесты не годятся без набора приемочных тестов......
Метрики кода - это еще один инструмент для вставки в ваш ящик для инструментов, они сами по себе не являются решением, они просто инструмент, который нужно использовать по мере необходимости (конечно же, со всеми другими инструментами в вашем ящике!).
Есть одна метрика кода, в которую я верю.
Я работаю над большой системой. Когда ко мне приходит одно новое требование, я приступаю к его кодированию. Когда я закончу и исправлю ошибки, я проверю это в системе контроля версий. Эта система выполняет различие и подсчитывает все сделанные мной изменения.
Чем меньше это число, тем лучше.
Людей привлекает идея механистических способов понимания и описания кода. Если это правда, подумайте о последствиях для эффективности и производительности!
Я согласен, что метрика для "хорошего кода" примерно такая же разумная, как метрика для "хорошей прозы". Однако это не означает, что метрики бесполезны, просто могут быть использованы неправильно.
Например, экстремальные значения для некоторых показателей указывают путь к возможным проблемам. Метод длиной в 1000 строк, вероятно, не поддерживается. Код с нулевым охватом кода тестового модуля, вероятно, содержит больше ошибок, чем аналогичный код с большим количеством тестов. Большой скачок в коде, добавленном в проект незадолго до релиза, который не является сторонней библиотекой, вероятно, требует дополнительного внимания.
Я думаю, что если мы используем метрики в качестве предложения - красный флаг - возможно, они могут быть полезны. Проблема в том, что люди начинают измерять производительность в SLOC или качество в процентах строк с тестами.
Мое весьма субъективное мнение состоит в том, что метрики кода выражают непреодолимую институциональную привлекательность способности количественно оценить что-то по своей природе не поддающееся количественному определению.
В каком-то смысле это имеет смысл, по крайней мере, психологически - как вы можете принимать решения по поводу того, что вы не можете оценить или понять? В конечном счете, конечно, вы не можете оценить качество, если вы не обладаете знаниями о предмете (и, по крайней мере, так же хорошо, как то, что вы пытаетесь оценить) или не спросите кого-то, кто обладает знаниями, что, конечно, просто ставит проблему обратно один шаг.
В этом смысле, возможно, разумной аналогией будет оценка абитуриентов по баллам SAT, это несправедливо и не учитывает все тонкости, но если вам нужно количественно оценить, нужно что-то делать.
Не говоря о том, что я думаю, что это хорошая мера, только то, что я вижу ее неотразимость. И, как вы указали, вероятно, есть несколько разумных метрик (много 500+ линейных методов, высокая сложность, вероятно, плохая). Я никогда не был в месте, которое купилось на это, хотя.
Метрики и автоматизированные тесты не заменят полные обзоры кода.
Они просто ускоряют процесс. С помощью автоматической проверки очень легко увидеть, какие соглашения вы забыли соблюдать, что вы используете назначенные пакеты и методы и т. Д. Вы можете увидеть, что вы можете исправить, не используя чужое время.
Менеджерам также нравится их метрика, потому что они чувствуют, что получают точную цифру производительности (хотя это часто не так), и они должны быть в состоянии жонглировать людьми лучше.
Вот некоторые метрики сложности от stan4j(http://stan4j.com/).
Инструмент анализа структуры классов затмения.
Мне нравится этот инструмент и метрики. Я рассматриваю метрики как статистику, индикаторы, предупреждающие сообщения. Иногда из-за того, что некоторые методы или классы действительно имеют сложную логику, они становятся сложными, что нужно сделать, это следить за ними, проверять их, чтобы увидеть, есть ли необходимость в их рефакторинге или внимательно их пересматривать, в связи с они подвержены ошибкам. Также я использую его в качестве инструмента анализа для изучения исходного кода, потому что мне нравится учиться от сложного к простому. На самом деле он включает в себя некоторые другие метрики, такие как метрики Роберта С. Мартина, метрики Чидамбера и Кемерера, метрики графа Но мне больше всего нравится этот
Метрики сложности
Методы цикломатической сложности
Цикломатическая сложность (ЦК) Цикломатическая сложность метода - это число точек принятия решения в графе потока управления метода, увеличенное на единицу. Точки принятия решения возникают в операторах if/for/while, предложениях case/catch и аналогичных элементах исходного кода, где поток управления не просто линейный. Количество точек принятия решений (байт-кода), представленных одним оператором (исходного кода), может варьироваться, в зависимости, например, от сложности логических выражений. Чем выше значение цикломатической сложности метода, тем больше тестовых случаев требуется для проверки всех ветвей графа потока управления метода.
Средняя цикломатическая сложность Среднее значение показателя цикломатической сложности по всем методам приложения, библиотеки, дерева пакетов или пакета.
Метрики жира Метрика жира артефакта - это количество ребер в соответствующем графе зависимостей артефакта. Тип графа зависимостей зависит от варианта метрики и выбранного артефакта:
Fat Метрика Fat дерева приложения, библиотеки или пакета - это число ребер графа зависимостей поддерева. Этот граф содержит все дочерние элементы артефакта в иерархии дерева пакетов, включая также листовые пакеты. (Чтобы увидеть соответствующий график в представлении "Композиция", необходимо отключить переключатель "Плоские пакеты" в Проводнике структуры. Переключатель "Показать библиотеки" должен быть включен, если выбранный артефакт является библиотекой, в противном случае он должен быть отключен.)
Метрика Fat пакета - это число ребер графа зависимостей модуля. Этот график содержит все классы верхнего уровня пакета.
Метрика Fat класса - это число ребер в графе его членов. Этот граф содержит все поля, методы и классы членов класса. (Этот график и значение Fat доступны только в том случае, если анализ кода выполнялся с элементом уровня детализации, а не с классом.)
Жир для библиотечных зависимостей (Жир - библиотеки) Метрика Жир для библиотечных зависимостей приложения - это число ребер в графе зависимостей библиотеки. Этот график содержит все библиотеки приложения. (Чтобы увидеть соответствующий график в представлении "Композиция", необходимо включить переключатель "Показать библиотеки" в проводнике структуры.)
Жир для зависимостей плоских пакетов (Fat - пакеты) Метрика зависимостей Fat для плоских пакетов приложения - это число ребер в графе зависимостей плоского пакета. Этот график содержит все пакеты приложения. (Чтобы увидеть соответствующий график в представлении "Композиция", необходимо включить переключатель "Плоские пакеты" в Проводнике структуры и отключить переключатель "Показать библиотеки".)
Показатель Fat for Flat Package Dependencies библиотеки - это число ребер графа зависимостей плоского пакета. Этот график содержит все пакеты библиотеки. (Чтобы увидеть соответствующий график в представлении "Композиция", необходимо включить переключатели "Плоские пакеты" и "Показать библиотеки" проводника структуры.)
Жир для зависимостей класса верхнего уровня (Fat - Units) Метрика Fat для зависимостей класса верхнего уровня приложения или библиотеки является счетчиком ребер в его графе зависимостей. Этот график содержит все классы верхнего уровня приложения или библиотеки. (Для приемлемых приложений он слишком велик, чтобы его можно было визуализировать, и поэтому его нельзя отобразить в представлении "Состав". Графики зависимостей модулей могут отображаться только для пакетов.)
Измерения полезны только если:
- Команда разработала их
- Команда согласилась с ними
- Они используются для определения конкретной области
В общем, любая метрика, которая не вписывается в это, пострадает от оптимизирующей команды. Вы хотите измерить строки кода? Черт возьми, смотри сколько они могут написать! Вы хотите измерить охват кода, черт возьми, смотри, как я покрываю этот код!
Я думаю, что метрики могут быть полезны для определения тенденций, и на самом деле, я видел некоторые полезные, такие как построение графиков, когда ломается сборка, отток кода (количество строк кода, изменяющихся в проекте) и другие вещи. Но если команда не подходит к ним, или они не соглашаются или не понимают их, вы, вероятно, в мире боли.
Я не думаю, что небольшие изменения в метриках имеют смысл: функция со сложностью 20 не обязательно чище, чем функция со сложностью 30. Но стоит искать метрики, чтобы искать большие различия.
Однажды я исследовал пару десятков проектов, и один из проектов имел максимальную ценность сложности около 6000, в то время как каждый другой проект имел ценность около 100 или меньше. Это ударило меня по голове, как бейсбольная бита. Очевидно, что в этом проекте происходило что-то необычное и, возможно, плохое.
Одна часть ответа заключается в том, что некоторые метрики кода могут дать вам очень быстрый начальный ответ на вопрос: на что похож этот код?
Даже "строки кода" могут дать вам представление о размере кодовой базы, на которую вы смотрите.
Как уже упоминалось в другом ответе, тренд метрик дает вам больше информации.
Метрики сами по себе не особо интересны. То, что вы делаете с ними, имеет значение.
Например, если бы вы измеряли количество комментариев на строку кода, что бы вы посчитали хорошим значением? Кто знает? Или, что еще важнее, у каждого свое мнение.
Теперь, если вы соберете достаточно информации, чтобы иметь возможность сопоставить количество комментариев на строку кода с временем, затраченным на устранение ошибок, или с количеством найденных ошибок, связанных с кодированием, тогда вы можете начать находить эмпирически полезное число,
Нет разницы между использованием метрик в программном обеспечении и использованием любого другого показателя производительности в любом другом процессе - сначала вы измеряете, затем анализируете, а затем улучшаете процесс. Если все, что вы делаете, это измерения, вы тратите свое время.
редактировать: в ответ на комментарии Стивена А. Лоу - это абсолютно правильно. При любом анализе данных необходимо тщательно различать причинно-следственную связь и простую корреляцию. И выбор метрик на основе пригодности важен. Нет смысла пытаться измерить потребление кофе и приписать качество кода (хотя я уверен, что некоторые пытались;-))
Но прежде чем вы сможете найти отношения (причинно или нет), вы должны иметь данные.
Выбор данных для сбора зависит от того, какой процесс вы хотите проверить или улучшить. Например, если вы пытаетесь проанализировать успешность ваших процедур проверки кода (используя свое собственное определение для "успеха", будь то уменьшение ошибок или уменьшение ошибок в кодировании, или более короткое время выполнения или что-то еще), тогда вы выбираете показатели, которые измеряют общая частота ошибок и частота ошибок в проверенном коде.
Поэтому, прежде чем собирать данные, вы должны знать, что вы хотите с ними делать. Если метрика является средством, каков конец?
Я согласен с вами, что показатели кода не должны заменять проверку кода, но я считаю, что они должны дополнять проверки кода. Я думаю, что это возвращается к старой поговорке, что "вы не можете улучшить то, что вы не можете измерить". Метрики кода могут предоставить команде разработчиков поддающиеся количественной оценке "запахи кода" или шаблоны, которые могут потребовать дальнейшего изучения. Метрики, которые фиксируются в большинстве инструментов статического анализа, как правило, являются метриками, которые были определены в ходе исследований в краткой истории нашей области, чтобы иметь значительное значение.
Метрики могут быть полезны для определения улучшения или ухудшения в проекте, и, конечно, могут найти нарушения стиля и соглашения, но ничто не заменит выполнение рецензирования кода. Вы не можете знать качество вашего кода без них.
Ох... и это предполагает, что по крайней мере один из участников вашего обзора кода имеет подсказку.
Метрики не являются заменой для проверки кода, но они намного дешевле. Они показатель больше всего на свете.
Мы программисты. Нам нравятся цифры.
Кроме того, что вы собираетесь делать, НЕ описывать размер кодовой базы, потому что "строки метрик кода не имеют значения"?
Существует определенная разница между кодовой базой из 150 строк и одной из 150 миллионов, чтобы привести глупый пример. И это не трудно получить число.