Jakie są przydatne wskaźniki dla kodu źródłowego? [Zamknięte]

Jakie są przydatne dane do przechwycenia dla kodu źródłowego?

W jaki sposób metryki, takie jak na przykład (kod wykonywalny?) Linie kodu lub cykliczność złożoności, mogą pomóc w zapewnieniu jakości lub w jaki sposób są ogólnie korzystne dla procesu tworzenia oprogramowania?

„Mierzenie produktywności oprogramowania według linii kodu jest jak mierzenie postępu w samolocie według jego wagi.” - Bill Gates

Zobacz posty Jeffa na ten temat:

Wizyta pokojówki Metrics

Inżynieria oprogramowania: Dead?

Jest też stary, ale dobry post od Joela, ściśle związany z parametrami oprogramowania i gorąco polecam jego przeczytanie: Metoda zarządzania Econ 101

Dla mnie kluczową kwestią jest to, cytując Jeffa: „Odpowiedzialne stosowanie wskaźników jest tak samo ważne, jak ich zbieranie”.

To, co myli mnie w pomiarach kodu, to to, że nie robi się więcej. Większość firm informuje o wydajności swoich pracowników, dostawców i istniejących systemów, ale wydaje się, że nikt nie chce raportować o kodzie. Zdecydowanie zgodzę się z odpowiedziami stwierdzającymi, że więcej wierszy kodu stanowi odpowiedzialność, ale ważniejsze jest to, co robi Twój kod.

Linie kodu: Jak już wspomniałem, jest to niezbędny pomiar i należy go traktować bardzo poważnie, ale na każdym poziomie. Funkcje, klasy, pliki i interfejsy mogą wskazywać kod do wszystkiego, co jest trudne w utrzymaniu i kosztowne w dłuższej perspektywie. Nieskończenie trudno jest porównać całkowitą liczbę wierszy kodu z tym, co robi system. Może to być coś, co robi wiele rzeczy, w takim przypadku będzie wiele wierszy kodu!

Złożoność: ten pomiar jest dobry do wykonania na podstawie kodu, nad którym nie pracowałeś, i może dać ci dobre wskazanie, gdzie leżą obszary problemowe. Jako użyteczną anegdotę zmierzyłem złożoność na jednej z moich własnych baz kodu, a obszarem o największej złożoności był ten, który spędzałem najwięcej czasu, kiedy musiałem go zmienić. Praca nad zmniejszeniem złożoności spowodowała znaczne skrócenie czasu konserwacji. Gdyby kierownictwo dysponowało tymi pomiarami, mogliby zaplanować iteracje refaktoryzacji lub przeprojektować określone obszary systemu.

Duplikacja kodu: o ile mi chodzi, to bardzo ważny pomiar. Duplikacja kodu jest bardzo złym znakiem i może wskazywać na głębokie problemy z niskim poziomem projektu systemu lub deweloperów, którzy wklejają kopie, powodując ogromne problemy w dłuższej perspektywie i systemy, których nie da się naprawić.

Wykresy zależności Znalezienie złych zależności i zależności cyklicznych jest ważnym pomiarem w kodzie. To prawie zawsze wskazuje na nieprawidłowy projekt wysokiego poziomu, który wymaga korekty. Czasami jedna zależność może zasysać wiele niepotrzebnych innych, ponieważ ktoś używa addNumber w bibliotece e-mail do obliczeń finansowych. Wszyscy są zszokowani zmianą biblioteki e-mail i załamaniem finansów. Jeśli wszystko zależy od jednej rzeczy, może również wskazywać na biblioteki, które są trudne do utrzymania i źle zaprojektowane.

Dobry pomiar zawsze powie ci, że każda cecha systemu ma mały ślad. Mniej zależności, mniej złożoności, mniej powielania. Wskazuje to na luźne połączenie i wysoką kohezję.

Czy ta „metryka kodu źródłowego” nigdy nie umrze?

Surowe wiersze kodu źródłowego (SLOC) to najstarsza, najłatwiejsza i najbardziej podstawowa metryka.

Halstead początkowo zaproponował całą masę wskaźników. Wiele osób dobrze się bawiło, pisząc programy pomiarowe, dopóki jakiś spoilsport nie zrobił oczywistych badań i wykazał, że każda pojedyncza metryka Halsteada była silnie bezpośrednio skorelowana z SLOC.

W tym momencie pomiary Halsteada zostały porzucone, ponieważ SLOC jest zawsze łatwiejszy do zmierzenia.

