Rola jakości kodu: kluczowe wskaźniki i ich wpływ

Jakość kodu jest mierzalna. To stwierdzenie wydaje się oczywiste, dopóki nie spróbujesz odpowiedzieć na pytanie, które zadaje CTO przed zakupem oprogramowania lub lider techniczny przed zaangażowaniem się w program refaktoryzacji: skąd wiesz, że kod jest dobry? „Działa” to nie odpowiedź. „Zespół go przejrzał” to nie odpowiedź. Odpowiedź wymaga obiektywnych pomiarów stosowanych konsekwentnie: złożoności cyklomatycznej na funkcję, wskaźnika łatwości utrzymania na moduł, gęstości defektów na tysiąc wierszy, pokrycia testami na komponent, wskaźnika odrzuceń kodu na plik na sprint. Każdy z tych parametrów jest liczbą. Liczby można analizować pod kątem trendów, porównywać z innymi i na ich podstawie podejmować działania.

Wyzwaniem jest to, że metryki jakości kodu nie są zamienne i nie można ich interpretować uniwersalnie. Wysoki wskaźnik utrzymywalności w programie COBOL oznacza co innego niż ten sam wynik w skrypcie Pythona. Złożoność cyklomatyczna na poziomie 15 jest akceptowalna w dobrze przetestowanej maszynie stanów, a poważnym problemem w funkcji walidacji. Gęstość defektów na poziomie 2 błędów na KLOC jest doskonała w programowaniu systemowym i alarmująca w aplikacjach wbudowanych o krytycznym znaczeniu dla bezpieczeństwa. Aby metryki były użyteczne, należy zrozumieć, co każda z nich mierzy, co ją podwyższa lub obniża oraz jakie progi są odpowiednie w danym kontekście. Dalsza część artykułu dokładnie to wyjaśnia.

Czym jest jakość kodu?

Jakość kodu to stopień, w jakim kod źródłowy spełnia zestaw mierzalnych właściwości, które czynią go poprawnym, łatwym w utrzymaniu, czytelnym, wydajnym, bezpiecznym i testowalnym. Żadna pojedyncza właściwość nie definiuje jakości w izolacji. Kod, który działa poprawnie, ale jest nieczytelny, traci na jakości z każdą zmianą, ponieważ programiści, którzy go nie rozumieją, nie mogą go bezpiecznie modyfikować. Kod, który jest czytelny, ale nieprzetestowany, zawiera ukryte defekty. Kod, który jest przetestowany, ale strukturalnie złożony, gromadzi więcej defektów w miarę rozwoju, ponieważ złożoność zwiększa prawdopodobieństwo, że każda zmiana spowoduje nieoczekiwane uszkodzenie.

Formalna definicja zawarta w normie ISO/IEC 25010 określa osiem cech jakości oprogramowania: przydatność funkcjonalną, wydajność, kompatybilność, użyteczność, niezawodność, bezpieczeństwo, łatwość utrzymania i przenośność. W przypadku kodu źródłowego, cechami, które można mierzyć bezpośrednio na podstawie samego kodu, a nie na podstawie zachowania w czasie wykonywania, są: łatwość utrzymania, niezawodność (aproksymowana metrykami defektów i złożoności), bezpieczeństwo (poprzez analizę statyczną) oraz przydatność funkcjonalną (poprzez pokrycie testami). Pozostałe cechy wymagają wykonania kodu w celu pomiaru. Metryki jakości kodu obejmują zatem zdefiniowany i ważny podzbiór jakości oprogramowania, a nie jego całość.

Dlaczego jakość kodu jest ważna

Zespoły techniczne wiedzą, dlaczego jakość kodu jest ważna. Dla interesariuszy biznesowych i zespołów, które muszą wewnętrznie uzasadniać swoje decyzje, powiązaniem są koszty i czas. Badania McKinsey i Konsorcjum ds. Jakości Oprogramowania IT (CISQ) konsekwentnie wykazują, że programiści poświęcają od 30 do 40 procent swojego czasu na radzenie sobie z istniejącym długiem technicznym, zamiast rozwijać nowe funkcjonalności. Niska jakość kodu to mechanizm, który powoduje akumulację długu technicznego: każdy błąd, który nie zostanie wcześnie wykryty, każda funkcja bardziej złożona niż to konieczne, każdy zduplikowany blok logiki, który musi być utrzymywany osobno, zwiększa koszt kolejnej zmiany. Wysoka jakość kodu stale obniża ten koszt, kumulując się przez cały okres użytkowania systemu.

