Obiektywne wskaźniki jakości oprogramowania [zamknięte]

Istnieją różne rodzaje jakości, które można mierzyć w oprogramowaniu, np. Przydatność do określonego celu (np. Zastosowanie końcowe), łatwość konserwacji, wydajność. Niektóre z nich są nieco subiektywne lub specyficzne dla danej dziedziny (np. Dobre zasady projektowania GUI mogą być różne w różnych kulturach lub zależą od kontekstu użytkowania, w zależności od użycia w celach militarnych i konsumenckich).

Interesuje mnie głębsza forma jakości związana z siecią (lub wykresem) typów i ich wzajemnymi powiązaniami, to znaczy do jakich typów odnosi się każdy typ, czy istnieją wyraźnie identyfikowalne klastry wzajemnych połączeń odnoszące się do właściwie architektura wielopoziomowa, lub odwrotnie, istnieje duża „kula” odniesień typu (kod „monolityczny”). Również rozmiar każdego typu i / lub metody (np. Mierzony ilością kodu bajtowego Java lub .Net IL) powinien dać pewne wskazanie, gdzie duże złożone algorytmy zostały zaimplementowane jako monolityczne bloki kodu zamiast być rozkładane na łatwiejsze w zarządzaniu / utrzymywaniu kawałki.

Analiza oparta na takich pomysłach może być w stanie obliczyć wskaźniki, które są co najmniej wskaźnikiem jakości. Podejrzewam, że dokładne progi / punkty decyzyjne pomiędzy wysoką a niską jakością są subiektywne, np. Ponieważ przez łatwość utrzymania rozumiemy przez to możliwość utrzymania przez ludzkich programistów, a zatem rozkład funkcjonalny musi być zgodny z tym, jak działają ludzkie umysły. Jako taki zastanawiam się, czy kiedykolwiek może istnieć matematycznie czysta definicja jakości oprogramowania, która wykracza poza wszelkie możliwe oprogramowanie we wszystkich możliwych scenariuszach.

Zastanawiam się również, czy to niebezpieczny pomysł, że jeśli obiektywne wskaźniki jakości staną się popularne, presja biznesowa spowoduje, że programiści zastosują te wskaźniki kosztem ogólnej jakości (tych aspektów jakości, które nie są mierzone przez proxy).

Innym sposobem myślenia o jakości jest z punktu widzenia entropii. Entropia to tendencja systemów do zmiany stanu z uporządkowanego na nieuporządkowany. Każdy, kto kiedykolwiek pracował nad prawdziwym światowym projektem oprogramowania o średniej i dużej skali, z pewnością doceni stopień, w jakim jakość bazy kodu z czasem spada. Presja biznesowa generalnie powoduje zmiany, które koncentrują się na nowej funkcjonalności (z wyjątkiem sytuacji, gdy sama jakość jest głównym punktem sprzedaży, np. W oprogramowaniu awionicznym), a także obniżaniu jakości poprzez problemy z regresją i funkcjonalność „klaksonu”, gdzie nie pasuje dobrze perspektywa jakości i utrzymania. Czy możemy zmierzyć entropię oprogramowania? A jeśli tak, to w jaki sposób?

To niebezpieczny pomysł. „Obiektywne” parametry pośrednie w zakresie jakości prowadzą bezpośrednio do nagród dla kierownictwa, a programiści zastosują się do tych wskaźników kosztem rzeczywistej jakości.

To jest prawo niezamierzonych konsekwencji.

Jakość - choć ważna - jest tylko jednym małym aspektem oprogramowania. Funkcjonalność i wartość tworzone przez oprogramowanie są o wiele ważniejsze niż jakość.

Wszystkie dane prowadzą do aktywności w celu optymalizacji danych. To z kolei ma konsekwencje, których możesz nie lubić.

Oprogramowanie jest bardzo złożone. Trudno zrozumieć, jak naprawdę jest złożona.

Nawet takie „oczywiste” rzeczy, jak pokrycie kodu testu jednostkowego, mogą tracić czas. Osiągnięcie 100% może wymagać stworzenia testów, które są w rzeczywistości bardziej złożone niż testowany trywialny kod. Dotarcie do 100% ubezpieczenia może wiązać się z niedopuszczalnym kosztem. [Alternatywą dla trywialnego, małego, rzadko używanego kodu jest test przez kontrolę. Ale to nie pasuje do 100-metrowej gry.]

Innym przykładem jest cykliczność. Jest to jedna z najlepszych miar jakości kodu. Ale można w nią grać, tworząc wiele małych funkcji, które mogą być trudniejsze do odczytania (i trudniejsze w utrzymaniu) niż jedna większa funkcja. Kończymy w recenzjach kodu, w których zgadzasz się, że może nie być bardzo czytelny, ale spełnia próg złożoności.

