Есть ли у bitrot принятые размеры?

Question

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

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

Какой анализ коммитов (комментарии коммитов (упомянутый ниже) или время между коммитами) являются достоверными данными для применения?

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

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

Answer 1

Очень интересный ход мыслей!

Во-первых, что является битротом? Статья Software Rot в Википедии собирает несколько пунктов:

• Изменение среды: изменения во время выполнения
• Неиспользуемый код: изменения в шаблонах использования
• Редко обновляемый код: изменения в процессе обслуживания
• Рефакторинг: способ борьбы с битротом

По Закон Мура , delta(CPU)/delta(t) - это постоянный коэффициент два каждые 18-24 месяца. Поскольку среда содержит больше, чем процессор, я бы предположил, что это лишь очень слабая нижняя граница для реальных изменений в среде. Единица: OPS / $ / с, изменение операций в секунду на доллар с течением времени

delta(users)/delta(t) труднее измерить, но данные о частоте появления в новостях слова «Эпоха знаний», я бы сказал, что ожидания пользователей также растут в геометрической прогрессии. Рассматривая развитие $/flops, базовая экономика говорит нам, что предложение растет быстрее, чем спрос, давая закон Мура как верхнюю границу изменения пользователя. Я буду использовать функциональных точек («объем бизнес-функций, которые информационная система предоставляет пользователю») в качестве меры требований. Единица измерения: FP / с, изменение требуемых функциональных точек с течением времени

delta(maintenance)/delta(t) полностью зависит от организации и обычно довольно высока непосредственно перед выпуском, когда быстрые исправления проталкиваются и при интеграции больших изменений. Изменения в различных мерах, таких как SLOC , Cyclomatic Complexity или реализованные функциональные точки во времени, могут использоваться здесь в качестве замены. Еще одна возможность - сбой в системе продажи билетов, если таковой имеется. Я останусь с реализованными функциональными точками со временем. Единица = FP / с, изменение реализованных функциональных точек с течением времени

delta(refactoring)/delta(t) можно измерить как время, потраченное , а не на реализацию новых функций. Единица = 1, время, потраченное на рефакторинг с течением времени

Так что битрот будет

             d(env)     d(users)     d(maint)        d(t)
bitrot(t) = -------- * ---------- * ---------- * ----------------
              d(t)        d(t)        d(t)        d(refactoring)

             d(env) * d(users) * d(maint)
          = ------------------------------
                d(t)² * d(refactoring)

с объединенной единицей OPS/$/s * FP/s * FP/s = (OPS*FP²) / ($*s³).

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

Answer 2

Как насчет самого простого ответа?

foreach (file in source control){
  file.RotLevel = (Time.Now - file.LastTestedOrDeployed)
}

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

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

Answer 3

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

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

Answer 4

Очевидный ответ - нет. BItrot не имеет принятых размеров.

Answer 5

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

Answer 6

Настоящий битрот (не программная гниль) имеет размеры физического объема памяти * время.

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

Answer 7

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

Но качественные юнит-тесты, очевидно, обеспечат некоторую защиту.

Итак, вот мои важные факторы для программного гниения:

1. Количество внешних точек интерфейса данных (extDataIntfPts)
   • Качество обработки данных / ошибок, юнит-тесты (codeQuality)
   • Зависимость от базовых реализаций, таких как ОС / ВМ. (OsDep)
   • Количество внешних точек реализации интерфейса, таких как плагины. (extIntfPts)
   • Сложность кода / простой объем кода (linesOfCode)

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

Это может быть смягчено качеством обработки данных, обработкой ошибок и юнит-тестами.

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

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

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

Итак, вот мое уравнение:

bitrot=((linesofcode/codeQuality)*(extDataInfPts+(osDep/change)+extIntfPts)*numberOfSecondsDeployed)

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

В конце концов, это псевдонаука. Вот мой вклад в лженауку.

Answer 8

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

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

Answer 9

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

Answer 10

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