Miary kodu źródłowego dla zapewnienia jakości mają na celu dwa cele:

• pisanie kodu z mniejszą liczbą błędów w środku
• pisanie kodu dla łatwej konserwacji

Oba prowadzą do pisania kodu tak prosto, jak to możliwe. To znaczy:

• krótkie jednostki kodu (funkcje, metody)
• kilka elementów w każdej jednostce (argumenty, zmienne lokalne, instrukcje, ścieżki)
• i wiele innych kryteriów mniej lub bardziej złożonych (patrz Metryka oprogramowania w Wikipedii).

Według mojej najlepszej wiedzy, liczba znalezionych błędów jest bezpośrednio związana z liniami kodu (prawdopodobnie ubijaniem), językiem modulo, programistą i domeną.

Nie znam żadnej innej prostej i praktycznej metryki dobrze skorelowanej z błędami.

Jedną rzeczą, którą chciałbym zrobić, to uruchomić liczby dla różnych projektów, w których jestem - Test Pokrycia :: kLOC, a następnie omówić „postrzeganą jakość”, aby sprawdzić, czy istnieje korelacja.

Dane są przydatne tylko wtedy, gdy wiesz, co zrobić z otrzymanymi odpowiedziami. Zasadniczo metryka oprogramowania jest jak termometr. Fakt, że mierzysz coś w temperaturze 98,6 ° F, nic nie znaczy, dopóki nie dowiesz się, jaka jest normalna temperatura. Powyższa temperatura jest dobra dla temperatury ciała, ale naprawdę niekorzystna dla lodów.

Typowe wskaźniki, które mogą być przydatne, to:

• Błędy wykryte / tydzień
• Błędy rozwiązane / tydzień
• # Zdefiniowane wymagania / wydanie
• # Wymagania zaimplementowane / wydania

Pierwsze dwa trendy mierzą. Czy znajdziesz błędy szybciej, niż możesz je naprawić? Dwa możliwe wyniki: być może potrzebujemy więcej zasobów do naprawiania błędów, może musimy przestać wdrażać nowe funkcje, dopóki nie nadrobimy zaległości. Drugie dwa obrazują, jak blisko jesteś do zrobienia. Zwinne zespoły nazywają to „wypaleniem”.

Cyklomatyczna złożoność jest interesującą miarą. Podstawową koncepcją jest liczba unikalnych ścieżek wykonania w funkcji / metodzie. W trudnym środowisku z testami jednostkowymi odpowiada to liczbie testów potrzebnych do zweryfikowania każdej ścieżki wykonania. Niemniej jednak fakt, że masz metodę o cyklicznej złożoności 96, nie oznacza, że ​​koniecznie jest to błędny kod - lub że musisz napisać 96 testów, aby uzyskać wystarczającą pewność. Nierzadko w generowanym kodzie (za pomocą WPF lub generatorów parsera) można stworzyć coś tak złożonego. Może dostarczyć przybliżonego obrazu poziomu wysiłku potrzebnego do debugowania metody.

Dolna linia

Każdy wykonany pomiar musi mieć zdefiniowane następujące wartości lub jest bezużyteczny:

• Zrozumienie, czym jest „normalność”. Można to zmienić w trakcie realizacji projektu.
• Próg poza „normalnym”, w którym należy podjąć jakieś działanie.
• Plan postępowania z kodem, gdy próg zostanie przekroczony.

Stosowane przez Ciebie dane mogą się znacznie różnić w zależności od projektu. Możesz mieć kilka wskaźników, których używasz w różnych projektach, ale definicja „normalny” będzie inna. Na przykład, jeśli jeden projekt wykrył średnio 5 błędów / tydzień, a nowy projekt wykrywa 10 błędów / tydzień, niekoniecznie oznacza to, że coś jest nie tak. Być może zespół testujący jest tym razem bardziej skrupulatny. Również definicja „normalna” może ulec zmianie w trakcie trwania projektu.

Metryka jest tylko termometrem, więc to, co z nią zrobisz, zależy od Ciebie.

Kod źródłowy to zobowiązanie, a nie składnik aktywów. Mając to na uwadze, mierzenie linii kodu jest analogiczne do śledzenia dolarów wydanych na budowę domu. Trzeba to zrobić, jeśli chcesz pozostać w budżecie, ale niekoniecznie pomyślałbyś, że wydawanie 1000 USD dziennie jest lepsze niż wydawanie 50 USD dziennie; chcesz wiedzieć, ile domu zbudowano za te pieniądze. To samo dotyczy wierszy kodu w projekcie oprogramowania.

