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

33

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?

cschol
źródło
37
Jedynym prawidłowym miernikiem jest WTF / s. :)
zakończenie
2
@terminus osnews.com/story/19266/WTFs_m :-)
thbusch

Odpowiedzi:

30

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

chrisaycock
źródło
3
Nie aktualizuj braków odpowiedzi.
Eric Wilson,
3
Chociaż jest to zabawna anegdota, odpowiedź ta niewiele pomaga w udzieleniu odpowiedzi na to pytanie.
Chris Knight
7
@Chris Ta odpowiedź uzyskała wiele głosów (lub „aktualizacji”, jak chce to nazwać FarmBoy), ponieważ wielu programistów uważa, że ​​metryki oprogramowania są bezużyteczne. Jeśli nie zgadzasz się lub uważasz, że masz lepszą odpowiedź na pytanie, opublikuj własną odpowiedź. Komentowanie, jak to zrobiłeś, nie jest produktywne; sam nic nie wniósłeś.
chrisaycock
7
Moja opinia i komentarz mają na celu zniechęcenie do odpowiedzi, które nie są głębokie i nie odnoszą się bezpośrednio do pytania PO. To może być znacznie lepsza odpowiedź, jeśli bardziej szczegółowo omówisz, dlaczego uważasz, że metryki oprogramowania są bezużyteczne w odniesieniu do rozwoju oprogramowania i zapewniania jakości i koncentrujesz się na czymś więcej niż tylko LOC.
Chris Knight
Dane oprogramowania są w rzeczywistości bardzo przydatne, jeśli używasz ich prawidłowo. Oznacza to, że im więcej LoC -> im więcej błędów -> tym gorsza jakość. Nigdy nie widziałem, aby zawiodła jako miara jakości. A samolot jest zdecydowanie lepszy, jeśli wykonuje tę samą podróż z tą samą prędkością, ale wymaga znacznie mniejszej masy. Oczywiście Bill Gates nie wiedział zbyt wiele o samolotach, kiedy to powiedział, ani nie wiedział wystarczająco dużo o oprogramowaniu.
Pablo Ariel,
12

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”.

Machado
źródło
+1 za zacytowanie tego jednowierszowego Jeffa. Czysta, zahartowana w bitwie mądrość właśnie tam.
luis.espinal
11

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ę.

Tjaart
źródło
8

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.

John R. Strohm
źródło
1
Jakieś linki do badania?
Jon Hopkins
Google jest Twoim PRZYJACIELEM, ale oto jeden, na początek. ecs.csun.edu/~rlingard/comp589/HoffmanArticle.pdf
John R. Strohm
6
Ciekawe badanie, chociaż w badaniu uwzględniono jedynie programy zawierające od 50 do 100 wierszy kodu. Przy tak małym, dobrze zdefiniowanym problemie do rozwiązania, efekt końcowy nie wydaje się tak zaskakujący.
Chris Knight
Powiedziałbym, że w prawdziwym świecie wszystkie te badania zamieniają się w błoto.
Warren P
To prawda. Im więcej wierszy kodu, tym lepsza jakość.
Pablo Ariel,
8

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).
mouviciel
źródło
7

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.

Paul Nathan
źródło
1
Więc im więcej kodu, tym więcej błędów w nim jest?
3
@Thor: Tak, tak. szok, co?
Paul Nathan,
O ile pamiętam, typowe liczby branżowe to około 2-3 błędy na 1000 linii kodu dla przeciętnych projektów, zbliżając się do około 0,5 błędu na 1000 linii kodu dla oprogramowania do kontroli elektrowni jądrowych lub projektów NASA, w których wkładają ogromną ilość wysiłku , kontrola, testowanie, przegląd itp., ponieważ awarie mogą mieć bardzo poważne konsekwencje. Czy ktoś ma jakieś odniesienia do liczb, które to potwierdzają?
hlovdal,
2
@hlovdal: 2-3 błędy na KSLOC to już bardzo niska liczba. Najniższe dane, które znam z dziedziny lotnictwa i bezpieczeństwa, są rzędu 0,1 błędów na KSLOC. Typowe liczby wydają się wynosić od 20 do 50 błędów na KSLOC. W celach informacyjnych artykuł Google dla Andy'ego Germana zatytułowany „Analiza kodu statycznego oprogramowania - wyciągnięte wnioski”.
Harmonogram
1
Kwestionowałbym te liczby - to całkowicie zależy od języka, kompilatora i środowiska wykonywalnego. Pisanie w kodzie JavaScript może zająć lata , ale literówka w skompilowanym języku można znaleźć przy pierwszym kompilacji.
JBRWilkinson
7

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.

Berin Loritsch
źródło
Innym związanym z tym błędem, który może być przydatny w niektórych przypadkach, są błędy w liniach kodu. Ogólnie rzecz biorąc, dojrzałe bazy kodu powinny mieć dość małą liczbę błędów w liniach kodu, w przeciwieństwie do aplikacji, które są wciąż w fazie rozwoju.
rjzii
@Rob Z, z dowolną metryką, ludzie zrobią tyle, aby zoptymalizować tę metrykę. W przypadku błędów w wierszu kodu programista może wprowadzić nieużywaną zmienną, którą zwiększają, aby zwiększyć liczbę wolnych od błędów LOC (ponieważ liczniki SLOC mogą wykryć wiele średników). Oczywiście sztucznie zwiększa to ilość kodu, przez który można się przedzierać.
Berin Loritsch
6

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.

