Jaka jest fascynacja metrykami kodu? [Zamknięte]

Widziałem ostatnio wiele pytań dotyczących SO związanych z „metrykami kodu” i muszę się zastanawiać, czym jest ta fascynacja? Oto kilka ostatnich przykładów:

• jakie metryki kodu przekonują Cię, że podany kod jest kiepski
• kiedy, jeśli kiedykolwiek, liczba wierszy kodu jest użyteczną miarą
• pisanie testów jakości

Moim zdaniem żadna metryka nie może zastąpić przeglądu kodu:

• niektóre wskaźniki mogą czasami wskazywać miejsca, które wymagają przeglądu, i
• radykalne zmiany wskaźników w krótkich ramach czasowych mogą wskazywać miejsca, które wymagają przeglądu

Ale nie przychodzi mi do głowy żadna miara, która sama w sobie zawsze wskazuje „dobry” lub „zły” kod - zawsze są wyjątki i powody, dla których pomiary nie są widoczne.

Czy można uzyskać jakiś magiczny wgląd z metryk kodu, który przeoczyłem? Czy leniwi programiści / menedżerowie szukają wymówek, aby nie czytać kodu? Czy ludzie mają do czynienia z gigantycznymi, starszymi bazami kodu i szukają miejsca, w którym mogliby zacząć? Co się dzieje?

Uwaga: Zadałem niektóre z tych pytań w określonych wątkach, zarówno w odpowiedziach, jak i komentarzach, ale nie otrzymałem odpowiedzi, więc pomyślałem, że powinienem ogólnie zapytać społeczność, ponieważ być może czegoś mi brakuje. Byłoby miło uruchomić zadanie wsadowe metryk i nie musieć już nigdy więcej czytać kodu innych osób (lub własnego), po prostu nie sądzę, aby było to praktyczne!

EDYCJA: Jestem zaznajomiony z większością, jeśli nie wszystkimi omawianymi wskaźnikami, po prostu nie widzę ich w oderwaniu lub jako arbitralne standardy jakości.

Odpowiedzi w tym wątku są trochę dziwne, ponieważ mówią o:

• „zespół”, na przykład „jedyny beneficjent” wspomnianych wskaźników;
• „metryki”, tak jakby same w sobie oznaczały cokolwiek.

1 / Metryki nie dotyczą jednej populacji, ale trzech :

• programiści: zajmują się chwilowymi statycznymi metrykami kodu dotyczącymi analizy statycznej ich kodu (złożoność cykliczna, jakość komentarzy, liczba wierszy, ...)
• liderzy projektów: zajmują się codziennymi wskaźnikami kodu na żywo pochodzącymi z testów jednostkowych, pokrycia kodu, ciągłych testów integracyjnych
• sponsorzy biznesowi (zawsze się o nich zapomina, ale to są interesariusze, którzy płacą za rozwój): interesują ich cotygodniowe globalne wskaźniki kodu dotyczące projektu architektonicznego, bezpieczeństwa, zależności, ...

Wszystkie te metryki można oczywiście obserwować i analizować we wszystkich trzech populacjach, ale każdy rodzaj jest zaprojektowany tak, aby był lepiej wykorzystywany przez każdą określoną grupę.

2 / Metryki same w sobie przedstawiają migawkę kodu, a to oznacza ... nic!

Jest to połączenie tych wskaźników i kombinacji tych różnych poziomów analizy, które mogą wskazywać na „dobry” lub „zły” kod, ale co ważniejsze, to trend tych wskaźników jest istotny.

To jest powtarzanie tych wskaźników, co da prawdziwą wartość dodaną, ponieważ pomogą menedżerom biznesowym / liderom projektów / programistom ustalić priorytety spośród różnych możliwych poprawek kodu

Innymi słowy, Twoje pytanie o „fascynację danymi” może odnosić się do różnicy między:

• „piękny” kod (chociaż zawsze jest to w oku patrzącego-kodera)
• „dobry” kod (który działa i może udowodnić, że działa)