Zastanawiam się również, czy to niebezpieczny pomysł, że jeśli obiektywne wskaźniki jakości staną się popularne, presja biznesowa spowoduje, że programiści zastosują te wskaźniki kosztem ogólnej jakości (tych aspektów jakości, które nie są mierzone przez proxy).

Bingo, a nie „jeśli” o tym. Nazywa się to „dysfunkcją pomiaru” i zostało zaobserwowane i napisane wiele razy, gdy Joel napisał na ten temat artykuł w 2002 roku, odnosząc się do książki profesora Harvarda.

To nie znaczy, że takie wskaźniki są bezużyteczne, tylko że nigdy nie należy opierać zachęt ani zasad wyraźnie na takich pomiarach zastępczych. Jeśli chcesz poprawić jakość, dobrym pomysłem jest rozpoczęcie pomiaru proxy o bardzo złej wartości. Ale nie można stwierdzić, że jakość jest dobra tylko dlatego, że wszystkie dane mają świetne wartości.

Interesuje mnie głębsza forma jakości związana z siecią (lub wykresem) typów i ich wzajemnymi powiązaniami, to znaczy do jakich typów odnosi się każdy typ, czy istnieją wyraźnie identyfikowalne klastry wzajemnych połączeń odnoszące się do właściwie architektura wielopoziomowa, lub odwrotnie, istnieje duża „kula” odniesień typu (kod „monolityczny”).

To brzmi jak wachlowanie i wachlowanie. Fan-in zlicza liczbę modułów, które wywołują dany moduł, a fan-out zlicza liczbę modułów wywoływanych przez dany moduł. Znakiem ostrzegawczym do użycia byłyby moduły, które mają duży wachlarz i duży wachlarz, ponieważ może to wskazywać na słabą konstrukcję i kluczowy cel dla refaktoryzacji lub przeprojektowania.

Również rozmiar każdego typu i / lub metody (np. Mierzony ilością kodu bajtowego Java lub .Net IL) powinien dać pewne wskazanie, gdzie duże złożone algorytmy zostały zaimplementowane jako monolityczne bloki kodu, zamiast być rozkładane na łatwiejsze w zarządzaniu / utrzymywaniu kawałki.

Prostym pomiarem byłyby linie kodu. Możesz podzielić go na wszystkie wiersze kodu w całym projekcie i wiersze kodu na moduł (być może przy użyciu modułów o różnych rozmiarach). Możesz użyć tego jako wskaźnika ostrzegawczego wskazującego, że powinieneś przejrzeć poszczególne moduły. Książka o pomiarach i pomiarach jakości oprogramowania omawia niektóre prace, które wskazują, że związek między współczynnikami defektów a rozmiarem modułu jest krzywoliniowy, przy czym średni defekt na KSLOC pochodzi z modułów o wielkości od 175 do 350 SLOC.

Coś nieco bardziej złożonego byłoby złożonością cykliczną, która ma na celu wskazanie testowalności, zrozumiałości i możliwości utrzymania systemu. Cyklomatyczna złożoność zlicza liczbę niezależnych ścieżek przez aplikację lub moduł. Liczba testów, a co za tym idzie wysiłek potrzebny do wykonania i wykonania testów, jest ściśle związana ze złożonością cykliczną.

Podejrzewam, że dokładne progi / punkty decyzyjne pomiędzy wysoką a niską jakością są subiektywne, np. Ponieważ przez łatwość utrzymania rozumiemy przez to możliwość utrzymania przez ludzkich programistów, a zatem rozkład funkcjonalny musi być zgodny z tym, jak działają ludzkie umysły.

Nie jestem pewien, czy tak jest.

Na przykład, istnieją badania sugerujące, że pamięć robocza człowieka może pomieścić tylko 7 obiektów plus / minus 2 . Prawdopodobnie jest to interesujące w przypadku pomiaru wachlarza i wachlarza - jeśli pracuję w module i jest on podłączony do więcej niż ~ 7 innych modułów, prawdopodobnie nie będę w stanie dokładnie śledzić, co te inne moduły są w mojej głowie.

Pracowano także nad powiązaniem defektów z miernikami, takimi jak złożoność cykliczna. Ponieważ chcesz zminimalizować defekty w systemie, możesz zidentyfikować punkty, które wymagają większego wysiłku w testowaniu lub refaktoryzacji, na co wskazuje duża złożoność cykliczna.

