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

11

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?

błędy
źródło
2
„jak długo konkretna linia kodu jest aktywna i używana”, dlaczego uważasz, że to dobra miara?
Pieter B

Odpowiedzi:

10

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.

Bruce Ediger
źródło
1
+1 @Bruce Ediger: Świetnie, dziękuję - patrzę na to teraz!
błąka się
Ponownie, dzięki, więc jedyne informacje, które mogę znaleźć, to: „Dowiadujemy się, że 61% linii kodu w dzisiejszym OpenBSD ma fundamentalne znaczenie: zostały one wprowadzone przed wydaniem pierwszej wersji, którą badaliśmy i nie został zmieniony od tego czasu ”. - które choć interesujące, nie są tak naprawdę powiązane. Wszystko inne wydaje się koncentrować na tym, ile czasu trzeba naprawić luki, co znowu jest interesujące, ale nie mówi nic o czynnikach, które należy uwzględnić w długości życia kodu. Czy czegoś brakuje?
błąka się
1

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ą. ;)

Dagnele
źródło
0

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 );
Mahdi
źródło