Na przykład funkcja o cyklomatycznej złożoności równej 9 może być zdefiniowana jako „piękna”, w przeciwieństwie do jednej, długiej i skomplikowanej funkcji o cyklomatycznej złożoności równej 42.

Ale jeśli:

• ta ostatnia funkcja ma stałą złożoność w połączeniu z pokryciem kodu na poziomie 95%,
• mając na uwadze, że pierwsza z nich jest coraz bardziej złożona, a jej zasięg wynosi ... 0%,

można by się spierać:

• ten ostatni reprezentuje „ dobry ” kod (działa, jest stabilny, a jeśli trzeba to zmienić, można sprawdzić, czy po modyfikacjach nadal działa),
• pierwszy jest „ złym ” kodem (nadal trzeba dodać kilka przypadków i warunków, aby pokryć wszystko, co musi zrobić, i nie ma łatwego sposobu na wykonanie testu regresji)

Podsumowując:

pojedynczy wskaźnik, który sam w sobie zawsze wskazuje [...]

: niewiele, poza tym, że kod może być piękniejszy, co samo w sobie niewiele znaczy ...

Czy można uzyskać jakiś magiczny wgląd z metryk kodu, który przeoczyłem?

Tylko kombinacja i trend wskaźników daje prawdziwy „magiczny wgląd”, którego szukasz.

Kilka miesięcy temu miałem projekt, który wykonałem jako jednoosobowa praca, której złożoność była cykliczna. To był mój pierwszy kontakt z tego rodzaju wskaźnikami.

Pierwszy raport, jaki otrzymałem, był szokujący. Prawie wszystkie moje funkcje nie przeszły testu, nawet te (imho) bardzo proste. Poradziłem sobie ze złożonością, przenosząc logiczne pod-zadanie do podprogramów, nawet jeśli zostały one wywołane tylko raz.

W przypadku drugiej połowy procedur moja duma jako programisty zaczęła działać i próbowałem przepisać je w taki sposób, aby działały tak samo, tylko prostsze i bardziej czytelne. To zadziałało i udało mi się dotrzeć do progu złożoności klienta.

W końcu prawie zawsze byłem w stanie wymyślić lepsze rozwiązanie i znacznie czystszy kod. Wydajność na tym nie ucierpiała (zaufaj mi - mam paranoję na tym punkcie i dość często sprawdzam demontaż wyjścia kompilatora).

Myślę, że metryki są dobrą rzeczą, jeśli używasz ich jako powodu / motywacji do ulepszania kodu. Ważne jest jednak, aby wiedzieć, kiedy przestać i poprosić o dotację z tytułu naruszenia metrycznego.

Metryki są wskazówkami i pomagają, a nie kończą się same w sobie.

Najlepszym wskaźnikiem, jakiego kiedykolwiek używałem, jest wynik CRAP .

Zasadniczo jest to algorytm, który porównuje ważoną złożoność cyklomatyczną z automatycznym pokryciem testów. Algorytm wygląda następująco: CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) gdzie comp (m) to cykliczna złożoność metody m, a cov (m) to pokrycie kodu testowego zapewniane przez testy automatyczne.

Autorzy wyżej wymienionego artykułu (proszę, przeczytaj ... warto poświęcić czas) sugerują maksymalny wynik CRAP 30, który rozkłada się w następujący sposób:

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

Jak szybko się przekonasz, metryka nagradza pisanie kodu, który nie jest skomplikowany, w połączeniu z dobrym pokryciem testów (jeśli piszesz testy jednostkowe, a powinieneś być, a nie mierzysz pokrycia ... cóż, prawdopodobnie spodobałoby Ci się plucie w wiatr także). ;-)

W przypadku większości moich zespołów programistycznych bardzo się starałem uzyskać wynik CRAP poniżej 8, ale jeśli mieli uzasadnione powody, aby uzasadnić dodatkową złożoność, która była akceptowalna, o ile obejmowały złożoność za pomocą wystarczających testów. (Pisanie złożonego kodu jest zawsze bardzo trudne do przetestowania ... rodzaj ukrytej korzyści dla tej metryki).

