Что привлекает в метриках кода? [закрыто]

В последнее время я видел несколько вопросов, связанных с «метриками кода», на SO, и мне интересно, что это за очарование? Вот несколько недавних примеров:

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

На мой взгляд, никакая метрика не может заменить обзор кода:

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

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

Можно ли получить какое-то волшебное представление о метриках кода, которые я упустил? Ленивые программисты / менеджеры ищут оправдания, чтобы не читать код? Представляют ли люди гигантские устаревшие кодовые базы и ищут ли с чего начать? Что происходит?

Примечание: я задавал некоторые из этих вопросов в конкретных темах как в ответах, так и в комментариях, но не получил ответов, поэтому я подумал, что должен спросить сообщество в целом, поскольку, возможно, я что-то упускаю. Было бы неплохо запустить пакетное задание метрик и больше никогда не читать чужой (или свой собственный) код, я просто не думаю, что это практично!

РЕДАКТИРОВАТЬ: Я знаком с большинством, если не со всеми обсуждаемыми метриками, я просто не вижу в них смысла изолированно или как произвольные стандарты качества.

Ответы в этой цепочке выглядят довольно странно, поскольку они говорят о:

• «команда», как «единственный бенефициар» этих указанных показателей;
• «метрики», как будто они что-то значат сами по себе.

1 / Показатели не для одной группы населения, а для трех :

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

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

2 / Метрики сами по себе представляют собой снимок кода, а это значит ... ничего!

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

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

Другими словами, ваш вопрос о «привлекательности показателей» может относиться к разнице между:

• "красивый" код (хотя это всегда в глазах смотрящего-кодера)
• "хороший" код (который работает и может доказать, что работает)

Так, например, функция с цикломатической сложностью 9 может быть определена как «красивая», в отличие от одной длинной запутанной функции с цикломатической сложностью 42.

Но если:

• последняя функция имеет постоянную сложность в сочетании с охватом кода 95%,
• тогда как первый имеет возрастающую сложность в сочетании с охватом ... 0%,

можно было бы возразить:

• последний представляет собой " хороший " код (он работает, он стабилен, и если его нужно изменить, можно проверить, работает ли он по-прежнему после изменений),
• первый - " плохой " код (ему все еще нужно добавить несколько случаев и условий, чтобы охватить все, что он должен делать, и нет простого способа сделать какой-нибудь регрессионный тест)

Итак, подведем итог:

единственная метрика, которая сама по себе всегда указывает [...]

: не много, разве что код может быть "красивее", что само по себе не много значит ...

Можно ли получить какое-то волшебное представление о показателях кода, которые я упустил?

Только сочетание и тенденция показателей дает настоящее «волшебное представление», которое вам нужно.

Несколько месяцев назад у меня был проект, который я выполнял в одиночку, измеряя цикломатическую сложность. Это было мое первое знакомство с такими метриками.

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

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

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

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

Метрики - это руководство и помощь, а не самоцель.

Лучшая метрика, которую я когда-либо использовал, - это оценка CRAP. .

По сути, это алгоритм, который сравнивает взвешенную цикломатическую сложность с автоматическим тестовым покрытием. Алгоритм выглядит так: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 обычно означает:

• код, написанный на скорую руку (т.е. не было времени найти элегантное решение, а не потому, что проблема требовала комплексного решения)
• непроверенный код (на таких зверей никто не пишет тесты)
• код, который многократно исправлялся и исправлялся (т.е. пронизан комментариями if и todo)
• главная цель для рефакторинга

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

Метрики кода - это еще один инструмент, который можно поместить в ящик для инструментов, они не являются самостоятельным решением, они просто инструмент, который нужно использовать по мере необходимости (конечно, со всеми другими инструментами в вашем ящике!).

Людей привлекает идея механистических способов понимания и описания кода. Если это правда, подумайте о последствиях для эффективности и производительности!

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

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

Я думаю, что если мы будем использовать метрики в качестве предложения - красного флажка - возможно, они могут быть полезны. Проблема в том, когда люди начинают измерять производительность в SLOC или качество в процентах строк с тестами.

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

В некотором смысле имеет смысл, по крайней мере, с психологической точки зрения - как вы можете принимать решения по тому, что вы не можете оценить или понять? В конечном итоге, конечно, вы не можете оценить качество, если вы не разбираетесь в предмете (и по крайней мере так хорошо, как то, что вы пытаетесь оценить) или спросите кого-то, кто осведомлен, что, конечно же, просто решит проблему. один шаг.

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

Я не говорю, что считаю это хорошей мерой, только то, что я вижу внутреннюю непреодолимость этого. И, как вы отметили, вероятно, есть несколько разумных показателей (множество методов из 500+ строк, высокая сложность - вероятно, плохая). Однако я никогда не был в месте, которое бы купилось на это.

Я верю в одну метрику кода.

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

Чем меньше это число, тем лучше.

Метрики и автоматические тесты не предназначены для замены полной проверки кода.

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

Менеджерам также нравятся метрики, потому что они чувствуют, что получают точные данные о производительности (хотя на самом деле это часто не так), и они должны уметь лучше манипулировать людьми.

Измерения полезны, только если:

• Команда их разработала
• Команда с ними согласилась
• Они используются для определения конкретной области

В общем, любая метрика, которая не вписывается в нее, пострадает от оптимизации команды. Вы хотите измерить строки кода? Черт возьми, посмотрите, сколько они могут написать! Вы хотите измерить покрытие кода, черт возьми, смотрите, как я покрываю этот код!

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

Вот несколько показателей сложности из stan4j .

Инструмент для анализа структуры классов eclipse.

