Jak mogę oszacować żywotność linii kodu?

Próbuję wymyślić sposób analizy długowieczności kodu w projektach open source: to znaczy, jak długo określony wiersz kodu jest aktywny i używany.

Moje obecne myślenie jest takie, że długość życia kodu zaczyna się od pierwszego zatwierdzenia, a kończy, gdy nastąpi jedna z następujących sytuacji:

• Jest edytowany lub usuwany,
• Wyłączone z kompilacji,
• Przez pewien czas (na przykład rok) żaden kod w jego kompilacji nie jest utrzymywany.

UWAGA: W celu wyjaśnienia, dlaczego „edycja” jest liczona jako „śmierć”, edytowane wiersze będą liczone jako „nowa” generacja lub wiersz kodu. Ponadto, chyba że istnieje prosty sposób, aby to zrobić, nie byłoby uwzględnienia długowieczności linii ani pochodzenia od przodka.

Co jeszcze określiłoby długość linii kodu?

Andy Ozment spojrzał na OpenBSD w 2006 roku z tym samym pytaniem: Milk or Wine: Czy bezpieczeństwo oprogramowania poprawia się wraz z wiekiem?

Możesz nauczyć się z jego definicji. Jest to również bardzo interesujący artykuł, z ciekawym wnioskiem, który nie został włączony do wiedzy o zarządzaniu oprogramowaniem:

Przez okres 7,5 lat i piętnastu wydań, 62% ze 140 podatności zgłoszonych w OpenBSD było fundamentalnych : obecnych w kodzie na początku badania.

Zgłoszenie pierwszej połowy tych podstawowych luk w zabezpieczeniach zajęło ponad dwa i pół roku. Odkryliśmy, że 61% kodu źródłowego w końcowej analizowanej wersji jest fundamentalne: pozostaje niezmienione od początkowej wersji wydanej 7,5 lat wcześniej. Częstotliwość zgłaszania podstawowych luk w zabezpieczeniach w OpenBSD może zatem w dalszym ciągu znacząco wpływać na ogólny wskaźnik zgłaszania luk w zabezpieczeniach.

Znaleźliśmy również istotne statystycznie dowody na to, że odsetek podstawowych raportów podatności na zagrożenia zmniejszył się w okresie badania. Zastosowaliśmy model wzrostu niezawodności, aby oszacować, że znaleziono 67,6% podatności w wersji podstawowej. Oszacowanie modelu dotyczące oczekiwanej liczby podstawowych luk zgłoszonych dziennie spadło z 0,051 na początku badania do 0,024.

Nie sądzę, żeby na to była odpowiedź. W dużym stopniu zależy to od projektu. Niektóre są bardziej stabilne na przestrzeni lat, inne są bardziej niestabilne / przekształcone / ewoluują na przestrzeni lat.

Co więcej, trudno to zmierzyć. Czy edytowana linia to naprawdę koniec jej żywotności? Co powiesz na tylko kosmetyczną zmianę, taką jak przeformatowanie bazy kodu za pomocą tabulatorów lub spacji? IMHO, które nie jest liczone jako odnowiona baza kodu, ale byłoby zgodne z Twoimi kryteriami.

To powiedziawszy, myślę, że spora część LOC żyje wiecznie.

Powód jest prosty: o wiele łatwiej jest dodać nowy kod niż go usunąć. Zwłaszcza, gdy system jest złożony i rozwija się przez lata. Następnie szybko dochodzi do punktu, w którym „ryzykowne” jest usunięcie lub zmiana nietrywialnego kodu. Może wprowadzić błędy, zepsuć kompatybilność, wprowadzić efekt motyla zmian ... Myślę więc, że im większa baza kodów, tym jest ona starsza, tym bardziej LOC pozostaną.

Co więcej, tylko dobrzy programiści mają tendencję do czyszczenia baz kodowych i zmniejszania linii. Wszyscy inni gromadzą LOC. I do tej pory te ostatnie zdecydowanie wygrywają. ;)

Usunięcie lub wykluczenie wiersza kodu zdecydowanie oznacza koniec jego żywotności.

Przypisywanie edycji, zadałbym następujące pytanie: Czy to stwierdzenie daje inny wynik po edycji?

Jeśli odpowiedź brzmi tak, to powiedziałbym, że poprzednie oświadczenie nie jest już dostępne, w przeciwnym razie nadal uważałbym je za kontynuację poprzedniego oświadczenia.

Przykład zmiany wyniku:

if ( a && b )

do:

if ( a || b )

Przykład kontynuacji życia:

foo.bar( baz );

do:

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