Поддержка показателей кода с помощью тематических исследований

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

В ряде исследований изучалась корреляция цикломатической сложности с количеством дефектов, содержащихся в модуле. Большинство таких исследований обнаруживают сильную положительную корреляцию между цикломатической сложностью и дефектами: модули, которые имеют наивысшую сложность, как правило, также содержат наибольшее количество дефектов. Например, в исследовании 2008 года, проведенном поставщиком программного обеспечения для мониторинга показателей Enerjy, были проанализированы классы приложений Java с открытым исходным кодом и разделены на два набора в зависимости от того, насколько часто в них обнаруживаются ошибки. Они обнаружили сильную корреляцию между цикломатической сложностью и их неисправностью: классы с комбинированной сложностью 11 имеют вероятность быть подверженными сбоям всего 0,28, повышаясь до 0,98 для классов со сложностью 74.

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

Я также нашел статью на сайте IBM, который способствует мониторингу значений CC, но не имеет поддержки тематических исследований, показывающих показатели рентабельности инвестиций. Затем есть статья Coding Horror о "коде стрелки" который размещает краткое изложение тематического исследования, но не предлагает ни самих тематических исследований, ни фактических цифр, обосновывающих вывод:

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

Конечно, цикломатическая сложность (CC) поможет определить стрелочный код, но мне все еще нужны тематические исследования, которые показывают значения ROI. Например, «организация X включила максимум 10 CC для методов / функций и уменьшила количество дефектов на 20% в следующей итерации разработки».

Без таких данных трудно привлечь внимание руководства. Может ли кто-нибудь указать мне на несколько серьезных исследований? Даже один мог бы помочь ...


refactoring code-metrics coding-style language-agnostic complexity-theory
person Brent Arias    schedule 21.07.2010    source источник
comment
См. Также Чем привлекают метрики кода ?: stackoverflow.com/questions/195887/   -  person VonC    schedule 21.07.2010

Ответы (3)


arrow_upward
0
arrow_downward

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

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

Также стоит отметить, что те же люди, которые проводили исследование, постоянно обновляли index на большое количество open-source проектов. Если вы хотите получить больше надежных данных, вы можете проверить их индекс по журналам системы управления версиями для некоторых из этих проектов, вы, вероятно, могли бы использовать их данные, чтобы получить больше в виде прямых результатов типа ROI. Однако одно замечание: их индекс основан на довольно многих показателях исходного кода, не только на цикломатической сложности, поэтому я не уверен, что именно он мог бы сказать исключительно о CC, в отличие от других показателей. они смотрят.

person Jerry Coffin    schedule 21.07.2010
comment
Забавно, вы заставили меня снова взглянуть на ссылки в Википедии, и я заметил, что неправильно интерпретировал числа. Это не вероятность X дефектов, это вообще вероятность дефектов. Читая таким образом, учеба намного интереснее. - person Brent Arias; 22.07.2010
comment
@jerry, вы знаете обновленные ссылки на оригинальную статью, технические и индексные статьи? Они не работали по состоянию на 20.11.2014. Спасибо, - person Ricardo; 21.11.2014

arrow_upward
1
arrow_downward

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

Почему так сложно окупить инвестиции?

Вот почему.

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

http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx

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

«Без таких данных трудно привлечь внимание руководства».

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

Вы должны проводить собственные эксперименты над собственным кодом в своей организации.

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

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

person S.Lott    schedule 21.07.2010
comment
Я склонен думать, что ваш ответ общий - он, возможно, применим почти ко всему в разработке программного обеспечения. Иначе говоря, процесс не заменяет талант. - person Brent Arias; 21.07.2010

arrow_upward
1
arrow_downward

Вот некоторые из объектно-ориентированных показателей:

  1. Оптимальный размер класса для объектно-ориентированного программного обеспечения,
  2. Прогнозирование ремонтопригодности с помощью объектно-ориентированных показателей - эмпирическое сравнение,
  3. Эмпирический анализ показателей CK для сложности объектно-ориентированного дизайна: последствия для дефектов программного обеспечения
person kc2001    schedule 08.08.2010