Większość ludzi początkowo miała trudności z napisaniem kodu, który przeszedłby wynik CRAP. Ale z biegiem czasu napisali lepszy kod, kod, który miał mniej problemów i kod, który był znacznie łatwiejszy do debugowania. Spośród wszystkich mierników to ta, która ma najmniej problemów i największą korzyść.

Dla mnie najważniejszą miarą identyfikującą zły kod jest cykliczna złożoność. Prawie wszystkie metody w moich projektach są poniżej CC 10, a błędy są niezmiennie znajdowane w starszych metodach z CC powyżej 30. Wysoki CC zwykle oznacza:

• kod napisany w pośpiechu (tj. nie było czasu na znalezienie eleganckiego rozwiązania, a nie dlatego, że problem wymagał złożonego rozwiązania)
• niesprawdzony kod (nikt nie pisze testów dla takich bestii)
• kod, który był wielokrotnie poprawiany i poprawiany (np. podziurawiony komentarzami ifs i todo)
• główny cel refaktoryzacji

Dobry przegląd kodu nie zastąpi dobrego narzędzia do analizy statycznej, które oczywiście nie zastępuje dobrego zestawu testów jednostkowych, teraz testy jednostkowe nie są dobre bez zestawu testów akceptacyjnych ......

Metryki kodu to kolejne narzędzie, które można umieścić w skrzynce narzędziowej, nie są one rozwiązaniem samym w sobie, są po prostu narzędziem, którego należy używać w razie potrzeby (oczywiście z wszystkimi innymi narzędziami w pudełku!).

Ludzi przyciąga idea mechanistycznych sposobów rozumienia i opisywania kodu. Jeśli to prawda, pomyśl o konsekwencjach dla wydajności i produktywności!

Zgadzam się, że miara „dobroci kodu” jest tak samo sensowna jak miara „dobrej prozy”. Nie oznacza to jednak, że metryki są bezużyteczne, tylko być może nadużywane.

Na przykład skrajne wartości niektórych metryk wskazują drogę do możliwych problemów. Metoda obejmująca 1000 wierszy jest prawdopodobnie nie do utrzymania . Kod z zerowym pokryciem kodu testów jednostkowych prawdopodobnie ma więcej błędów niż podobny kod z dużą ilością testów. Duży skok kodu dodany do projektu tuż przed wydaniem, który nie jest biblioteką innej firmy, prawdopodobnie jest powodem dodatkowej uwagi.

Myślę, że jeśli użyjemy metryk jako sugestii - czerwonej flagi - być może będą przydatne. Problem pojawia się, gdy ludzie zaczynają mierzyć produktywność w SLOC lub jakość jako procent linii z testami.

Moją wysoce subiektywną opinią jest to, że metryki kodu wyrażają nieodpartą instytucjonalną fascynację możliwością ilościowego określenia czegoś, co jest z natury niewymierne.

W pewnym sensie ma to sens, przynajmniej psychologicznie - jak możesz podejmować decyzje dotyczące czegoś, czego nie możesz ocenić lub zrozumieć? Ostatecznie, oczywiście, nie możesz ocenić jakości, chyba że masz wiedzę na temat przedmiotu (i jesteś przynajmniej tak dobry, jak to, co próbujesz ocenić) lub zapytać kogoś, kto ma wiedzę, co oczywiście po prostu rozwiązuje problem jeden krok.

W tym sensie może rozsądną analogią byłaby ocena osób rozpoczynających naukę w college'u na podstawie wyników SAT, jest to niesprawiedliwe i pomija wszelkie subtelności, ale jeśli chcesz określić ilościowo, musisz coś zrobić.

