Метрики исходного кода для измерения стабильности кода?

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

Например, можно увидеть, что в течение первых шести месяцев проекта в среднем было 200 строк кода в день, в то время как в течение последнего месяца это было 50 строк кода в день, а также в течение последней недели (непосредственно перед DVD-диском с продуктом). были отправлены), никакие строки кода не были изменены вообще (замораживание кода). Это всего лишь пример, и в зависимости от процесса разработки, принятого конкретной командой, могут появиться разные шаблоны.

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

Одна из мер, которую описал Майкл Фезер, - « Активный набор классов ».

Он измеряет количество добавленных классов против тех, кто «закрыт». Описывает закрытие класса как:

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

Он использует эти меры для создания таких диаграмм:

Чем меньше число разрыва между двумя строками, тем лучше.

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

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

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

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

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

Если вы используете git или svn и ваша версия gource> = 0.39, это так же просто, как запустить gource в папке проекта.

Использование частоты измененных строк в качестве индикатора стабильности кода, по крайней мере, сомнительно.

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

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

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

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

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

Надежность измеряется путем испытаний. Юнит-тесты, тесты на дым, автоматические регрессионные тесты; тесты, тесты, тесты!

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

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

С наилучшими пожеланиями.