Как я могу оценить срок службы строки кода?

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

В настоящее время я думаю, что строка времени жизни кода начинается, когда он впервые фиксируется, и заканчивается, когда происходит одно из следующих действий:

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

ПРИМЕЧАНИЕ. В качестве пояснения того, почему «правка» считается «смертью», отредактированные строки будут учитываться как «новое» поколение или строка кода. Кроме того, если бы не было простого способа сделать это, не было бы никакого объяснения долговечности линии или происхождения от предка.

Что еще определило бы продолжительность жизни кода?

Энди Озмент рассматривал OpenBSD в 2006 году с тем же вопросом: « Молоко или вино»: улучшается ли безопасность программного обеспечения с возрастом?

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

За период 7,5 лет и пятнадцати выпусков 62% из 140 уязвимостей, о которых сообщалось в OpenBSD, были основополагающими : они присутствовали в коде в начале исследования.

Потребовалось более двух с половиной лет, чтобы сообщить о первой половине этих основных уязвимостей. Мы обнаружили, что 61% исходного кода в изученной окончательной версии является основополагающим: он остается неизменным по сравнению с первоначальной версией, выпущенной 7,5 годами ранее. Таким образом, частота сообщений об основных уязвимостях в OpenBSD, вероятно, будет продолжать оказывать значительное влияние на общий уровень сообщений об уязвимостях.

Мы также обнаружили статистически значимые доказательства того, что в течение периода исследования частота сообщений об основных уязвимостях снизилась. Мы использовали модель роста надежности, чтобы оценить, что было найдено 67,6% уязвимостей в базовой версии. Оценка модели ожидаемого числа основных уязвимостей, о которых сообщалось в день, снизилась с 0,051 в начале исследования до 0,024.

Я не думаю, что есть ответ на это. Это сильно зависит от проекта. Некоторые из них более стабильны в течение многих лет, другие более изменчивы / реорганизованы / развиваются в течение многих лет.

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

Тем не менее, я думаю, что большая часть LOCs живут вечно.

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

Более того, только хорошие программисты стремятся очистить кодовые базы и сократить количество строк. Все остальные имеют тенденцию накапливать LOC. И пока что последние выигрывают. ;)

Удаление или исключение строки кода определенно свидетельствует об окончании срока его службы.

Обновляя редактирование, я бы задал этот вопрос: дает ли это утверждение другой результат после редактирования?

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

Пример изменения результата:

if ( a && b )

чтобы:

if ( a || b )

Пример продолжения жизни:

foo.bar( baz );

чтобы:

foo.prototype.bar.call( this, baz );