Что такое увлечение метриками кода? [закрытый]
в последнее время я видел ряд вопросов, связанных с "метриками кода", и должен задаться вопросом, Что такое очарование? Вот несколько недавних примеров:
- какие метрики кода убеждают вас, что предоставленный код дерьмовый
- Если когда-либо количество строк кода является полезной метрикой
- написание тестов качества
на мой взгляд, никакая метрика не может заменить анализ кода, но:
- некоторые показатели иногда могут укажите места, которые необходимо пересмотреть, и
- радикальные изменения в метриках за короткие промежутки времени могут указывать на места, которые необходимо пересмотреть
но я не могу придумать ни одной метрики, которая сама по себе всегда указывает на "хороший" или "плохой" код - всегда есть исключения и причины для вещей, которые измерения не могут видеть.
есть ли какое-то волшебное понимание, которое можно получить из метрик кода, которые я пропустил? Ленивые программисты / менеджеры ищут для оправданий не читать код? Люди представлены с гигантскими устаревшими кодовыми базами и ищут место для начала? Что происходит?
Примечание: я задал некоторые из этих вопросов по конкретным темам как в ответах, так и в комментариях и не получил ответов, поэтому я подумал, что должен спросить сообщество в целом, поскольку, возможно, мне чего-то не хватает. Было бы неплохо запустить пакетное задание метрик и на самом деле не читать код других людей (или мой собственный) когда-либо снова, я просто не думаю, что это так практично!
EDIT: я знаком с большинством, если не со всеми обсуждаемыми метриками, я просто не вижу смысла в их изоляции или в качестве произвольных стандартов качества.
18 ответов:
ответы в этой теме довольно странные, поскольку они говорят о:
- "команда", как "один и единственный бенефициар" из этих указанных показателей;
- "метрики", как будто они что-то значат сами по себе.
1 / метрика не для один населения, но для три:
- разработчики: они обеспокоены мгновенностатические метрики кода что касается статики анализ их кода (цикломатическая сложность, качество комментариев, количество линий ...)
- руководители проектов: они обеспокоены ежедневнотекущий код метрики исходя из модульного теста, покрытия кода, непрерывного тестирования интеграции
- спонсоры бизнеса (они всегда забываются, но они являются заинтересованными сторонами, которые платят за развитие): они обеспокоены еженедельноглобальные метрики кода в отношении архитектурное проектирование, безопасность, зависимости ...
все эти показатели могут быть просмотрены и проанализированы всеми тремя популяциями, конечно, но каждый вид предназначен для лучшего использования каждой конкретной группой.
2/ метрики сами по себе представляют собой снимок кода, а это значит... ничего!
Это сочетание этих показателей и комбинаций тех различных уровней анализа, которые могут указывать "хорошей" или "плохой" код, но что более важно, это тенденция этих показателей это важно.
Что это повторение из тех метрик, которые дадут реальную добавленную стоимость, так как они помогут бизнес-менеджерам/руководителям проектов/разработчикам приоритеты среди различных возможных исправлений кода
другими словами, ваш вопрос о " очаровании метрики" может ссылаться на разницу между:
- "красивый" код (хотя это всегда в глазах смотрящего-кодера)
- "хороший" код (который работает, и может доказать, что это работает)
но, если:
- последняя функция имеет стабильный сложность в сочетании с охват кода 95%,
- в то время как бывший имеет повышение сложность в сочетании с покрытие... 0%,
кто-то может возразить:
- последний представляет собой "хороший" код (он работает, он стабилен, и если его нужно изменить, можно проверить, если он все еще работает после изменений),
- бывший "плохо" код (он все еще должен добавить некоторые случаи и условия, чтобы покрыть все, что он должен сделать, и нет простого способа сделать некоторый регрессионный тест)
Итак, подведем итоги:
одна метрика, которая сама по себе всегда указывает [...]
: не много, за исключением того, что код может быть более" красивым", что само по себе не означает много...
есть ли какое-то магическое понимание, которое можно получить от метрики кода, которые я пропустил?
только сочетание и тенденция метрики дают реальную "магическую проницательность", которую вы ищете.
У меня был проект, который я сделал как работа одного человека, измеренная для цикломатической сложности несколько месяцев назад. Это было мое первое знакомство с такими метриками.
первое сообщение, которое я получил, было шокирующим. Почти все мои функции не прошли тест, даже (imho) очень простые. Я обошел проблему сложности, переместив логическую подзадачу в подпрограммы, даже если они были вызваны только один раз.
для другой половины процедур моя гордость как программист пнул и я попытался переписать их таким образом, чтобы они делали то же самое, просто проще и читабельнее. Это сработало, и я смог максимально приблизиться к порогу сложности клиентов yclomatic.
в конце концов я почти всегда был в состоянии придумать лучшее решение и гораздо более чистый код. Производительность от этого не пострадала (поверьте - я параноик по этому поводу, и проверяю разборку вывода компилятора довольно часто).
Я думаю, что метрики-это хорошо если вы используете их в качестве причины / мотивации для улучшения вашего кода. Однако важно знать, когда остановиться и попросить грант на нарушение метрики.
метрики-это руководства и помощь, а не самоцель.
лучшая метрика, которую я когда-либо использовал, - это оценка C. R. A. P. 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) - покрытие тестового кода, обеспечиваемое автоматизированными тестами.авторы вышеупомянутой статьи (пожалуйста, иди почитай it...it ' s well worth your time) предложите максимальную оценку C. R. A. P. 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.для большинства моих команд разработчиков я очень старался получить оценку C. R. A. P. ниже 8, но если у них были веские причины для обоснования дополнительной сложности, которая была приемлемой, если они покрывали сложность достаточными тестами. (Написание сложного кода всегда очень трудно проверить...своего рода скрытая выгода для этой метрики).
большинству людей было трудно изначально написать код,который прошел бы оценку C. R. A. P. Но со временем они написали лучший код, код, который имел меньше проблем, и код, который был намного легче отлаживать. Из любой метрики, это тот, который имеет наименьшее количество проблем и наибольшую выгоду.
для меня самой важной метрикой, которая идентифицирует плохой код, является цикломатическая сложность. Почти все методы в моих проектах ниже CC 10, и ошибки неизменно встречаются в устаревших методах с CC более 30. Высокий CC обычно указывает:
- код написан в спешке (т. е. не было времени найти элегантное решение и не потому что проблема требовала сложного решения)
- непроверенный код (никто не пишет тесты для таких зверей)
- код, который был исправлено и исправлено много раз (т. е. пронизанный комментариями ifs и todo)
- - главная цель для рефакторинга
хороший обзор кода не заменяет хороший инструмент статического анализа, который, конечно же, не заменяет хороший набор модульных тестов, теперь модульные тесты не годятся без набора приемочных тестов......
метрики кода-это еще один инструмент для размещения в вашем ящике инструментов, они не являются решением сами по себе, они просто инструмент, который можно использовать по мере необходимости (конечно, со всеми другими инструментами в вашем ящике!).
мое весьма субъективное мнение заключается в том, что метрики кода выражают непреодолимое институциональное увлечение возможностью количественной оценки чего-то изначально не поддающегося количественной оценке.
имеет смысл, в некотором смысле, по крайней мере психологически - как вы можете принимать решения о том, что вы не можете оценить или понять? В конечном счете, конечно, вы не можете оценить качество, если вы не знаете о предмете (и, по крайней мере, так же хорошо, как то, что вы пытаетесь оценить) или спросить кого-то кто хорошо осведомлен, что, конечно, просто ставит проблему на один шаг назад.
в этом смысле, возможно, разумная аналогия будет оценивать абитуриентов колледжа по баллам SAT, это несправедливо и пропускает все виды тонкости, но если вам нужно количественно оценить, вы должны что-то сделать.
не говорю, что я думаю, что это хорошая мера, только то, что я вижу конституционную неотразимость этого. И, как вы указали, есть, вероятно, несколько разумных показателей (много 500 + line методы , высокая сложность-наверное, плохо). Хотя я никогда не был в месте,которое купилось на это.
есть одна метрика кода, в которую я верю.
Я работаю над большой системой. Когда ко мне приходит одно новое требование, я начинаю его кодировать. Когда я закончу и разберусь с ошибками, я проверю его в системе управления версиями. Эта система делает разницу и подсчитывает все изменения, которые я сделал.
чем меньше это число, тем лучше.
людей привлекает идея механистических способов понимания и описания кода. Если это правда, подумайте о последствиях для эффективности и производительности!
Я согласен, что метрика для "кодовой доброты" примерно так же разумна, как метрика для "хорошей прозы"."Однако это не означает, что метрики бесполезны, просто, возможно, неправильно.
например, экстрим значения для некоторых метрик указать путь возможных проблем. Метод длиной в 1000 строк это наверное unmaintainable. Код с нулевым покрытием кода единичного теста наверное больше ошибок, что подобный код с большим количеством тестов. Большой скачок в коде, добавленном в проект непосредственно перед выпуском, который не является сторонней библиотекой, - это наверное поводом для дополнительного внимания.
Я думаю, что если мы используем метрики в качестве предложения-красный флаг-возможно, они могут быть полезны. Проблема в том, когда люди начинают измерять производительность в SLOC или качество в процент строк с тестами.
метрики и автоматические тесты не предназначены для замены полных обзоров кода.
Они просто ускоряют процесс. С помощью автоматической проверки очень легко увидеть, какие соглашения вы забыли соблюдать, что вы используете назначенные пакеты и методы и т. д. Вы можете увидеть, что вы можете исправить, не используя время других людей.
менеджеры также любят метрики их, потому что они чувствуют, что они получают точную цифру по производительности (хотя это часто не так действительно так) и они должны уметь лучше жонглировать людьми.
измерения полезны только в том случае, если:
- команда разработала их
- команда согласилась на них
- Они используются для определения конкретной области
В общем, любая метрика, которая не вписывается в это, будет страдать от оптимизации команды. Вы хотите измерить строки кода? Черт возьми, посмотрите, сколько они могут написать! Вы хотите измерить покрытие кода, черт возьми, смотрите, как я покрываю этот код!
Я думаю, что метрики могут полезно для определения тенденций, и на самом деле, я видел некоторые полезные, такие как построение графиков при разрывах сборки, отток кода (количество строк кода, изменяющихся по всему проекту) и другие вещи. Но если команда не подходит с ними, или они не согласны или не понимают их, вы, вероятно, в мире больно.
вот некоторые метрики сложности из stan4j(http://stan4j.com/).
инструмент анализа структуры класса eclipse.
Мне нравится этот инструмент и метрики. Я рассматриваю метрики как статистику, индикаторы, предупреждающие сообщения. Когда-то из-за некоторых методов или некоторых классов действительно есть какая-то сложная логика сделала их сложными, что должно быть сделано, это следить за ними, просмотрите их, чтобы узнать, есть ли необходимость в их рефакторинге или внимательно просмотрите их, из-за того, что обычно они склонны к ошибкам. Также я использую его в качестве инструмента анализа для изучения исходного кода, потому что мне нравится учиться от сложного к простому.На самом деле он включает в себя некоторые другие метрики, такие как Robert C. Martin Metrics,Chidamber & Kemerer Metrics, Count Metrics Но этот мне нравится больше всего
Метрики Сложности
Цикломатическая Сложность Метрики
цикломатическая сложность (CC) Цикломатическая сложность метода-это число точки принятия решений в графе потока управления метода увеличиваются на единицу. Точки принятия решений возникают в операторах if/for/while, предложениях case/catch и аналогичных элементах исходного кода, где поток управления не просто линейный. Количество точек принятия решений (байтовый код), введенных одним оператором (исходный код), может варьироваться, например, в зависимости от сложности булевых выражений. Чем выше значение цикломатической сложности метода, тем больше тестовых случаев требуется для проверки всех ветвей метода. график потока управления метода.
Средняя Цикломатическая Сложность Среднее значение метрики цикломатической сложности для всех методов приложения, библиотеки, дерева пакетов или пакета.
Жир Показатели Метрика Fat артефакта - это число ребер в соответствующем графе зависимостей артефакта. Тип графа зависимостей зависит от варианта метрики и выбранного артефакта:
жир Показатель жира дерево приложений, библиотек или пакетов-это число ребер его графа зависимостей поддерева. Этот график содержит все дочерние элементы артефакта в иерархии дерева пакетов, включая также конечные пакеты. (Чтобы увидеть соответствующий график в представлении композиция, необходимо отключить переключатель плоские пакеты обозревателя структур. Переключатель показать библиотеки должен быть включен, если выбранный артефакт является библиотекой, в противном случае он должен быть отключен.)
тучная метрика пакета число ребер графа единичных зависимостей. Этот график содержит все классы верхнего уровня пакета.
Метрика Fat класса-это число ребер его графа-члена. Этот график содержит все поля, методы и классы-члены класса. (Этот график и значение Fat доступны только в том случае, если анализ кода был выполнен с элементом уровня детализации, а не с классом.)
Fat для библиотечных зависимостей (Fat - библиотеки) Жир для библиотечных зависимостей метрика приложения-это число ребер графа зависимостей библиотеки. Этот график содержит все библиотеки приложения. (Чтобы увидеть соответствующий график в представлении композиция, необходимо включить переключатель показать библиотеки обозревателя структур.)
Fat для плоских зависимостей пакетов (Fat - Packages) Метрика Fat for Flat Package Dependencies приложения - это число ребер его графа зависимостей плоского пакета. Этот график содержит все пакеты приложение. (Чтобы увидеть соответствующий график в представлении композиция, необходимо включить переключатель плоские пакеты обозревателя структур и отключить переключатель показать библиотеки.)
метрика Fat for Flat Package Dependencies библиотеки - это число ребер ее графа зависимостей плоского пакета. Этот график содержит все пакеты библиотеки. (Чтобы увидеть соответствующий график в представлении "композиция", переключатели плоских пакетов и библиотек Show Explorer должны быть включен.)
Fat для зависимостей класса верхнего уровня (Fat - Units) Метрика Fat for Top Level Class Dependencies приложения или библиотеки-это число ребер ее графа единичных зависимостей. Этот график содержит все классы верхнего уровня приложения или библиотеки. (Для разумных приложений он слишком велик для визуализации и, следовательно, не может отображаться в представлении композиции. Графики зависимости единиц измерения могут отображаться только для пакетов.)
метрики могут быть полезны для определения улучшения или ухудшения в проекте и, безусловно, могут найти нарушения стиля и конвенции, но нет никакой замены для проведения экспертных обзоров кода. Вы не можете знать качество вашего кода без них.
Я согласен с вами, что метрики кода не должны заменять обзор кода, но я считаю, что они должны дополнять обзоры кода. Я думаю, что это возвращается к старой поговорке: "вы не можете улучшить то, что вы не можете измерить."Метрики кода могут предоставить команде разработчиков количественные "запахи кода" или шаблоны, которые могут потребовать дальнейшего изучения. Метрики, которые фиксируются в большинстве инструментов статического анализа, обычно являются метриками, которые были определены в ходе исследования в короткая история нашей области имеет большое значение.
метрики не заменяют обзор кода, но они намного дешевле. Они являются индикатором больше, чем что-либо.
одна часть ответа заключается в том, что некоторые метрики кода могут дать вам очень быстрый, первоначальный удар по ответу на вопрос: каков этот код?
даже "строки кода" могут дать вам представление о размере базы кода, на которую вы смотрите.
Как уже упоминалось в другом ответе, тренд метрик дает вам больше информации.
метрики сами по себе не особо интересны. Важно то, что ты с ними делаешь.
например, если бы вы измеряли количество комментариев в строке кода, что бы вы сочли хорошим значением? Кто знает? Или, что еще более важно, у каждого есть свое мнение.
теперь, если вы соберете достаточно информации, чтобы иметь возможность сопоставить количество комментариев в строке кода с временем, затраченным на устранение ошибок или с количеством ошибок найдя то, что приписывается кодированию, то можно начать искать эмпирически полезное число.
нет никакой разницы между использованием метрик в программном обеспечении и использованием любого другого показателя производительности в любом другом процессе - сначала вы измеряете, затем анализируете, а затем улучшаете процесс. Если все, что вы делаете измерение, вы тратите свое время.
edit: в ответ на комментарии Стивена А. Лоу - это абсолютно правильно. В любом анализе данных нужно быть осторожным различать причинно-следственные связи и простое соотношение. И выбор метрик на основе пригодности имеет важное значение. Нет смысла пытаться измерить потребление кофе и приписать качество кода (хотя я уверен, что некоторые пытались ; -))
но прежде чем вы сможете найти связь (причинную или нет), вы должны иметь данные.
выбор данных для сбора основан на том, что процесс, который вы хотите проверить или улучшить. Например, если вы пытаетесь проанализировать успешность ваших процедур проверки кода (используя свое собственное определение для "успеха", будь то сокращение ошибок или сокращение ошибок кодирования, или более короткое время выполнения или что-то еще), затем вы выбираете метрики, которые измеряют общую скорость ошибок и скорость ошибок в проверенном коде.
поэтому, прежде чем собирать данные, вы должны знать, что вы хотите с ним делать. Если метрика-это средство, то какова цель?
Я не думаю, что небольшие изменения в метриках имеют смысл: функция со сложностью 20 не обязательно чище, чем функция со сложностью 30. Но стоит запустить метрики, чтобы искать большие различия.
однажды я обследовал пару десятков проектов, и один из проектов имел максимальное значение сложности около 6000, в то время как каждый другой проект имел значение около 100 или меньше. Это ударило меня по голове, как бейсбольная бита. Очевидно, что-то необычное, и наверное, плохо, что шел этот проект.