Metryki kodu źródłowego do pomiaru stabilności kodu?

17

Biorąc pod uwagę, jak rozwija się oprogramowanie podczas cyklu wydawniczego (implementacja, testowanie, naprawa błędów, wydanie), pomyślałem, że w liniach kodu, które są zmieniane w bazie kodu, powinien być widoczny pewien wzorzec; np. pod koniec projektu, jeśli kod staje się bardziej stabilny, należy zauważyć, że mniej wierszy kodu jest modyfikowanych w jednostce czasu.

Na przykład można zauważyć, że w ciągu pierwszych sześciu miesięcy projektu średnia wynosiła 200 linii kodu dziennie, podczas gdy w ostatnim miesiącu było to 50 linii kodu dziennie, aw ostatnim tygodniu (tuż przed DVD z produktem zostały wysłane), żadne wiersze kodu nie zostały w ogóle zmienione (zamrożenie kodu). To tylko przykład i mogą pojawić się różne wzorce zgodnie z procesem rozwoju przyjętym przez konkretny zespół.

W każdym razie, czy są jakieś wskaźniki kodu (jakaś literatura na ich temat?), Które wykorzystują liczbę zmodyfikowanych wierszy kodu na jednostkę czasu do pomiaru stabilności podstawy kodu? Czy są przydatne, aby poczuć, że gdzieś się pojawia projekt lub czy wciąż jest daleki od gotowości do wydania? Czy są jakieś narzędzia, które mogą wyodrębnić te informacje z systemu kontroli wersji i generować statystyki?

code-metrics

— Giorgio
źródło

1

ndepend.com/Features.aspx#BuildComparison

— AakashM

4

„Po drugie, ponieważ mechanizm jest abstrakcyjny, jego produkcja jest uwzględniona w projekcie. Pod tym względem program jest jak wiersz: nie można napisać wiersza bez napisania. Jednak ludzie mówią o programowaniu, jakby to był proces produkcyjny i miara” wydajność programisty „pod względem„ liczby wyprodukowanych wierszy kodu ”. W ten sposób księgują ten numer po niewłaściwej stronie księgi: zawsze powinniśmy odnosić się do„ liczby zużytych wierszy kodu ”. - Owoc nieporozumienia , Edsger W. Dijkstra.

— yannis

3

@Yannis Rizos: W żadnym wypadku nie sugeruję mierzenia wydajności ani złożoności kodu przez LOC, ponieważ wiem, że nie jest to dobra miara. Z drugiej strony, gdyby 300 wierszy kodu zostało zmienionych na dwa dni przed wysyłką, ja jako menedżer miałbym w głowie dużą lampkę „CZERWONY ALERT” (chyba że zostało to zaplanowane i jest wynikiem bardzo starannej oceny ryzyka ). Ogólnie zakładam, że kod, który był używany (i testowany) przez długi czas bez zmian, jest „bardziej stabilny” niż kod, w którym codziennie zmienia się 100 wierszy.

— Giorgio

2

@Giorgio Argh, zostałem przerwany (w środku dnia roboczego tutaj), gdy publikowałem kolejny komentarz (osiągnąłem limit znaków w pierwszym). Nie oznaczało to, że mówisz o wydajności, właśnie przyszedł mi do głowy cytat Dijkstry i pomyślałem, że będzie interesujący. W każdym razie wskaźniki rezygnacji z kodu są bardzo zbliżone do tego, czego szukasz, i jest na nich mnóstwo literatury. Jeśli chodzi o narzędzia, FishEye Atlassian jest spektakularne.

— yannis

@Yannis Rizos: To naprawdę bardzo interesująca lektura. Jeśli chodzi o FishEye, używamy go w naszym miejscu pracy (do recenzji), więc od razu przejrzę instrukcję i zobaczę, jakie statystyki możemy stworzyć.

— Giorgio

17

Jednym ze środków, które opisał Michael Feather, jest „ Aktywny zestaw klas ”.

Mierzy liczbę klas dodanych do tych „zamkniętych”. Opisuje zamknięcie klasy jako:

Klasa jest zamknięta w dniu, w którym nie nastąpiły żadne dalsze modyfikacje od tej daty do chwili obecnej.

Używa tych miar do tworzenia takich wykresów: Aktywny wykres klas

Im mniejsza liczba odstępów między dwiema liniami, tym lepiej.