Nie mówię, że uważam, że to dobry środek, tylko, że widzę w nim instytucjonalną nieodpartość. I, jak zauważyłeś, prawdopodobnie istnieje kilka rozsądnych wskaźników (wiele metod ponad 500 linii, duża złożoność - prawdopodobnie zła). Jednak nigdy nie byłem w miejscu, które to kupiło.

Wierzę w jeden wskaźnik kodu.

Pracuję na dużym systemie. Kiedy przychodzi do mnie jeden nowy wymóg, zabieram się za jego kodowanie. Kiedy skończę i naprawię błędy, sprawdzam to w systemie kontroli wersji. Ten system robi różnicę i zlicza wszystkie wprowadzone przeze mnie zmiany.

Im mniejsza liczba, tym lepiej.

Metryki i testy automatyczne nie zastępują pełnego przeglądu kodu.

Po prostu przyspieszają. Dzięki automatycznemu kontrolerowi bardzo łatwo jest zobaczyć, których konwencji zapomniałeś przestrzegać, że używasz wyznaczonych pakietów i metod itp. Możesz zobaczyć, co możesz naprawić, nie poświęcając czasu innych ludzi.

Menedżerowie lubią też metryki, ponieważ czują, że uzyskują dokładną liczbę wydajności (chociaż często tak nie jest) i powinni być w stanie lepiej żonglować ludźmi.

Pomiary są przydatne tylko wtedy, gdy:

• Zespół je opracował
• Zespół zgodził się na nie
• Są używane do identyfikacji określonego obszaru

Ogólnie rzecz biorąc, każdy wskaźnik, który nie pasuje do tego, ucierpi z powodu optymalizacji zespołu. Chcesz mierzyć linie kodu? O rany, patrz, jak wielu mogą pisać! Chcesz zmierzyć pokrycie kodu, przez golly, patrz, jak pokrywam ten kod!

Myślę, że metryki mogą być przydatne do identyfikowania trendów, aw rzeczywistości widziałem kilka przydatnych, takich jak wykreślanie, kiedy kompilacja się psuje, zmiany kodu (liczba linii kodu zmieniających się w trakcie projektu) i inne. Ale jeśli zespół ich nie wymyśla lub nie zgadzają się z nimi lub nie rozumieją, prawdopodobnie jesteś w świecie zranienia.

Oto niektóre metryki złożoności ze stan4j .

Narzędzie do analizy struktury klas zaćmień.

Podoba mi się to narzędzie i metryki. Metryki traktuję jako statystyki, wskaźniki, komunikaty ostrzegawcze. Czasami z powodu pewnych metod lub niektórych klas naprawdę skomplikowana logika sprawiła, że ​​są złożone, należy je obserwować, przejrzeć, aby sprawdzić, czy istnieje potrzeba ich refaktoryzacji lub dokładnie je przejrzeć, ponieważ normalnie są podatni na błędy. Używam go również jako narzędzia analitycznego do nauki kodu źródłowego, ponieważ lubię uczyć się od złożonego do prostego. Właściwie zawiera kilka innych wskaźników, takich jak Robert C. Martin Metrics, Chidamber & Kemerer Metrics, Count Metrics Ale ten podoba mi się najbardziej

Metryki złożoności

Cyklomatyczne wskaźniki złożoności

Złożoność cyklomatyczna (CC) Cyklomatyczna złożoność metody to liczba punktów decyzyjnych na wykresie przepływu sterowania metody, zwiększona o jeden. Punkty decyzyjne występują w instrukcjach if / for / while, klauzulach case / catch i podobnych elementach kodu źródłowego, w których przepływ sterowania jest nie tylko liniowy. Liczba punktów decyzyjnych (kodu bajtowego) wprowadzanych przez pojedynczą instrukcję (kod źródłowy) może się różnić, w zależności np. Od złożoności wyrażeń logicznych. Im wyższa wartość cyklomatycznej złożoności metody, tym więcej przypadków testowych jest wymaganych do przetestowania wszystkich gałęzi kontrolnego wykresu przepływu metody.

