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

Question

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

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

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

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

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

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

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

Answer 1

Вот некоторые для объектно-ориентированных метрик:

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

Answer 2

"... Мне все еще нужны тематические исследования, которые показывают значения ROI."

Почему ROI такой жесткий?

Вот почему.

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

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

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

"Без данных такого рода этотрудно заставить руководство заботиться. "

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

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

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

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

Answer 3

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

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

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