Możesz być w stanie zastosować podobną miarę do swojej bazy kodu. Jest prawdopodobne, że liczba klas jest skorelowana z liczbą wierszy kodu. Może być nawet możliwe rozszerzenie tego zakresu o linijkę kodu dla miary klasy, co może zmienić kształt wykresu, jeśli masz jakieś duże klasy monolityczne.

— Dave Hillier
źródło

4

Tak długo, jak istnieje względnie spójne odwzorowanie funkcji na klasy lub, w tym przypadku, system plików, możesz podłączyć coś takiego źródło do systemu kontroli wersji i bardzo szybko dowiedzieć się, na czym skupia się większość rozwoju (a tym samym które części kodu są najbardziej niestabilne).

Zakłada się, że masz stosunkowo uporządkowaną bazę kodu. Jeśli bazą kodu jest kula błota, w zasadzie zobaczysz każdą małą część, nad którą pracujesz z powodu wzajemnych zależności. To powiedziawszy, może samo w sobie (grupowanie podczas pracy nad funkcją) jest dobrym wskaźnikiem jakości bazy kodu.

Zakłada również, że Twój zespół biznesowy i zespół programistów jako całość mają jakiś sposób na rozdzielenie funkcji w fazie rozwoju (czy to gałęzie kontroli wersji, jedna funkcja na raz, cokolwiek). Jeśli na przykład pracujesz nad 3 głównymi funkcjami w tej samej gałęzi, metoda ta daje bezsensowne wyniki, ponieważ masz większy problem niż stabilność kodu na rękach.

Niestety nie mam literatury, aby udowodnić swój punkt widzenia. Opiera się wyłącznie na moim doświadczeniu w korzystaniu z zasobów na dobrych (i nie tak dobrych) kodach.

Jeśli używasz git lub svn, a twoja wersja źródła to> = 0,39, jest tak prosta, jak uruchomienie źródła w folderze projektu.

— Carl
źródło

gource wydaje się także doskonałym narzędziem! (+1)

— Giorgio

1

Natknąłem się na tę odpowiedź, a następnie spędziłem następne sześć godzin, grając z Gource. Nie jestem pewien, czy to zasługuje na +1 czy -1, ale cholera, to jedno fajne narzędzie.

— RonU

@RonU: Możesz użyć gource do wizualizacji stanu repozytorium w niestandardowym zakresie czasu. Chodzi o to, że wizualizuje aktywność w bazie kodu w czasie. To, jak łatwa jest interpretacja informacji, zależy od wielu czynników, takich jak wyjaśniono w mojej odpowiedzi powyżej. Tak, jest to niesamowite narzędzie, jeśli chcesz mieć „duży obraz”, więc myślę, że zasługuje na +1;)

— Carl

Tak, kiedy powiedziałem „sześć godzin”, nie miałem na myśli, że w tym czasie uruchomiłem jedną kartę Gource ... po prostu bawiłem się z wieloma opcjami, przesłałem ją do ffmpeg, prawdopodobnie dodałem epicką ścieżkę dźwiękową itp. była całkiem królicza nora. :)

— RonU

Niech zgadnę. Ścieżką dźwiękową był zapętlony Harlem Shuffle;)

— Carl

0

Wykorzystanie częstotliwości zmodyfikowanych linii jako wskaźnika stabilności kodu jest co najmniej wątpliwe.

Po pierwsze, rozkład zmodyfikowanych linii w czasie zależy w dużym stopniu od modelu zarządzania oprogramowaniem w projekcie. Istnieją duże różnice w różnych modelach zarządzania.

Po drugie, ofiara w tym założeniu nie jest jasna - jest to mniejsza liczba zmodyfikowanych linii spowodowana stabilnością oprogramowania, lub po prostu dlatego, że upłynął termin, a programiści postanowili nie wprowadzać żadnych zmian teraz, ale wprowadzić je po wydanie?

Po trzecie, większość linii jest modyfikowana po wprowadzeniu nowych funkcji. Ale nowa funkcja nie powoduje, że kod nie jest stabilny. To zależy od umiejętności programisty i jakości projektu. Z drugiej strony nawet poważne błędy mogą zostać naprawione przy bardzo niewielu zmianach linii - w tym przypadku stabilność oprogramowania znacznie wzrasta, ale zmieniona liczba linii nie jest zbyt duża.

— johnfound
źródło