Średnia złożoność cyklomatyczna Średnia wartość miary złożoności cyklomatycznej dla wszystkich metod aplikacji, biblioteki, drzewa pakietów lub pakietu.

Metryki Fat Metryka Fat artefaktu to liczba krawędzi na odpowiednim wykresie zależności artefaktu. Typ wykresu zależności zależy od wariantu metryki i wybranego artefaktu:

Fat Metryka Fat aplikacji, biblioteki lub drzewa pakietu to liczba krawędzi wykresu zależności poddrzewa. Ten wykres zawiera wszystkie elementy potomne artefaktu w hierarchii drzewa pakietów, a tym samym obejmuje również pakiety-liście. (Aby zobaczyć odpowiedni wykres w widoku kompozycji, przełącznik płaskich paczek eksploratora struktury musi być wyłączony. Przełącznik Pokaż biblioteki musi być włączony, jeśli wybrany artefakt jest biblioteką, w przeciwnym razie należy go wyłączyć).

Metryka Fat pakietu to liczba krawędzi jej wykresu zależności od jednostek. Ten wykres zawiera wszystkie klasy najwyższego poziomu pakietu.

Metryka Fat klasy to liczba krawędzi jej grafu składowego. Ten wykres zawiera wszystkie pola, metody i klasy składowe klasy. (Ten wykres i wartość Fat są dostępne tylko wtedy, gdy analiza kodu została przeprowadzona dla elementu poziomu szczegółowości, a nie klasy).

Fat dla zależności bibliotek (Fat - Libraries) Metryka Fat dla zależności bibliotecznych aplikacji to liczba krawędzi jej wykresu zależności biblioteki. Ten wykres zawiera wszystkie biblioteki aplikacji. (Aby zobaczyć odpowiedni wykres w widoku kompozycji, należy włączyć przełącznik Pokaż biblioteki eksploratora struktury).

Tłuszcz dla zależności od płaskiego pakietu (Fat - pakiety) Metryka Fat dla płaskich zależności od pakietu aplikacji to liczba krawędzi wykresu zależności płaskiego pakietu. Ten wykres zawiera wszystkie pakiety aplikacji. (Aby zobaczyć odpowiedni wykres w widoku kompozycji, przełącznik płaskich pakietów eksploratora struktury musi być włączony, a przełącznik Pokaż biblioteki musi być wyłączony).

Metryka Fat for Flat Package Dependencies jest liczbą krawędzi jej płaskiego wykresu zależności pakietu. Ten wykres zawiera wszystkie pakiety biblioteki. (Aby zobaczyć odpowiedni wykres w widoku kompozycji, należy włączyć przełączniki Flat Packages i Show Libraries w eksploratorze struktury).

Fat dla zależności klas najwyższego poziomu (Fat - jednostki) Metryka Fat dla zależności klas najwyższego poziomu aplikacji lub biblioteki jest liczbą krawędzi jej wykresu zależności jednostek. Ten wykres zawiera wszystkie klasy najwyższego poziomu aplikacji lub biblioteki. (W rozsądnych zastosowaniach jest on zbyt duży, aby go wizualizować i dlatego nie można go wyświetlić w widoku kompozycji. Wykresy zależności jednostek mogą być wyświetlane tylko dla pakietów).

Metryki mogą być przydatne do określenia ulepszeń lub degradacji projektu iz pewnością mogą wykryć naruszenia stylu i konwencji, ale nic nie zastąpi przeprowadzania wzajemnych recenzji kodu. Bez nich nie możesz poznać jakości swojego kodu.

Aha ... i zakłada się, że przynajmniej jeden z uczestników przeglądu kodu ma wskazówkę.

Zgadzam się z Tobą, że metryki kodu nie powinny zastępować przeglądu kodu, ale uważam, że powinny uzupełniać recenzje kodu. Myślę, że wraca do starego powiedzenia, że ​​„nie można poprawić tego, czego nie można zmierzyć”. Metryki kodu mogą dostarczyć zespołowi programistów mierzalnych „zapachów kodu” lub wzorców, które mogą wymagać dalszych badań. Metryki, które są rejestrowane w większości narzędzi do analizy statycznej, to zazwyczaj metryki, które zostały zidentyfikowane w toku badań w krótkiej historii naszej dziedziny, aby mieć znaczące znaczenie.