Krótko mówiąc, nie ma przydatnych wskaźników dla kodu źródłowego, ponieważ sam pomiar kodu źródłowego nie jest użyteczny.

Ponieważ kod źródłowy jest po prostu kombinacją sekwencji, selekcji i powtórzeń. Gdybym miał opisać najbardziej optymalne oprogramowanie, jakiego moglibyśmy się spodziewać, to byłoby to następujące. Oprogramowanie o prawie 100% pokryciu kodu testowego, wykorzystujące najmniejszą liczbę wierszy kodu niezbędnych do wykonania zadania, a jednocześnie wystarczająco elastyczne, aby wytrzymać zmiany.

Anegdota pokazująca, dlaczego liczby KLOC są bezużyteczne (a nawet szkodliwe) do oceny wydajności.

Wiele lat temu pracowałem nad dużym projektem (ponad 70 osób w naszej firmie, kolejne 30+ u naszego klienta), w którym liczniki KLOC były jedyną miarą wydajności zespołów i osób.

Za nasz wysiłek Y2K (mówi ci, jak dawno temu to było :)) zrobiliśmy duże czyszczenie części kodu, za którą odpowiedzialny był mój zespół. Skończyliśmy na wydaniu, pisząc około 30 000 wierszy kodu, niezły 3 miesiące pracy dla 5 osób. Skończyło się również na zeskrobaniu kolejnych 70 000 wierszy kodu, co jest bardzo dobrą pracą przez 3 miesiące pracy, szczególnie w połączeniu z nowym kodem.

Wynik końcowy za kwartał: -40 000 wierszy kodu. Podczas przeglądu wydajności po kwartale otrzymaliśmy oficjalną reprymendę od firmy za niespełnienie naszych wymagań dotyczących produktywności w wysokości 20 000 wierszy kodu na kwartał (w końcu narzędzia pokazały, że wyprodukowaliśmy -40 000 wierszy kodu), co spowodowałoby, że wszyscy zostalibyśmy wymienieni jako nieskuteczni i pominięci w promocjach, szkoleniach, podwyższeniu wynagrodzeń itp. itp., gdyby kierownik projektu i zespół ds. kontroli nie interweniowali i nie otrzymali nagany i zastąpiono ją pochwałą.

Kilka miesięcy później (takie rzeczy wymagają czasu) powiedziano nam, że firma dokonuje przeglądu ich standardów wydajności i zatrudniliśmy zespół ekspertów do stworzenia nowego systemu opartego na analizie punktów funkcyjnych.

Dziwi mnie, że nikt jeszcze nie wspomniał o oświadczeniu / decyzji dotyczącej testów jednostkowych (procent kodu wykonywanego przez testy jednostkowe).

Zasięg kodu jest przydatny, ponieważ wiesz, jaki procent aplikacji nie zawiedzie katastrofalnie; reszta jego użyteczności zależy od jakości testów jednostkowych.

Im mniejsze zobowiązania, tym lepiej. Chodzi o narzędzia SCM, a nie sam kod, ale jest to bardzo wymierna miara. Im mniejszy zatwierdzenie, tym łatwiej jest zobaczyć każdą zmianę jako jednostkę atomową; tym łatwiej jest cofnąć określone zmiany i wskazać, kiedy coś się zepsuło.

Dopóki żadne zatwierdzenie nie zakłóci kompilacji ...

Nie są to bardzo przydatne wskaźniki bezwzględne pod względem postępu, ale można je wykorzystać do ogólnego zorientowania się w stanie kodu.

Zwłaszcza cykliczność złożoności, która okazała się przydatna, jeśli chodzi o wizualizację, jak modułowa jest dana baza kodu. Ogólnie chcesz niskiej złożoności, ponieważ oznacza to, że liczba źródeł na moduł jest niska i istnieje wiele modułów.

Często pracuję nad gigantycznym pakietem C ++, a kiedy szukam problematycznego kodu, który warto zreformować, złożoność cyklomatyczną lub okropne FanIn / FanOut są zwykle całkiem niezłymi czerwonymi flagami. Naprawianie problemów zazwyczaj prowadzi do ulepszeń w całej bazie kodu.

