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

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

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

31 голос | спросил cschol 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

17 ответов


28

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
10

Взгляните на сообщения Джеффа по теме:

Посещение дежурной метрики

Software Engineering: Dead?

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
10

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

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

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

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

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
8

Не будет ли эта «исходная кодовая метрика» дерьмом EVER умирать?

Исходные строки кода (SLOC) - самая старая, самая простая, самая основная метрика.

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
7

Показатели исходного кода для обеспечения качества нацелены на достижение двух целей:

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

Оба приводят к простому написанию кода. Это означает:

  • короткие единицы кода (функции, методы)
  • несколько элементов в каждой единице (аргументы, локальные переменные, инструкции, пути)
  • и многие другие критерии более или менее сложны (см. Показатель программного обеспечения в Википедии).
ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
6

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

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
6

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

Полезными являются следующие метрики, которые могут :

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

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

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

Нижняя строка

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

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

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
5

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
3

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
3

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

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

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

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
2

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
1

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
1

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
1

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

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

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

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

Во время обзоров QA /Code

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

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

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

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
0

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

Пока никакая фиксация не прерывает сборку ...

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
0

Q: Каковы полезные показатели для захвата исходного кода?

Для бизнеса:

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

Для супервизора кодера:

A: Не важно. Давайте сделаем все сегодня

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

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

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

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

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55
-1

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

ответил 18 SatEurope/Moscow2010-12-18T06:37:55+03:00Europe/Moscow12bEurope/MoscowSat, 18 Dec 2010 06:37:55 +0300 2010, 06:37:55

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132