Metryki nie zastępują przeglądu kodu, ale są znacznie tańsze. Są wskaźnikiem bardziej niż cokolwiek innego.

Jedna część odpowiedzi jest taka, że ​​niektóre metryki kodu mogą dać bardzo szybką, początkową odpowiedź na pytanie: Jaki jest ten kod?

Nawet „wiersze kodu” mogą dać wyobrażenie o rozmiarze oglądanej bazy kodu.

Jak wspomniano w innej odpowiedzi, trend wskaźników dostarcza najwięcej informacji.

Wskaźniki dotyczące samych siebie nie są szczególnie interesujące. Liczy się to, co z nimi zrobisz.

Na przykład, jeśli mierzysz liczbę komentarzy w wierszu kodu, co uważasz za dobrą wartość? Kto wie? A może co ważniejsze, każdy ma swoje zdanie.

Teraz, jeśli zbierzesz wystarczającą ilość informacji, aby móc skorelować liczbę komentarzy w wierszu kodu z czasem potrzebnym do usunięcia błędów lub z liczbą znalezionych błędów przypisanych kodowaniu, możesz zacząć znajdować liczbę użyteczną empirycznie .

Nie ma różnicy między używaniem metryk w oprogramowaniu a używaniem jakichkolwiek innych mierników wydajności w jakimkolwiek innym procesie - najpierw mierzysz, potem analizujesz, a potem udoskonalasz proces. Jeśli wszystko, co robisz, to mierzenie, marnujesz swój czas.

edycja: W odpowiedzi na komentarze Stevena A. Lowe'a - to jest absolutnie poprawne. W każdej analizie danych należy uważać, aby odróżnić związek przyczynowy od zwykłej korelacji. Ważny jest także wybór wskaźników na podstawie przydatności. Nie ma sensu próbować mierzyć spożycia kawy i przypisywać jakości kodu (chociaż jestem pewien, że niektórzy próbowali ;-))

Ale zanim będziesz mógł znaleźć związek (przyczynowy lub nie), musisz mieć dane.

Wybór danych do zbierania zależy od tego, jaki proces chcesz zweryfikować lub ulepszyć. Na przykład, jeśli próbujesz przeanalizować powodzenie procedur przeglądu kodu (używając własnej definicji „sukcesu”, czy to mniej błędów, mniej błędów w kodowaniu, krótszy czas realizacji itp.), To wybierasz metryki, które mierzą łączny wskaźnik błędów i wskaźnik błędów w recenzowanym kodzie.

Więc zanim zbierzesz dane, musisz wiedzieć, co chcesz z nimi zrobić. Jeśli mierniki są środkiem, jaki jest koniec?

Nie sądzę, żeby małe zmiany w metrykach miały znaczenie: funkcja o złożoności 20 niekoniecznie jest czystsza niż funkcja o złożoności 30. Ale warto uruchomić metryki, aby znaleźć duże różnice.

Kiedyś badałem kilkadziesiąt projektów i jeden z projektów miał maksymalną wartość złożoności około 6000, podczas gdy każdy inny projekt miał wartość około 100 lub mniej. To uderzyło mnie w głowę jak kij baseballowy. Oczywiście przy tym projekcie działo się coś niezwykłego i prawdopodobnie złego.

Jesteśmy programistami. Lubimy liczby.

Ponadto, co zamierzasz zrobić, NIE opisywać rozmiaru bazy kodu, ponieważ „wiersze metryk kodu są nieistotne”?

Na głupim przykładzie istnieje różnica między bazą kodów składającą się ze 150 linii a bazą danych wynoszącą 150 milionów. I nie jest to trudna liczba.