Metryki jakości kodu: kompletne odniesienie

Poniższe wskaźniki obejmują wszystkie główne kategorie pomiaru jakości kodu. Dla każdego wskaźnika wyjaśniono definicję, metodę pomiaru, dopuszczalny zakres oraz interpretację. Progi w poniższej tabeli odzwierciedlają powszechnie cytowane standardy branżowe; zespoły pracujące w środowiskach o krytycznym znaczeniu dla bezpieczeństwa lub podlegających regulacjom powinny stosować bardziej rygorystyczne progi.

Metryki złożoności

Złożoność cyklomatyczna Mierzy liczbę liniowo niezależnych ścieżek przechodzących przez funkcję lub metodę. Został wprowadzony przez Thomasa McCabe'a w 1976 roku i pozostaje najpowszechniej stosowaną miarą złożoności. Wzór zlicza punkty decyzyjne, if, else if, switch przypadki, warunki pętli, catch bloki i operatory warunkowe, a następnie dodaje 1. Funkcja bez rozgałęzień ma złożoność cyklomatyczną równą 1.

Złożoność cyklomatyczna	Interpretacja
1-5	Proste, łatwe do przetestowania
6-10	Umiarkowany, łatwy do opanowania
11-20	Złożone, testowanie staje się trudne
21-50	Bardzo wysokie ryzyko, zalecana refaktoryzacja
50 +	Niemożliwy do przetestowania, niemal pewny, że zawiera defekty

Wysoka złożoność cyklomatyczna jest silnie skorelowana z gęstością defektów. Badania opublikowane w czasopiśmie „IEEE Transactions on Software Engineering” wykazały, że funkcje o złożoności cyklomatycznej powyżej 10 mają znacznie wyższy wskaźnik defektów niż funkcje prostsze. analiza złożoności cyklomatycznej w starszych bazach kodu problemem jest znalezienie funkcji, w których na przestrzeni lat skumulowała się logika decyzyjna, a cała struktura nie została poddana refaktoryzacji przez nikogo.

Złożoność NPath Zlicza liczbę unikalnych ścieżek wykonania funkcji, w tym ścieżek utworzonych przez zagnieżdżone warunki i pętle. Podczas gdy złożoność cyklomatyczna zlicza rozgałęzienia liniowo, złożoność NPath je mnoży: funkcja z trzema sekwencyjnymi blokami if-else ma złożoność cyklomatyczną równą 4, ale złożoność NPath równą 8, ponieważ każdy warunek może być niezależnie prawdziwy lub fałszywy. Złożoność NPath rośnie wykładniczo wraz z zagnieżdżaniem. Wartość powyżej 200 oznacza funkcję, która wymagałaby większej liczby przypadków testowych, niż jakikolwiek zespół jest w stanie realistycznie napisać.

Złożoność poznawcza Został wprowadzony przez SonarSource i mierzy stopień trudności kodu w zrozumieniu, a nie liczbę zawartych w nim ścieżek. Kary za zagnieżdżanie są większe niż za rozgałęzienia liniowe: if wewnątrz a while wewnątrz innego if wyniki wyższe niż trzy kolejne if instrukcji o tej samej złożoności cyklomatycznej. Złożoność poznawcza lepiej odzwierciedla rzeczywiste trudności, z jakimi borykają się programiści podczas czytania kodu. Złożoność poznawcza powyżej 15 na metodę jest zazwyczaj oznaczana do weryfikacji; powyżej 25 oznacza funkcję, którą większość programistów będzie miała autentycznie trudno racjonalnie interpretować.

Metryki Halsteada Wyprowadzić rodzinę miar z czterech liczb w kodzie źródłowym: operatorów odrębnych (n1), operandów odrębnych (n2), operatorów sumarycznych (N1) i operandów sumarycznych (N2). Na tej podstawie Halstead oblicza:

• objętość (N × log2(n)): rozmiar implementacji w treści informacyjnej
• Trudność (n1/2 × N2/n2): oszacowanie stopnia trudności napisania lub zrozumienia kodu
• Wysiłek (Objętość × Trudność): szacowany całkowity wysiłek umysłowy potrzebny do wdrożenia lub zrozumienia kodu

Metryki Halsteada są szczególnie przydatne do porównywania funkcji o podobnej złożoności cyklomatycznej, aby określić, która z nich jest trudniejsza do zrozumienia. Funkcja z 10 gałęziami nad zmiennymi o wyraźnych nazwach ma mniejszy problem Halsteada niż funkcja z 10 gałęziami nad indeksami obliczeniowymi i identyfikatorami jednoznakowymi.

Metryki utrzymywalności

Indeks łatwości utrzymania to metryka złożona, pierwotnie opracowana przez Paula Omana i Jacka Hagemeistera, a następnie przyjęta przez Microsoft Visual Studio jako standardowa miara łatwości utrzymania. Łączy ona objętość Halsteada, złożoność cyklomatyczną i wiersze kodu w jeden wynik.

Formuła programu Visual Studio generuje wynik od 0 do 100:

Indeks łatwości utrzymania	Ocena
20-100	Utrzymywalny (zielony)
10-19	Umiarkowana potrzeba konserwacji (żółty)
0-9	Trudny w utrzymaniu (czerwony)

Wskaźnik łatwości utrzymania to statystyka podsumowująca. Jest on najbardziej przydatny do identyfikacji wartości odstających, plików lub modułów z czerwoną strefą, a nie do szczegółowego porównywania modułów z zieloną strefą. W Pythonie radon Biblioteka oblicza indeks łatwości utrzymania bezpośrednio. W programie Visual Studio pojawia się on w oknie metryk kodu. statyczna analiza kodu Platformy, wskaźnik łatwości utrzymania jest zazwyczaj jednym ze standardowych wyników, obok złożoności cyklomatycznej i linii kodu.

Wiersze kodu (LOC) i KLOC Zmierz rozmiar bazy kodu w wierszach lub tysiącach wierszy. Sam LOC nic nie mówi o jakości, ale dostarcza istotnych mianowników dla innych metryk: gęstość defektów to liczba błędów na KLOC, gęstość komentarzy to liczba komentarzy na LOC, gęstość testów to liczba asercji testowych na LOC. LOC skaluje również koszt złożoności: funkcja 500-wierszowa o złożoności cyklomatycznej równej 20 stanowi znacznie większy problem niż funkcja 50-wierszowa o tym samym wyniku.

Churn kodu To tempo zmian kodu w czasie, mierzone jako liczba dodanych, usuniętych i zmodyfikowanych wierszy na plik w jednostce czasu. Wysoki wskaźnik rotacji kodu wskazuje na niestabilność: kod, który często się zmienia, może być podatny na błędy w projekcie, które nie były poprawne od samego początku, niestabilne wymagania lub błędy, które wymagają ciągłych poprawek. Badania przeprowadzone przez Microsoft wykazały, że pliki w 10% przypadków rotacji kodu zawierały pięć razy więcej defektów niż pliki z niską rotacją. Śledzenie rotacji kodu wraz ze wskaźnikami defektów ujawnia, czy częste zmiany poprawiają jakość, czy generują nowe problemy.

Metryki pokrycia kodu

Pokrycie testów jednostkowych to procent wierszy, rozgałęzień lub warunków w bazie kodu, które są wykonywane przez testy jednostkowe. Najbardziej miarodajną formą jest pokrycie rozgałęzień: czy każda decyzja w kodzie może zostać osiągnięta przez co najmniej jeden test zarówno w przypadku wyniku „prawda”, jak i „fałsz”. Pokrycie wierszy jest łatwiejsze do oszukania – test, który wykonuje każdy wiersz bez żadnych asercji, osiąga 100% pokrycia wierszy i niczego nie wychwytuje.

Branżowe wzorce pokrycia testów jednostkowych:

• Poniżej 50%: niewystarczające, większość defektów nie zostanie wykryta przez testy
• 50-75%: umiarkowany, główne ścieżki pokryte, skrajne przypadki prawdopodobnie pominięte
• 75-90%: dobre dla większości kodu aplikacji
• Powyżej 90%: odpowiednie dla systemów o krytycznym znaczeniu dla bezpieczeństwa lub o wysokiej niezawodności

Pokrycie kodem w aplikacjach o znaczeniu krytycznym dla bezpieczeństwa Normy DO-178C dotyczące oprogramowania lotniczego i IEC 61508 dotyczące bezpieczeństwa funkcjonalnego określają wymagania dotyczące pokrycia (pokrycie MC/DC dla najwyższych poziomów krytyczności), które wykraczają poza standardowe testy jednostkowe. Poprawa jakości kodu w aplikacjach krytycznych dla bezpieczeństwa wymaga narzędzi do pomiaru pokrycia, które śledzą pokrycie warunków/decyzji i mogą generować formalne dowody wymagane przez organy certyfikujące.

Gęstość testu Uzupełnia pokrycie, mierząc liczbę asercji testowych w stosunku do rozmiaru kodu produkcyjnego. Wysokie pokrycie przy niskiej gęstości testów może wskazywać na testy, które wykonują kod bez sensownej weryfikacji działania. Wysoka gęstość testów przy niskim pokryciu wskazuje na testy skoncentrowane w małej części bazy kodu.

Metryki defektów

Gęstość błędów (znany również jako Defect Density) to liczba potwierdzonych defektów na tysiąc linii kodu (KLOC). Jest to najbardziej bezpośrednia ilościowa miara poprawności kodu. Branżowe benchmarki CISQ wskazują, że komercyjne oprogramowanie gotowe ma średnio około 15–50 defektów na KLOC przed testowaniem; po testach i wydaniu, wysokiej jakości komercyjne oprogramowanie zazwyczaj ma mniej niż 1 defekt na KLOC.

Wyniki analizy statycznej przybliżona gęstość defektów przed potwierdzeniem ich obecności w testach lub w warunkach produkcyjnych. Narzędzia takie jak SonarQube, Checkmarx i SMART TS XL Przeanalizuj bazę kodu pod kątem wzorców powiązanych ze znanymi klasami defektów i luk w zabezpieczeniach, tworząc liczbę potencjalnych problemów sklasyfikowanych według wagi. Stosunek ustaleń krytycznych i blokujących do poziomu kontroli (LOC) zapewnia wczesny sygnał jakości kodu, zanim trafi on do testów.

Kod gęstości zapachu Zlicza obecność antywzorców, duplikatów kodu, zbyt długich funkcji, nadmiernego sprzężenia klas, zazdrości o funkcje, obiektów o wysokiej wartości, zgodnie z KLOC. Zapachy kodu nie powodują natychmiastowych awarii, ale przewidują przyszłe defekty i koszty utrzymania. Baza kodu o wysokiej gęstości zapachów kodu to taka, w której koszt każdej przyszłej zmiany jest wysoki, ponieważ każda zmiana musi pokonać nagromadzone problemy strukturalne.

Metryki czytelności i stylu