Мне нравится этот инструмент и его показатели. Я отношусь к метрикам как к статистике, индикаторам, предупреждающим сообщениям. Иногда из-за того, что некоторые методы или классы действительно имеют сложную логику, делающую их сложными, нужно следить за ними, просматривать их, чтобы увидеть, есть ли необходимость в их рефакторинге или внимательно их проверять, поскольку обычно они подвержены ошибкам. Также я использую его как инструмент анализа для изучения исходного кода, потому что мне нравится учиться от сложного к простому. На самом деле он включает в себя некоторые другие метрики, такие как метрики Роберта К. Мартина, метрики Чидамбера и Кемерера, метрики подсчета, но мне больше всего нравится этот

Метрики сложности

Цикломатические показатели сложности

Цикломатическая сложность (CC) Цикломатическая сложность метода - это количество точек принятия решения в графе потока управления метода, увеличенное на единицу. Точки принятия решения возникают в операторах if / for / while, предложениях case / catch и подобных элементах исходного кода, где поток управления не просто линейный. Число точек принятия решения (байтовый код), вводимых одним оператором (исходный код), может варьироваться, например, в зависимости от сложности логических выражений. Чем выше значение цикломатической сложности метода, тем больше тестовых примеров требуется для тестирования всех ветвей графа потока управления метода.

Средняя цикломатическая сложность Среднее значение метрики цикломатической сложности по всем методам приложения, библиотеки, дерева пакетов или пакета.

Жирные метрики Жирные метрики артефакта - это количество ребер в соответствующем графе зависимостей артефакта. Тип графа зависимостей зависит от варианта метрики и выбранного артефакта:

Fat Метрика Fat для дерева приложения, библиотеки или пакета - это количество ребер его графа зависимостей поддерева. Этот граф содержит все дочерние элементы артефакта в иерархии дерева пакетов, включая конечные пакеты. (Чтобы увидеть соответствующий график в представлении «Композиция», переключатель «Плоские пакеты» в обозревателе структуры должен быть отключен. Переключатель «Показать библиотеки» должен быть включен, если выбранный артефакт является библиотекой, в противном случае его необходимо отключить.)

Жирная метрика пакета - это количество граней его графа зависимостей. Этот график содержит все классы верхнего уровня пакета.

Жирная метрика класса - это количество ребер его графа-членов. Этот граф содержит все поля, методы и классы-члены класса. (Этот график и значение Fat доступны только в том случае, если анализ кода проводился с элементом с уровнем детализации, а не с классом.)

Жир для библиотечных зависимостей (Fat - библиотеки) Показатель «жирный для библиотечных зависимостей» приложения - это количество ребер его графа зависимостей библиотеки. Этот график содержит все библиотеки приложения. (Чтобы увидеть соответствующий график в представлении композиции, необходимо включить переключатель «Показать библиотеки» в обозревателе структуры.)

Жир для зависимостей плоских пакетов (Fat - Packages) Метрика приложения «Жир для зависимостей плоских пакетов» - это количество граней его плоского графа зависимостей пакетов. Этот график содержит все пакеты приложения. (Чтобы увидеть соответствующий график в представлении «Композиция», необходимо включить переключатель «Плоские пакеты» в Structure Explorer и отключить переключатель «Показать библиотеки».)

Метрика «Жирность для зависимостей плоских пакетов» библиотеки - это количество граней ее плоского графа зависимостей пакетов. Этот график содержит все пакеты библиотеки. (Чтобы увидеть соответствующий график в представлении композиции, необходимо включить переключатели Flat Packages и Show Libraries в Structure Explorer.)

Жир для зависимостей классов верхнего уровня (Fat - Units) Метрика Fat для зависимостей классов верхнего уровня приложения или библиотеки - это количество ребер его графа зависимостей модулей. Этот график содержит все классы верхнего уровня приложения или библиотеки. (Для разумных приложений он слишком велик для визуализации и, следовательно, не может отображаться в представлении композиции. Графики зависимости модулей могут отображаться только для пакетов.)

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

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

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

Метрики не заменяют обзор кода, но они намного дешевле. Они являются индикатором больше всего на свете.

Одна часть ответа состоит в том, что некоторые показатели кода могут дать вам очень быстрый первоначальный ответ на вопрос: что это за код?

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

Как упоминалось в другом ответе, тренд показателей дает вам больше всего информации.

Сами по себе показатели не особо интересны. Важно то, что вы с ними делаете.

Например, если бы вы измеряли количество комментариев на строку кода, что бы вы посчитали хорошим значением? Кто знает? Или, что еще более важно, у каждого свое мнение.

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

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

edit: В ответ на комментарии Стивена А. Лоу - это абсолютно правильно. При любом анализе данных нужно быть внимательным, чтобы различать причинную связь и простую корреляцию. И выбор показателей на основе пригодности важен. Нет смысла пытаться измерить потребление кофе и приписать качество кода (хотя я уверен, что некоторые пробовали ;-))

Но прежде чем вы сможете найти связь (причинную или нет), вы должны иметь данные.

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

Поэтому, прежде чем собирать данные, вы должны знать, что вы хотите с ними делать. Если метрики - это средство, то каков конец?

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

Однажды я изучал пару десятков проектов, и один из них имел максимальную сложность около 6000, в то время как каждый другой проект имел значение около 100 или меньше. Это ударило меня по голове, как бейсбольной битой. Очевидно, что с этим проектом происходило что-то необычное и, вероятно, плохое.

Мы программисты. Нам нравятся числа.

Кроме того, что вы собираетесь делать, НЕ описывать размер кодовой базы, потому что «строки показателей кода не имеют значения»?

Определенно есть разница между кодовой базой в 150 строк и одной из 150 миллионов, если взять глупый пример. И получить это число не сложно.