Oczywiście liczby te mogą służyć jedynie za wskazówkę, na co warto spojrzeć. Uczynienie tego twardym progiem, po którym niepowodzenie kompilacji lub odmowa zatwierdzenia byłoby absurdalne.

W mojej pracy jest wiele sytuacji, w których używam wskaźników kodu:

Podczas pisania kodu

Największym i chyba najważniejszym zastosowaniem w mojej codziennej pracy jest Checkstyle , narzędzie dla programistów Java, które stale sprawdza miary (między innymi) mojego kodu w oparciu o zestaw zdefiniowanych przez nas reguł i zaznacza miejsca, w których mój kod nie przestrzegać tych zasad. Gdy rozwijam kod, mówi mi w czasie rzeczywistym, czy moje metody stają się zbyt długie, złożone lub połączone, co pozwala mi cofnąć się i pomyśleć o przekształceniu go w coś lepszego.

Programiści mają całkowitą swobodę w łamaniu wszystkich zasad, ponieważ nigdy nie będą obowiązywać we wszystkich sytuacjach. „Reguły” są po to, aby pobudzić myśl i powiedzieć „Hej, czy to najlepszy sposób, aby to zrobić?”

Podczas kontroli jakości / przeglądu kodu

Pierwszą rzeczą, którą zazwyczaj robię, kiedy przeprowadzam przegląd kodu, jest sprawdzenie pokrycia kodu sprawdzanego kodu w połączeniu z narzędziem pokrycia kodu, które podkreśla, które wiersze kodu zostały objęte. To daje mi ogólne wyobrażenie o dokładności kodu testowego. Nie obchodzi mnie, czy zasięg wynosi 20%, czy 100%, o ile ważny kod jest dobrze przetestowany. Tak więc procent objęty gwarancją jest nieco bez znaczenia, ale 0% na pewno wyróżnia się jak obolały kciuk jako coś, na co chcę uważnie przyjrzeć się.

Sprawdzam również, które wskaźniki uzgodnione przez zespół zostały „uszkodzone”, jeśli w ogóle, aby sprawdzić, czy zgadzam się z deweloperem, czy wszystko jest w porządku, czy też mogę zasugerować sposoby poprawy. Uzgodnienie tych wskaźników rozwoju przez nasz zespół do pisania nowego kodu znacznie przyczyniło się do ulepszenia naszego kodu. Piszemy o wiele mniej metod monolitycznych i jesteśmy teraz znacznie lepsi na zasadzie pojedynczej odpowiedzialności .

Trendy w udoskonalaniu starszego kodu Mamy dużo starszego kodu, który chcielibyśmy ulepszyć. Wskaźniki w dowolnym momencie są dość bezużyteczne, ale dla nas ważne jest to, że z czasem zasięg kodu rośnie, a złożoność i łączenie maleją. Dlatego nasze wskaźniki są podłączone do naszego serwera Continuous Integration, co pozwala nam patrzeć w czasie, aby upewnić się, że jesteśmy na dobrej drodze.

Zapoznanie się z nową bazą kodu O tym, kiedy tylko używam wierszy metryki kodu źródłowego, patrzę na bazę kodu, której nie znam. Pozwala mi to szybko oszacować przybliżony rozmiar projektu w porównaniu do innych, z którymi pracowałem. Korzystając z innych wskaźników, mogę również uzyskać przybliżone pojęcie o jakości projektu.

Kluczowe rzeczy to wykorzystanie wskaźników jako punktów wyjścia do tworzenia trendów, dyskusji lub dalszych działań, a nie religijne zarządzanie nimi do dokładnych liczb. Ale głęboko wierzę, że mogą pomóc ci poprawić kod, który właściwie używasz.

P: Jakie są przydatne dane do przechwycenia kodu źródłowego?

Dla biznesu:

Odp .: Liczba roboczogodzin

W przypadku osoby nadzorującej kodera:

Odp .: Nieważne. Zróbmy wszystko dzisiaj

Dla samooceny kodera:

Odp .: Liczba SLOC (wiersze kodu źródłowego)

Dla matki kodera:

Odp .: Jedz więcej tych miękkich francuskich bułek i pij herbatę

ciąg dalszy w komentarzach poniżej ...

Pamiętaj: cały kod można zmniejszyć o co najmniej 1 instrukcję. Cały kod zawiera co najmniej 1 błąd. Dlatego cały kod można sprowadzić do pojedynczej instrukcji, która nie działa. Mam nadzieję, że to pomaga!