Какие метрики полезны для исходного кода? [закрыто]

Какие метрики полезны для сбора исходного кода?

Как метрики, такие как, например, (исполняемые?) Строки кода или Cyclomatic Complexity, могут помочь в обеспечении качества или как они в целом полезны для процесса разработки программного обеспечения?

«Измерение производительности программного обеспечения по строкам кода похоже на измерение прогресса на самолете по его весу», - Билл Гейтс.

Посмотрите на сообщения Джеффа на эту тему:

Посещение горничной Метрики

Программная инженерия: мертв?

Есть старая, но хорошая статья от Джоэла, тесно связанная с метриками программного обеспечения, и я настоятельно рекомендую ее прочитать: Метод управления Econ 101

Ключевой момент для меня заключается в том, чтобы процитировать Джеффа: «Ответственное использование метрик так же важно, как и их сбор в первую очередь».

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

Строки кода: как я уже говорил, это жизненно важное измерение, и к нему следует относиться очень серьезно, но на каждом уровне. Функции, классы, файлы и интерфейсы могут указывать на универсальный код, который сложно поддерживать и который является дорогостоящим в долгосрочной перспективе. Сравнивать количество строк кода с тем, что делает система, бесконечно сложно. Это может быть что-то, что делает много вещей, и в этом случае будет много строк кода!

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

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

Графики зависимостей Поиск плохих и циклических зависимостей является важным измерением в коде. Это почти всегда указывает на неправильный дизайн высокого уровня, который нуждается в пересмотре. Иногда одна зависимость может поглощать множество ненужных других, потому что кто-то использует addNumber внутри библиотеки электронной почты для выполнения своих финансовых расчетов. Все шокированы, когда библиотека электронной почты меняется, а финансы ломаются. Если все зависит от одной вещи, это также может указывать на все библиотеки, которые трудно поддерживать и плохо спроектированы.

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

Не будет ли это дерьмо "метрики исходного кода" когда-либо умирать?

Необработанные строки исходного кода (SLOC) - это самая старая, самая простая и самая базовая метрика.

Холстед первоначально предложил целую кучу метрик. Многие люди получали массу удовольствия от написания программ измерения до тех пор, пока какой-то спорспорт не провел очевидное исследование и не продемонстрировал, что каждая метрика Хэлстеда напрямую связана с SLOC.

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

Метрики исходного кода для обеспечения качества направлены на две цели:

• написание кода с меньшим количеством ошибок внутри
• написание кода для простоты обслуживания

Оба приводят к написанию кода настолько просто, насколько это возможно Это означает:

• короткие единицы кода (функции, методы)
• несколько элементов в каждом блоке (аргументы, локальные переменные, операторы, пути)
• и многие другие критерии, более или менее сложные (см. Метрика программного обеспечения в Википедии).

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

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

Одна вещь, которую я хотел бы сделать, - это запустить номера для разных проектов, над которыми я работаю - Test Coverage :: kLOC, а затем обсудить «воспринимаемое качество», чтобы увидеть, есть ли корреляция.

Метрики полезны, только если вы знаете, что делать с полученными ответами. По сути, метрика программного обеспечения похожа на термометр. Тот факт, что вы измеряете что-то при температуре 98,6 ° F, ничего не значит, пока вы не узнаете, какова нормальная температура. Вышеуказанная температура хороша для температуры тела, но очень плоха для мороженого

Общие метрики, которые могут быть полезны:

• Обнаруженные ошибки / неделя
• Устраненные ошибки / неделя
• # Требования определены / выпуск
• # Требования выполнены / релиз

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

Цикломатическая сложность - интересная метрика. В своей базовой концепции это количество уникальных путей выполнения в функции / методе. В сложной среде модульных тестов это соответствует количеству тестов, необходимых для проверки каждого пути выполнения. Тем не менее, тот факт, что у вас есть метод с цикломатической сложностью 96, не означает, что это обязательно глючный код, или что вы должны написать 96 тестов, чтобы обеспечить разумную уверенность. Сгенерированный код (с помощью генераторов синтаксических анализаторов или WPF) нередко создает нечто сложное. Это может дать приблизительное представление об уровне усилий, необходимых для отладки метода.