Zastanawiam się również, czy to niebezpieczny pomysł, że jeśli obiektywne wskaźniki jakości staną się popularne, presja biznesowa spowoduje, że programiści zastosują te wskaźniki kosztem ogólnej jakości (tych aspektów jakości, które nie są mierzone przez proxy).

Tak jest w przypadku wszelkich pomiarów lub miar. Muszą być używane do zrozumienia systemu i podejmowania świadomych decyzji. Przyszło mi na myśl wyrażenie „nie możesz zarządzać tym, czego nie możesz zmierzyć”. Jeśli potrzebujesz oprogramowania wysokiej jakości, potrzebujesz kilku pomiarów i wskaźników, aby ocenić tę jakość. Istnieje jednak druga strona. Nie możesz zarządzać wyłącznie za pomocą liczb. Możesz używać liczb do podejmowania świadomych decyzji, ale nie możesz podejmować decyzji tylko dlatego, że tak mówią liczby.

Istnieją wskaźniki lub wskaźniki zastępcze dla wielu cech, którymi jesteś zainteresowany:

1. Linie kodu
2. Wachluj, wachluj
3. Współczynnik błędów na 1000 linii kodu
4. Złożoność cykliczna
5. Pokrycie kodu
6. Zasięg punktów decyzyjnych
7. Współczynnik błędów naprawionych / wprowadzonych przez czynności konserwacyjne
8. Analiza punktu funkcji

Występują pewne problemy ze wszystkimi tymi elementami:

1. Trwają prace nad optymalizacją miernika - trend uniwersalny; znacznie zaostrzone, jeśli którykolwiek z mierników zostanie wykorzystany jako podstawa oceny lub nagrody dla zespołów lub osób.
2. Nie znam żadnych danych, które nie zawierają kontekstu. Oznacza to, że porównanie nie jest możliwe w różnych sklepach - z czasem tylko w sklepach. Dane wynikające z takich porównań są nadal cenne - „czy kod produkujemy teraz bardziej poprawnie niż rok temu”.

Całkowitym skutkiem tych problemów jest to, że takie wskaźniki mogą być cenne tylko w szerszej kulturze - takie jak TQM, zapewnienie jakości (nie kontrola), ciągłe doskonalenie, kaizan itp. Konieczne jest zdefiniowanie elementów zarówno kultury i jak trzeba to zmienić. Jeśli masz ich definicję, wówczas takie metryki stają się niezbędnymi narzędziami pomagającymi poprawić jakość kodu, praktyki robocze, wydajność itp. Bez tego szerszego kontekstu metryki generują pracę w celu optymalizacji metryki; stanie się narzędziem beancounter do zwiększania wydajności i obniżania kosztów; i stanie się przeszkodą do grania przez personel programistyczny.

Możesz mieć obsesję na punkcie wskaźników lub obsesję na punkcie najlepszych ludzi, narzędzi, praktyk inżynierskich i kontroli jakości, na jakie Cię stać. Byłbym znacznie szczęśliwszy, mając kilku paranoicznych geniuszy QA, którzy przeczytali „Fooled by Randomness” i lubią automatyzować niż kilka ładnie sformatowanych raportów z liczbami.

Jest ten podstawowy problem z pomiarami.

Wykazano, że prawie wszystkie proponowane metryki, w prawdziwym świecie na prawdziwym kodzie, są silnie lub bardzo silnie skorelowane z surowym SLOC (wierszami kodu źródłowego).

Właśnie to zabiło miary Halsteada w latach siedemdziesiątych. (Przez przypadek, pewnego dnia, około 1978 r., Zasiadłem w rozmowie nowego doktora na temat wskaźników Halsteada, w której to zauważył).

Niedawno wykazano, że cykliczna złożoność McCabe'a jest bardzo silnie skorelowana z surowym SLOC, do tego stopnia, że ​​facet, który przeprowadził badanie, zastanawiał się głośno, czy metryka McCabe powiedziała nam coś pożytecznego.

Od dziesięcioleci wiemy, że duże programy mają większe problemy niż małe. Od dziesięcioleci wiemy, że większe podprogramy częściej zawierają błędy niż małe. Dlaczego potrzebujemy tajemniczych wskaźników, aby nam to powiedzieć, gdy patrzenie na cztery strony drukarki rozłożone na stole powinno być wystarczająco przekonujące?

Biorąc pod uwagę wszystkie inne odpowiedzi tutaj, czuję się trochę głupio z tym małym. Spójrz na Crap4j , który próbuje uszeregować metody w Javie według ich smrodu. (Projekt wygląda na opuszczony).

Wykorzystuje połączenie złożoności cyklicznej i zasięgu testu. Jak każda inna metryka, jest dostępna.