Komentarz Gęstość to stosunek liczby wierszy komentarzy do liczby wierszy kodu. Optymalne zakresy różnią się w zależności od języka i konwencji zespołu, ale zazwyczaj mieszczą się w przedziale 10–30%. Poniżej 10% może wskazywać na niedostatecznie udokumentowany kod; powyżej 50% może oznaczać kod tak złożony, że wymaga obszernego wyjaśnienia nieoczywistej logiki. Jakość komentarzy jest ważniejsza niż ich ilość: komentarz, który powtarza, co kod robi (// increment i by 1) niczego nie wnosi, natomiast komentarz wyjaśniający, dlaczego wybrano konkretny algorytm, wnosi znaczną wartość.

Zgodność z konwencją nazewnictwa Mierzy odsetek identyfikatorów (zmiennych, funkcji, klas) zgodnych z konwencjami nazewnictwa projektu. Zautomatyzowane narzędzia mogą egzekwować konwencje nazewnictwa w ramach konfiguracji lintingu. Spójne nazewnictwo to jedno z najważniejszych usprawnień w zakresie czytelności, ponieważ pozwala programistom przewidzieć przeznaczenie identyfikatora na podstawie samej nazwy, zmniejszając obciążenie poznawcze związane z czytaniem nieznanego kodu.

Współczynnik duplikacji kodu Mierzy odsetek bazy kodu zduplikowanej w wielu lokalizacjach. Duplikacja powyżej 5% jest zazwyczaj oznaczana. Duplikacja kodu zwielokrotnia nakład pracy konserwacyjnej: błąd w zduplikowanej logice musi zostać znaleziony i naprawiony w każdej kopii, a zmiany w działaniu muszą być stosowane spójnie we wszystkich kopiach. Duplikacja zaciemnia również rzeczywisty rozmiar bazy kodu: system, który wydaje się mieć 100 000 wierszy, może zawierać 40 000 wierszy unikalnej logiki i 60 000 wierszy kopii.

Wskaźniki bezpieczeństwa i długu technicznego

Wskaźnik zadłużenia technicznego SonarQube definiuje wskaźnik zadłużenia technicznego jako stosunek szacowanego kosztu naprawy do szacowanego kosztu rozwoju bazy kodu. Wskaźnik zadłużenia technicznego poniżej 5% jest uważany za czysty kod; powyżej 20% oznacza znaczne zadłużenie, które znacząco spowolni przyszły rozwój.

Gęstość punktów dostępu do zabezpieczeń Zlicza liczbę punktów newralgicznych, wzorców kodu wymagających weryfikacji bezpieczeństwa oraz niepotwierdzonych luk w zabezpieczeniach, na jednostkę KLOC. Przykładami są nieparametryzowane zapytania SQL, użycie przestarzałych funkcji kryptograficznych oraz obsługa niesprawdzonych danych wejściowych. Narzędzia do analizy statycznej identyfikują te wzorce i przedstawiają je jako elementy wymagające ręcznej weryfikacji bezpieczeństwa.

Gęstość podatności Liczba potwierdzonych luk w zabezpieczeniach według KLOC, zazwyczaj kategoryzowanych według wagi CVSS. Ta metryka jest najbardziej znacząca w kontekście audytów bezpieczeństwa po wydaniu lub procesów ciągłego monitorowania bezpieczeństwa.

Jak mierzyć jakość kodu: praktyczne podejście

Pomiar jakości kodu to nie jednorazowa czynność, lecz ciągła praktyka wbudowana w proces rozwoju oprogramowania. Pragmatyczne, czterofazowe podejście sprawdza się w przypadku zespołów, które zaczynają pracę od niezmierzonej bazy kodu.

Faza 1: Ustalenie punktu bazowego. Przed wprowadzeniem jakichkolwiek zmian należy przeprowadzić pełną analizę statyczną kodu źródłowego. Zanotuj aktualne wartości rozkładu złożoności cyklomatycznej, wskaźnika łatwości utrzymania dla każdego pliku, gęstości defektów, pokrycia i współczynnika duplikacji. Ta linia bazowa stanowi punkt wyjścia, z którym porównywane są wszystkie przyszłe pomiary. Bez niej nie można stwierdzić, czy zmiany poprawiają, czy pogarszają jakość.

Faza 2: Określenie progów. Ustal akceptowalne progi dla każdej metryki, odpowiednie do kontekstu. Komercyjna aplikacja internetowa i urządzenie medyczne o krytycznym znaczeniu dla bezpieczeństwa mają różne odpowiednie progi. Udokumentuj te progi w standardach jakości projektu i udostępnij je całemu zespołowi.

Faza 3: Integracja z CI/CD. Skonfiguruj potok CI, aby obliczać kluczowe metryki dla każdego zatwierdzenia lub żądania ściągnięcia. Oznacz zmiany, które przesuwają metrykę poza dopuszczalny zakres. Scalanie bloków, które wprowadza nowy kod o złożoności cyklomatycznej powyżej progu, zmniejsza pokrycie poniżej progu lub wprowadza krytyczne wyniki analizy statycznej. Dzięki temu progi metryk z wytycznych staną się egzekwowanymi standardami.

Faza 4: Przegląd trendów, a nie migawek. Pojedynczy odczyt metryki jest informacyjny; trend jest użyteczny. Rosnąca tendencja rotacji kodu w konkretnym module, malejąca tendencja pokrycia w całym cyklu wydawniczym lub malejący wskaźnik utrzymywalności dla konkretnego pliku – to wszystko sygnalizuje problemy, które mogą zostać przeoczone przez pomiar migawki. Analizuj trendy metryk podczas każdej retrospektywy sprintu.

Metryki jakości kodu w kontekście przedsiębiorstwa, metodyki Agile i kontekstów krytycznych dla bezpieczeństwa

Metryki jakości kodu w programowaniu zwinnym

Zespoły Agile stoją przed szczególnym wyzwaniem związanym z metrykami jakości kodu: nacisk na dostarczanie działającego oprogramowania w krótkich cyklach może stwarzać presję na wydanie go przed rozwiązaniem problemów z jakością. Rozwiązaniem nie jest rezygnacja z metryk, ale uwzględnienie ich w definicji ukończenia. Historia nie jest ukończona, gdy funkcja działa; jest ukończona, gdy funkcja działa, a nowy kod spełnia progi jakościowe zespołu.

W kontekstach Agile do wskaźników wyprzedzających, czyli metryk przewidujących przyszłe problemy, zanim się pojawią, należą wskaźnik rotacji kodu, nowy dług techniczny wprowadzany w sprincie oraz trend w liczbie wyników analizy statycznej w danym wydaniu. Do wskaźników opóźnionych, czyli metryk mierzących już uzyskane rezultaty, należą: gęstość defektów wykrytych w testach, czas poświęcony na konserwację w porównaniu z nowymi funkcjami oraz wskaźnik incydentów produkcyjnych w danym wydaniu.

Jakość kodu na potrzeby należytej staranności technicznej

Techniczna analiza due diligence w transakcjach fuzji i przejęć, wyborze dostawców i procesach przejmowania systemów wymaga ustrukturyzowanej oceny jakości kodu w całej bazie. W tym kontekście najważniejsze są następujące wskaźniki:

• Dystrybucja wskaźnika utrzymywalności:jaki procent bazy kodu mieści się w strefie czerwonej, żółtej i zielonej
• Wskaźnik zadłużenia technicznego:jaki jest szacunkowy koszt naprawy w stosunku do kosztów rozwoju
• Gęstość defektów:ile znanych defektów występuje w przypadku każdego KLOC i jak wypada to w porównaniu z branżowymi punktami odniesienia
• Pokrycie testowe:jaki procent bazy kodu jest objęty testami automatycznymi i na jakim poziomie (linia, gałąź, warunek)
• Zdrowie osób uzależnionych:ile zależności zewnętrznych istnieje, ile jest nieaktualnych lub porzuconych i jak głęboko powiązana jest architektura
• Duplikacja kodu:jaka część bazy kodu jest zduplikowana, co wskazuje na ryzyko związane z konserwacją

W kontekście badania analiza wpływu na ocenę kodu przedsiębiorstwaAby przeprowadzić dokładną analizę due diligence, konieczne jest zrozumienie nie tylko wyników każdego komponentu w metrykach jakości, ale także tego, w jaki sposób komponenty te są od siebie zależne: moduł niskiej jakości, który jest izolowany, może oznaczać rozsądne koszty naprawy, podczas gdy ten sam moduł w centrum gęstego grafu zależności oznacza znacznie większe ryzyko.

Jakość kodu w aplikacjach o znaczeniu krytycznym dla bezpieczeństwa i aplikacjach Fintech

Aplikacje o znaczeniu krytycznym dla bezpieczeństwa w lotnictwie, motoryzacji, urządzeniach medycznych i sterowaniu przemysłowym wymagają standardów jakości kodu wykraczających poza typowe oprogramowanie komercyjne. Kluczowe różnice:

• Limity złożoności cyklomatycznej są zazwyczaj ustalane na poziomie 10 lub niższym, a wyjątki wymagają formalnego uzasadnienia
• Wymagania dotyczące pokrycia wykorzystują MC/DC (zmodyfikowany stan/pokrycie decyzji) zamiast pokrycia linii lub gałęzi
• Analizę statyczną należy przeprowadzać przy użyciu certyfikowanych narzędzi, a naruszenia muszą być udokumentowane i rozwiązane lub formalnie zaakceptowane
• Wskaźnik rotacji kodu jest monitorowany jako wskaźnik bezpieczeństwa: wysokie wskaźniki zmian w modułach krytycznych dla bezpieczeństwa powodują konieczność przeprowadzenia dodatkowych przeglądów i ponownej walidacji

Aplikacje FinTech stoją w obliczu podobnej presji ze strony ram regulacyjnych. PCI DSS wymaga bezpiecznych standardów kodowania i procesów przeglądu kodu. Zgodność systemów raportowania finansowego z ustawą SOX wymaga udokumentowanej identyfikowalności od wymagań, przez kod, aż po testy. Metryki jakości kodu dostarczają obiektywnych dowodów na to, że te procesy działają: raporty pokrycia dowodzą istnienia testów, raporty analizy statycznej dowodzą, że sprawdzono znane wzorce podatności, a raporty złożoności dowodzą, że recenzenci byli w stanie racjonalnie ocenić kod.

Metryki jakości kodu według języka

Metryki jakości kodu Pythona można obliczyć za pomocą radon (wskaźnik złożoności cyklomatycznej i utrzymywalności), pylint (błędy w kodzie i naruszenia stylu), coverage.py (pokrycie testowe), bandit (kwestie bezpieczeństwa) i mypy or pyright (poprawność typu). Wskaźnik utrzymywalności w radon Używa zmodyfikowanego wzoru Halsteada skalibrowanego dla Pythona. Ocena A to powyżej 20, ocena B to 10-20, ocena C to poniżej 10.

Jakość kodu RPG w systemie IBM i wymagane są specjalistyczne narzędzia, ponieważ standardowe narzędzia do pomiaru jakości nie analizują składni języka RPG. SMART TS XL zapewnia analizę złożoności cyklomatycznej, linii kodu i zależności dla programów RPG, co jest szczególnie cenne dla działów IBM i zarządzających dużymi, starszymi bazami kodu, w których dotychczas nie było możliwe zautomatyzowanie pomiaru jakości.

Metryki przeglądu kodu

Przegląd kodu to czynność kontroli jakości, której skuteczność można zmierzyć:

• Recenzja pokrycia: procent zatwierdzonego kodu, który przeszedł formalną kontrolę przed scaleniem
• Wady znalezione podczas przeglądu: liczba usterek wykrytych podczas przeglądu w stosunku do rozmiaru przeglądanego zestawu zmian
• Sprawdź czas realizacji:czas od otwarcia żądania ściągnięcia do jego przejrzenia i scalenia
• Przejrzyj współczynnik rozwiązywania komentarzy: procent komentarzy w recenzjach skutkujących zmianą kodu w porównaniu do odrzucenia

Zespoły o wysokiej wydajności zazwyczaj charakteryzują się pokryciem przeglądów powyżej 90%, średnią liczbą znalezionych defektów na przegląd wynoszącą od 1 do 3 na sto sprawdzonych wierszy kodu oraz krótkim czasem realizacji. Metryki przeglądów pomagają określić, czy przegląd kodu pełni funkcję kontroli jakości, czy jest formalnością.

Ciągłe monitorowanie jakości kodu

Jednorazowy pomiar jakości kodu jest znacznie mniej wartościowy niż ciągłe monitorowanie. Jakość kodu nie jest stałą cechą bazy kodu; zmienia się z każdym commitem. Baza kodu, która dziś dobrze mierzy, może znacznie się pogorszyć po trzech sprintach pospiesznego rozwoju, jeśli wskaźniki jakości nie będą stale monitorowane.

Efektywne ciągłe monitorowanie jakości kodu obejmuje:

• Obliczanie metryki na zatwierdzenie:złożoność cyklomatyczna i wyniki analizy statycznej obliczane przy każdym naciśnięciu
• Panele trendów:wizualizacje kluczowych wskaźników na przestrzeni czasu, aktualizowane codziennie lub po każdym wydaniu
• Bramki jakości w CI/CD:automatyczne egzekwowanie minimalnych progów dla metryk mających wpływ na możliwość utrzymania, bezpieczeństwo i ryzyko wystąpienia defektów
• Wykrywanie regresji: ostrzega, gdy metryka znacząco zmienia się w złym kierunku pomiędzy wersjami

Wiodącymi wskaźnikami poprawy jakości kodu, czyli sygnałami, które przewidują, czy jakość będzie lepsza, czy gorsza w kolejnej wersji, są kierunek trendu pokrycia, nowa złożoność wprowadzana w każdym sprincie oraz stosunek liczby rozwiązanych problemów z kodem do liczby problemów z kodem wprowadzonych. Gdy te zmiany idą w dobrym kierunku, jakość się poprawi. Gdy nie, pogorszenie jest przewidywalne, zanim jeszcze nastąpi.

W jaki sposób SMART TS XL Mierzy i poprawia jakość kodu

SMART TS XL oblicza pełny zestaw metryk jakości kodu opisanych w tym artykule dla każdego języka i platformy w środowisku programistycznym: COBOL, JCL, Java, .NET, Python, JavaScript, TypeScript, RPG, SQL i innych. Podczas gdy większość narzędzi jakościowych działa jednocześnie w jednym języku, SMART TS XL buduje ujednolicony model jakości całego systemu, umożliwiając porównywanie jakości w różnych językach, śledzenie wskaźników na poziomie systemu, a nie na poziomie pliku, oraz identyfikowanie problemów z jakością obejmujących różne komponenty, których narzędzia jednojęzyczne nie są w stanie wykryć.

W przypadku przedsiębiorstw z dużymi, wielojęzycznymi bazami kodów statyczna analiza kodu zdolność SMART TS XL zapewnia pomiar bazowy, którego wymagają: należyta staranność techniczna, planowanie modernizacji starszych systemów i ciągłe doskonalenie jakości. mapowanie zależności Funkcja ta rozszerza ocenę jakości o kwestie strukturalne: które komponenty są najbardziej zależne, które zmiany mają największy zasięg oraz które obszary bazy kodu stanowią najwyższe ryzyko konserwacyjne, gdy metryki jakości zostaną połączone z centralnością zależności.

SMART TS XLMetryki jakości kodu firmy integrują się z procesami DevOps poprzez API, umożliwiając kontrolę jakości na poziomie CI/CD. Gdy commit wprowadza funkcję o złożoności cyklomatycznej przekraczającej próg, zmniejsza pokrycie poniżej skonfigurowanego minimum lub wprowadza krytyczne odkrycie analizy statycznej, proces może odrzucić kompilację, generując specjalną diagnostykę, która dokładnie informuje programistę, co zostało zmierzone i dlaczego nie przekroczyło progu. Przenosi to egzekwowanie jakości z audytów po wydaniu na informacje zwrotne w trakcie rozwoju, zmniejszając koszty rozwiązywania problemów z jakością poprzez ich wykrycie w momencie, gdy ich naprawa jest najtańsza.

Jakość kodu to dyscyplina zespołowa, a nie raport

Wartość metryk jakości kodu zależy wyłącznie od tego, jak zespoły z nimi postępują. Kwartalny raport o jakości kodu, na który nikt nie reaguje, jest gorszy niż brak raportu, ponieważ stwarza iluzję, że jakość jest zarządzana, podczas gdy baza kodu pogarsza się bez kontroli. Metryki stają się cenne, gdy kierują konkretnymi działaniami: gdy skok złożoności cyklomatycznej w nowej funkcji uruchamia konwersację refaktoryzacji przed jej scaleniem, gdy spadek pokrycia w module uruchamia sprint testowy, gdy rosnąca gęstość defektów w konkretnym komponencie uruchamia formalny przegląd projektu tego komponentu.

Zbudowanie takiej kultury wymaga uwidocznienia metryk we właściwym czasie, w trakcie rozwoju, a nie po wydaniu, oraz powiązania ich z konkretnymi zobowiązaniami zespołu. Zespoły, które analizują trendy jakości kodu podczas każdej retrospektywy sprintu, uwzględniają progi jakości w definicji ukończenia i traktują regresję metryk tak poważnie, jak regresję funkcjonalności, budują bazy kodu, których utrzymanie jest tańsze i generują mniej incydentów produkcyjnych w czasie. Pomiar jest punktem wyjścia. Dyscyplina przynosi rezultat.