Нижняя граница

Каждое измерение, которое вы проводите, должно иметь следующее определение, или оно бесполезно:

• Понимание того, что "нормально". Это может быть скорректировано в течение всего срока проекта.
• Порог за пределами «нормального», где вам нужно предпринять какое-то действие.
• План работы с кодом при превышении порога.

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

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

Исходный код является обязательством, а не активом. Имея это в виду, измерение строк кода аналогично отслеживанию долларов, потраченных на строительство дома. Это необходимо сделать, если вы хотите остаться в рамках бюджета, но вы не обязательно думаете, что тратить 1000 долларов в день лучше, чем тратить 50 долларов в день; Вы хотели бы знать, сколько дома построено за эти деньги. То же самое и со строками кода в программном проекте.

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

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

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

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

За наши усилия в 2000 году (рассказывает, как давно это было :)) мы провели большую очистку раздела кода, за который отвечала моя команда. В итоге мы выпустили около 30 000 строк кода, неплохие 3 месяца работы для 5 человек. В итоге мы также удалили еще 70 000 строк кода - очень хорошая работа за 3 месяца работы, особенно в сочетании с новым кодом.

Конечный результат за квартал: -40.000 строк кода. В ходе обзора производительности, следующего за кварталом, мы получили официальный выговор от компании за то, что мы не выполнили наши требования к производительности в 20 000 строк кода, производимых за квартал (в конце концов, инструменты показали, что мы произвели -40 000 строк кода), что привело бы к тому, что все мы были бы перечислены как неэффективные и обойденные для продвижения по службе, обучения, повышения заработной платы и т. д. и т. д., если бы менеджер проекта и команда QA не вмешались и не отменили выговор и не заменили его похвалой.

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

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

Покрытие кода полезно в том смысле, что вы знаете, какой процент приложений не терпит неудачу катастрофически; В остальном его полезность зависит от качества юнит-тестов.

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

Пока без коммита нарушается сборка ...

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

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

Я часто работаю над гигантским C ++-пакетом, и при поиске проблемного кода, заслуживающего рефакторинга Cyclomatic Complexity или ужасного FanIn / FanOut , обычно достаточно хороших красных флагов. Исправление проблем обычно приводит к улучшению всей кодовой базы.

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

На моей работе много ситуаций, когда я использую метрики кода:

При написании кода

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

Разработчики могут свободно нарушать все правила, поскольку они никогда не будут применяться ко всем ситуациям. «Правила» существуют для того, чтобы стимулировать мысль и сказать: «Эй, это лучший способ сделать это?»

Во время проверки качества кода

Первое, что я обычно делаю, когда выполняю проверку кода, это проверяю покрытие кода проверяемым кодом в сочетании с инструментом покрытия кода, который выделяет, какие строки кода были покрыты. Это дает мне общее представление о том, насколько тщательным является тестовый код. Мне действительно все равно, если покрытие составляет 20% или 100%, если важный код хорошо протестирован. Таким образом, покрываемый процент несколько бессмыслен, но 0% наверняка выделяется, как больной палец, как то, на что я хочу внимательно посмотреть

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

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

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

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

В: Какие метрики полезны для сбора исходного кода?

Для бизнеса:

A: Количество человеко-часов

Для руководителя кодера:

A: не имеет значения. Давайте сделаем все сегодня

Для самооценки кодера:

A: Количество SLOC (исходных строк кода)

Для мамы кодера:

A: Ешьте больше этих мягких французских булочек и пейте чай

продолжение в комментариях ниже ...

Помните: весь код может быть уменьшен как минимум на 1 инструкцию. Весь код содержит как минимум 1 ошибку. Следовательно, весь код может быть сведен к одной инструкции, которая не работает. Надеюсь, это поможет!