Na czym polega fascynacja metrykami kodowymi? [zamknięte]

Jakiś miesiąc temu miałem projekt, który wykonałem jako jednoosobowa praca zmierzona pod kątem złożoności cyklomatycznej. To była moja pierwsza ekspozycja na tego rodzaju metryki.

Pierwszy raport, który dostałem, był szokujący. Prawie wszystkie moje funkcje zawiodły test, nawet te (imho) bardzo proste. Obejrzałem sprawę złożoności, przenosząc logiczne podzadania do podprogramów, nawet jeśli zostały wywołane tylko raz.

Dla drugiej połowy rutyny moja duma jako programisty kopnęła i próbowałem aby przepisać je w taki sposób, że robią to samo, po prostu prostsze i bardziej czytelne. To zadziałało i udało mi się najbardziej dotrzeć do progu złożoności klientów yclomatic.

W końcu prawie zawsze byłem w stanie wymyślić lepsze rozwiązanie i dużo czystszy kod. Wydajność nie ucierpiała z tego powodu (uwierz 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 powód/motywacja do ulepszania kodu. Ważne jest, aby wiedzieć, kiedy przestać i poprosić o dotację metryczną.

Metryki są przewodnikami i pomocą, a nie celem samym w sobie.

Najlepszą metryką, jaką kiedykolwiek użyłem, jest wynik C. R. A. P. http://www.artima.com/weblogs/viewpost.jsp?thread=215899

Autorzy wyżej wymienionego artykułu (zapraszam do lektury it...it ' s well warto poświęcić swój czas) zaproponuj max wynik C. R. A. P. 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 widzisz, metric 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óż, pewnie też by Ci się podobało plucie na wiatr). ;-)

Dla większości moich zespołów programistycznych bardzo starałem się uzyskać wynik C. R. A. P. poniżej 8, ale jeśli mieli ważne powody, aby uzasadnij dodatkową złożoność, która była akceptowalna, o ile obejmowały one złożoność za pomocą wystarczających testów. (Pisanie skomplikowanego kodu jest zawsze bardzo trudne do przetestowania...rodzaj ukrytej korzyści dla tej metryki).

Większości ludzi trudno było początkowo napisać kod, który przekroczy wynik C. R. A. P. Ale z czasem napisali lepszy kod, kod, który miał mniej problemów i kod, który był o wiele łatwiejszy do debugowania. Z każdej metryki, to jest ten, który ma najmniejsze obawy i największa korzyść.

Dla mnie najważniejszą metryką identyfikującą zły kod jest złożoność cyklomatyczna. Prawie wszystkie metody w moich projektach są poniżej CC 10 i błędy są niezmiennie spotykane w starszych metodach z CC ponad 30. Wysoki CC zazwyczaj oznacza:

• kod napisany w pośpiechu (tj. nie było czasu na znalezienie eleganckiego rozwiązania, a nie dlatego, że problem wymagał skomplikowanego rozwiązania)
• nieprzetestowany kod (nikt nie pisze testów na takie bestie)
• kod, który został poprawiony i poprawiony wielokrotnie (tj. podziurawione IFS i todo komentarze)
• główny cel refaktoryzacji

Dobry przegląd kodu nie zastępuje 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ą tylko narzędziem, które można wykorzystać w odpowiedni sposób(oczywiście z innymi narzędziami w skrzynce!).

Moja wysoce subiektywna opinia jest taka, że code metrics wyraża nieodpartą instytucjonalną fascynację możliwością kwantyfikacji czegoś z natury niepodważalnego.

Ma sens, w pewnym sensie, przynajmniej psychologicznie - jak można podejmować decyzje o czymś, czego nie można ocenić lub zrozumieć? Ostatecznie, oczywiście, nie można ocenić jakości, chyba że jesteś kompetentny w temacie (i są co najmniej tak dobre, jak to, co próbujesz ocenić) lub zapytać kogoś, kto jest Kompetentny, co oczywiście stawia problem z powrotem o jeden krok.

W tym sensie, może rozsądną analogią byłoby ocenianie studentów po wynikach SAT, to niesprawiedliwe i pomija każdy rodzaj subtelności, ale jeśli trzeba oszacować, trzeba coś zrobić.

Nie mówię, że uważam, że to dobry środek, tylko, że widzę jego niekonstytucyjność. I, jak zauważyłeś, istnieje prawdopodobnie kilka rozsądnych metryk (wiele metod liniowych 500+, wysoka złożoność-prawdopodobnie źle). Nigdy nie byłem w miejscu, które by to kupiło.

Jest jeden kod metryczny, w który wierzę.

Pracuję nad dużym systemem. Kiedy pojawia się jeden nowy wymóg, zacząłem go kodować. Kiedy skończę i rozwiążę błędy, sprawdzam je w systemie kontroli wersji. Ten system robi diff i zlicza wszystkie wprowadzone przeze mnie zmiany.

Im mniejsza liczba, tym lepiej.

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 metryka dla "dobroci kodu" jest tak samo sensowna jak metryka dla " dobrej prozy."Jednak nie oznacza to, że metryki są bezużyteczne, po prostu być może nadużywane.

Na przykład, ekstremalne wartości dla niektórych metryk wskazują drogę do możliwych problemów. Metoda 1000-liniowa to prawdopodobnie nie do utrzymania. Code with zero unit test code coverage prawdopodobnie ma więcej błędów niż podobny kod z dużą ilością testów. Duży skok kodu dodanego do projektu tuż przed wydaniem, który nie jest biblioteką innej firmy, jest prawdopodobnie powodem do dodatkowej uwagi.

Myślę, że jeśli użyjemy metryk jako sugestii -- czerwonej flagi -- być może mogą się przydać. Problem polega na tym, że ludzie zaczynają mierzyć wydajność w SLOC lub jakość w procentach linii z testami.

Metryki i testy automatyczne nie mają zastąpić pełnych recenzji kodu.

Po prostu przyspieszają. Dzięki automatycznemu sprawdzaniu bardzo łatwo jest sprawdzić, których konwencji zapomniałeś przestrzegać, czy używasz wyznaczonych pakietów i metod itp. Możesz zobaczyć, co możesz naprawić bez korzystania z czasu innych ludzi.

Menedżerowie lubią również metryki, ponieważ czują, że otrzymują dokładną liczbę na temat produktywności (choć często tak nie jest) i powinni umieć 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żda metryka, która nie pasuje do tego, będzie cierpieć z powodu optymalizacji zespołu do niego. Chcesz zmierzyć linie kodu? Ojej, zobacz ile potrafią napisać! Chcesz zmierzyć zasięg kodu, do kurwy nędzy, patrz, jak ja go Osłaniam!

Myślę, że metryki mogą być przydatne do identyfikacji trendów i w rzeczywistości widziałem kilka przydatnych, takich jak kreślenie, kiedy build breaks, code churn (liczba linii kodu zmieniających się w całym projekcie) i inne rzeczy. Ale jeśli zespół nie wymyśla ich, albo nie zgadzają się lub nie rozumieją ich, prawdopodobnie jesteś w świecie bólu.

Oto kilka metryk złożoności z stan4j(http://stan4j.com/).

Narzędzie do analizy struktury klas eclipse.

Lubię to narzędzie i metryki. Metryki traktuję jako statystyki, wskaźniki, komunikaty ostrzegawcze. Czasami z powodu niektórych metod lub niektórych klas naprawdę ma jakąś skomplikowaną logikę, która sprawiła, że były złożone, co należy zrobić, to mieć na nie oko, przejrzyj je, aby sprawdzić, czy istnieje potrzeba ich refaktoryzacji lub uważnie je przejrzeć, ponieważ zwykle są one błędem / align = "left" / Również używam go jako narzędzia analizy do nauki kodu źródłowego, ze względu na lubię uczyć się od złożonych do prostych.W rzeczywistości obejmuje ona inne metryki, takie jak Robert C. Martin Metrics, Chidamber & Kemerer Metrics, Count Metrics Ale ten mi się najbardziej podoba

Metryka Złożoności

Cyclomatic Complexity Metrics

Złożoność Cyklomatyczna (CC) Złożoność cyklomatyczna metody jest liczba punktów decyzyjnych na wykresie przepływu sterowania metody / align = "left" / Punkty decyzyjne występują w instrukcjach if / for / while, klauzulach case / catch i podobnych elementach kodu źródłowego, gdzie przepływ sterowania nie jest tylko liniowy. Liczba punktów decyzyjnych (kodu bajtowego) wprowadzanych przez pojedyncze polecenie (kod źródłowy) może być różna, w zależności np. od złożoności wyrażeń boolowskich. Im wyższa jest wartość złożoności cyklomatycznej metody, tym więcej przypadków testowych jest wymaganych do przetestowania wszystkich gałęzi wykresu przepływu sterowania metody.

Średnia Złożoność Cyklomatyczna Średnia wartość metryki złożoności Cyklomatycznej dla wszystkich metod aplikacji, biblioteki, drzewa pakietów lub pakietu.

Fat Metrics Metryka tłuszczu artefaktu to liczba krawędzi na odpowiednim wykresie zależności artefaktu. Typ grafu zależności zależy od wariantu metrycznego i wybranego artefaktu:

Fat Metryka Fat w drzewie aplikacji, biblioteki lub pakietu to liczba krawędzi jego wykres zależności podrzędnych. Ten wykres zawiera wszystkie dzieci artefaktu w hierarchii drzewa pakietów, włączając w to również pakiety liści. (Aby zobaczyć odpowiedni wykres w widoku kompozycja, Przełącznik płaskich pakietów Eksploratora struktury musi być wyłączony. Przełącznik Pokaż biblioteki musi być włączony, jeśli wybrany artefakt jest biblioteką, w przeciwnym razie musi być wyłączony.)

Metryka Fat pakietu jest liczbą krawędzi na wykresie zależności jednostkowych. Wykres ten zawiera wszystkie top klasy poziomu pakietu.

Metryka Fat klasy jest liczbą krawędzi jej wykresu członowego. Wykres ten zawiera wszystkie pola, metody i klasy członkowskie klasy. (Ten wykres i wartość Fat są dostępne tylko wtedy, gdy analiza kodu została przeprowadzona z poziomem szczegółowości członka, a nie Klasy.)

Fat for Library Dependencies (Fat-Libraries) Metryka fat for Library Dependencies aplikacji jest liczbą krawędzi jej wykresu zależności bibliotek. Ten wykres zawiera wszystkie biblioteki aplikacji. (Aby zobaczyć odpowiedni wykres w widoku kompozycja, należy włączyć przełączanie Pokaż Biblioteki Eksploratora struktury.)

Fat for Flat Package Dependencies (Fat-Packages) Metryka Fat dla płaskich zależności pakietu aplikacji jest liczbą krawędzi płaskiego wykresu zależności pakietu. Ten wykres zawiera wszystkie pakiety aplikacji. (Aby zobaczyć odpowiedni wykres w widoku kompozycji, struktura jest płaska Packages toggle musi być włączone i Show Libraries toggle musi być wyłączone.)

Metryka Fat dla płaskich zależności pakietów biblioteki jest liczbą krawędzi płaskiego wykresu zależności pakietów. Ten wykres zawiera wszystkie pakiety biblioteki. (Aby zobaczyć odpowiedni wykres w widoku kompozycja, należy włączyć przełączniki płaskich pakietów i pokaż Biblioteki Eksploratora struktury.)

Fat for Top Level Class Dependencies (Fat-Units) Tłuszcz na najwyższym poziomie Metryką zależności klas aplikacji lub biblioteki jest liczba krawędzi jej wykresu zależności jednostkowych. Ten wykres zawiera wszystkie klasy najwyższego poziomu aplikacji lub biblioteki. (W przypadku rozsądnych zastosowań jest zbyt duży, aby można go było zwizualizować 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 poprawy lub degradacji w projekcie i z pewnością mogą znaleźć naruszenia stylu i konwencji, ale nie ma substytutu dla robienia recenzji kodu rówieśniczego. Bez nich nie można poznać jakości kodu.

Oh ... a to zakłada, że przynajmniej jeden z uczestników Twojej recenzji kodu ma wskazówkę.

Zgadzam się z Tobą, że metryki kodu nie powinny zastępować recenzji kodu, ale uważam, że powinny one uzupełniać recenzje kodu. Myślę, że wraca do starego powiedzenia, że " nie można poprawić tego, czego nie można zmierzyć."Wskaźniki kodu mogą dostarczyć zespołowi programistycznemu wymierne "zapachy kodu" lub wzorce, które mogą wymagać dalszego zbadania. Metryki, które są przechwytywane w większości narzędzi analizy statycznej, są zazwyczaj metrykami, które zostały zidentyfikowane w trakcie badań w naszym krótka historia pola ma istotne znaczenie.

Metryki nie zastępują przeglądu kodu, ale są znacznie tańsze. Są wskaźnikiem ponad wszystko.

Jedną z części odpowiedzi jest to, że niektóre metryki kodu mogą dać bardzo szybką, początkową odpowiedź na pytanie: Jak wygląda ten kod?

Nawet 'linie kodu' mogą dać ci wyobrażenie o rozmiarze bazy kodu, na którą patrzysz.

Jak wspomniano w innej odpowiedzi, trend metryk daje najwięcej informacji.

Metryki same w sobie nie są szczególnie interesujące. Liczy się to, co z nimi robisz.

Na przykład, gdybyś mierzył liczbę komentarzy w linii kodu, co uznałbyś za dobrą wartość? Kto wie? A może co ważniejsze, każdy ma swoje własne zdanie.

Teraz, jeśli zbierzesz wystarczająco dużo informacji, aby móc skorelować liczbę komentarzy w wierszu kodu z czasem poświęconym na rozwiązanie błędu lub z liczbą znalezionych błędów, które są przypisany do kodowania, wtedy możesz zacząć szukać empirycznie użytecznej liczby.

Nie ma różnicy między używaniem metryk w oprogramowaniu a używaniem jakiejkolwiek innej miary wydajności w dowolnym innym procesie - najpierw mierzysz, potem analizujesz, a następnie ulepszasz proces. Jeśli tylko mierzysz, tracisz czas.

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

Ale zanim znajdziesz związek (przyczynowy lub nie), musisz mieć dane.

Wybór danych do zebrania zależy od tego, jaki proces chcesz zweryfikować lub ulepszyć. Na przykład, jeśli próbujesz przeanalizować sukces Twoje procedury sprawdzania kodu (używając własnej definicji "sukcesu", np. ograniczenie błędów lub skrócenie błędów w kodowaniu, skrócenie czasu realizacji itp.), następnie wybierasz metryki, które mierzą całkowitą liczbę błędów i szybkość błędów w recenzowanym kodzie.

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

Myślę, że małe zmiany w metrykach nie są znaczące: funkcja o złożoności 20 niekoniecznie jest czystsza niż funkcja o złożoności 30. Ale warto uruchomić metryki, aby szukać dużych różnic.

Pewnego razu badałem kilkadziesiąt projektów i jeden z nich miał maksymalną wartość złożoności około 6000, podczas gdy każdy inny projekt miał wartość około 100 lub mniej. Uderzyło mnie to w głowę jak kij baseballowy. Oczywiście coś niezwykłego i prawdopodobnie złego, realizował ten projekt.

Jesteśmy programistami. Lubimy liczby.

Poza tym, co zrobisz, nie opisz rozmiaru bazy kodowej, bo "linie metryk kodu są nieistotne"?

Jest zdecydowanie różnica między kodem 150 linii i jednym z 150 milionów, aby wziąć głupi przykład. I nie jest to trudna Liczba do zdobycia.