„To zależy od umiejętności programisty i jakości projektu.”: Ale potrzebujesz przynajmniej trochę czasu, aby przetestować zmiany, aby mieć wystarczającą pewność, że nie wprowadziłeś żadnych błędów. Nawet najbardziej wykwalifikowani programiści mogą popełniać błędy w pisaniu, np. Jeśli są pod presją, zbyt dużo nadgodzin lub zbyt mało snu. Ponadto, jeśli zastosujesz zasadę otwarcia / zamknięcia, po pewnym czasie liczba zmian (poprawek błędów) powinna się zmniejszyć. W każdym razie wyraźnie stwierdziłem w swoim pytaniu, że wynik takiego pomiaru może ulec zmianie w zależności od procesu opracowywania.

— Giorgio

BTW, kod może być niestabilny nie dlatego, że programiści są źli, ale ponieważ wymagania nie są jasne, a projekt jest nadal w fazie prototypowania.

— Giorgio

@Giorgio: Oczywiście masz rację. Ale właśnie to napisałem: liczba zmodyfikowanych linii w dużej mierze zależy od zbyt wielu czynników. Niektóre z nich dotyczyły stabilności kodu, inne nie. To tak, jakby próbować obliczyć, ile osób uprawia seks, mierząc moc elektryczną, zakładając - mniej mocy - mniej światła - więcej seksu. Chociaż udowodniono, że wskaźnik urodzeń rośnie po dużych czarnych przerwach. ;)

— John

-1

Wytrzymałość to termin odnoszący się do prawidłowego działania zestawu instrukcji, a nie ilości, szczegółowości, zwięzłości, poprawności gramatycznej tekstu użytego do wyrażenia tych instrukcji.

Rzeczywiście składnia jest ważna i musi być poprawna, ale wszystko poza tym, ponieważ odnosi się do pożądanej funkcji instrukcji, patrząc na „metryki” instrukcji jest podobne do kreślenia swojej przyszłości poprzez czytanie wzoru liści herbaty na dole ty filiżanka herbaty.

Wytrzymałość jest mierzona za pomocą testów. Testy jednostkowe, testy dymu, automatyczne testy regresji; testy, testy, testy!

Moja odpowiedź na twoje pytanie brzmi: używasz niewłaściwego podejścia, szukając odpowiedzi na solidność. To czerwony śledź, który oznacza, że linie kodu oznaczają coś więcej niż linie zajmujące kod. Możesz wiedzieć tylko, czy kod robi to, co chcesz, jeśli przetestujesz, czy robi to, czego od niego oczekujesz.

Zapoznaj się ponownie z odpowiednimi wiązkami testowymi i unikaj mistyfikacji metrycznych.

Wszystkiego najlepszego.

— Sassafras_wot
źródło

3

Wyraźnie stwierdziłem, że nie sugeruję LoC jako miary złożoności kodu. Sugerowałem zmiany w kodzie jako miarę stabilności kodu: czy fragment kodu ma stabilne wymagania funkcjonalne i stabilną, przetestowaną implementację spełniającą te wymagania?

— Giorgio

Nie chcę się z tobą kłócić, ale z szacunkiem odsuwam cię od szaleństwa metryki bez znaczenia. Ponownie czytam ci pytanie, a twoje przykłady wskazują na chęć wnioskowania o związku między zmieniającymi się liniami kodu i wynikającą z tego jego odpornością. Rozumiem, że im więcej słów wpiszesz, tym bardziej prawdopodobne jest, że popełnisz literówkę. Ale jestem przeciwny zasadzie, w której prosisz, że muszę zdecydowanie poprzeć to, że porzuciłeś swoje poszukiwania w ten sposób. Dobre praktyki testowania = duże prawdopodobieństwo odporności.

— Sassafras_wot

„Dobre praktyki testowe = duże prawdopodobieństwo odporności”.: Całkowicie się zgadzam. Dlatego sugeruję, że fragment kodu, który został ostatnio zmieniony, musi zostać ponownie przetestowany, zanim będziemy mieć pewność, że jest poprawny.

— Giorgio

Istnieje kilka definicji stabilności, a jedna z nich jest tym, o co walczysz. To inna interpretacja semantyczna niż ta, którą stworzyłem. Przyjąłem, że stabilne oznacza, że „nie podlega ono ekstremalnym zmianom”, a nie „odporne na zmiany”

— Dave Hillier