Larry Coleman
źródło
4

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.

Xenohacker
źródło
2
100% pokrycia wynosi tylko 100%, jeśli obejmuje wszystkie ścieżki, a nie tylko wszystkie linie. W każdym realistycznym oprogramowaniu pokrycie 100% ścieżki jest złym celem, ponieważ osiągnięcie tego będzie bardzo drogie, a mimo to powie ci tylko, że Twój kod zachowuje się zgodnie z projektem, a nie sam projekt. Możesz mieć luki w zabezpieczeniach i mieć 100% zasięgu ścieżki.
Joeri Sebrechts,
+1 Więcej kodu źródłowego niekoniecznie jest lepsze.
Larry Coleman
Tylko bardzo proste aplikacje są objęte 100% pokryciem testowym (co powoduje, że zasięg jest redundantny). Osiągnięcie 100% pokrycia testowego złożonego oprogramowania jest drogie obliczeniowo (jeśli nie niemożliwe). Znamy ten fakt na solidnych podstawach już od około 6 dekad. Po drugie, testowanie mówi tylko, że nie znalazłeś błędu - nie gwarantuje, że nie ma błędów nie związanych z jakością strukturalną, rozmiarem czy złożonością (coś znanego również od dłuższego czasu.) Nie znając tych faktów podczas pracy w oprogramowaniu przypomina fizyka, który tak naprawdę nie zna praw termodynamiki.
luis.espinal
@ luis.espinal Oprogramowanie tak duże, że jest zbyt drogie obliczeniowo, by je przetestować, jest niezwykle źle napisanym oprogramowaniem. To prawie nie ma pojęcia, jak zrobić działające oprogramowanie.
Pablo Ariel,
@PabloAriel - „Oprogramowanie tak duże, że jest zbyt drogie obliczeniowo, by je przetestować” << To nie to, co powiedziałem. Przeczytaj komentarz (może dwa lub trzy razy), aby upewnić się, że faktycznie czytasz to, co myślisz.
luis.espinal
4

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.

jwenting
źródło
Dlaczego po prostu nie pokazałeś różnic ?!
reinierpost
Myślę, że tak się stało. Ale jeśli system jest tak sztywny, że nawet nie dzwoni na alarm, gdy pojawia się tak rażąco fałszywy punkt danych, nie przyniesie wiele dobrego.
jwenting
2
Twoja odpowiedź nie pokazuje, że KLOC są bezużyteczne, pokazuje, jak ich nie używać.
Neil N,
2
pokazuje, że poleganie na nich jako mierniku produktywności jest krótkowzroczne, polegając na nich, ponieważ jedynym miernikiem jest idiota. W innych projektach wykorzystujących KLOC jako miarę produktywności, a nawet jakości, z łatwością zwiększyliśmy liczby, tworząc standardy kodowania, które powodowały mnóstwo linii (praktyki stężeń w C ++, dodatkowe puste linie z krótkim komentarzem wszędzie, dzieląc warunki w instrukcji if na 3 linie itp.).
jwenting
1
Używanie SLOC jako miernika produktywności jest po prostu głupie i prawdopodobnie nigdy nie da dobrych wyników. Używanie SLOC jako miernika jakości wskazującego na łatwość konserwacji i liczbę wad jest bardziej rozsądne, przy wszystkich zastrzeżeniach już omówionych w tym pytaniu.
redcalx,
2

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.

StuperUser
źródło
pokrycie kodu jest również fałszywą miarą (choć może się przydać). Zachęca do pisania bzdurnych testów, aby uzyskać większy zasięg. I oczywiście są rzeczy, które nigdy nie zostaną omówione, a ludzie zaczną unikać pisania tych rzeczy. np. widziałem narzędzia pokrycia kodu, które oznaczyły JavaDoc jako kod i oczywiście nie byłyby objęte. inne narzędzie oznaczało wszystkie puste linie jako nieobjęte testami. Zgodziłbyś się, że usunięcie komentarzy i białych znaków w kodzie jest gorsze niż pominięcie testów jednostkowych dla niektórych seterów, mam nadzieję?
jwenting
Oczywiście, złe testy jednostkowe bolą bardziej niż pomagają na wiele sposobów. Na przykład możesz uzyskać 100% pokrycia kodu dla zestawu testów, które nie zawierały pojedynczego potwierdzenia.
StuperUser
1

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 ...

Assaf Lavie
źródło
1

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.

użytkownik1249
źródło
1

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.

Benjamin Bannier
źródło
1

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.

Chris Knight
źródło
0

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 ...

Geniusz
źródło
-1

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!

Will Kunkel
źródło
i mniej skutków ubocznych.
Lub może to: en.wikipedia.org/wiki/Sorites_paradox
StuperUser