Jak określić efektywność procesu przeglądu kodu?

14

Wprowadziliśmy proces sprawdzania kodu w naszej organizacji i wydaje się, że działa dobrze. Chciałbym jednak móc mierzyć efektywność procesu w czasie, tj. Czy nie znajdujemy błędów, ponieważ kod jest czysty, czy ludzie po prostu nie wychwytują błędów?

Obecnie nie mamy skutecznego, w pełni zautomatyzowanego procesu testowego. Stosujemy głównie testy ręczne, więc nie możemy polegać na defektach wykrytych na tym etapie, aby upewnić się, że proces sprawdzania kodu działa.

Czy ktoś wcześniej spotkał się z tym problemem lub ma jakieś przemyślenia na temat tego, co działa dobrze w mierzeniu recenzji kodu?

Johnv2020
źródło
7
Znalezienie błędów nie jest jedynym celem recenzji kodu. Są również przydatne do wzmacniania standardów kodowania, szkolenia, zapylania pomysłów i technologii itp.
Jason
Dzięki Jason i zrozumiałem, ale w tym przypadku staram się dowiedzieć, jak zapewnić, że proces osiągnie swój podstawowy cel, jakim jest zapobieganie
@ Johnv2020 Nie jest to jednak jego główny cel ... Całkowicie brakuje Ci punktu przeglądu kodu. Byłoby to jak wprowadzenie nowej, znakomitej funkcji bezpieczeństwa we flocie samolotów odrzutowych, a następnie próba oceny jej skuteczności na podstawie liczby wypadków. Istnieje zbyt wiele zmiennych i innych czynników, które należy wziąć pod uwagę, aby dokładnie twierdzić, że funkcja bezpieczeństwa poprawiła prawdopodobieństwo wystąpienia awarii.
wałek klonowy
@maple_shaft: Słaba analogia. Próba oceny wskaźników błędów jest bardziej jak próba zmierzenia liczby trumien używanych dla ofiar śmiertelnych po wypadkach.
S.Lott,
1
We wszystkich przeglądach kodu, w których uczestniczyłem, wiele błędów zostało już naprawionych w testach jednostkowych i wyższych. Oznacza to, że kod nie jest gotowy do przeglądu tylko dlatego, że się kompiluje.
Pete Wilson,

Odpowiedzi:

7

Istnieje wiele wskaźników, które można zebrać z recenzji kodu, niektóre nawet rozszerzają się przez cały cykl życia projektu.

Pierwszą miarą, którą poleciłbym gromadzenie, jest skuteczność usuwania defektów (DRE) . Dla każdej wady określasz, w której fazie została wprowadzona i w jakiej fazie została usunięta. Różne stosowane przez ciebie techniki wykrywania wad są oceniane jednocześnie, więc ma to zastosowanie w równym stopniu do recenzji wymagań, recenzji projektu, recenzji kodu, testów jednostkowych , i tak dalej. Byłbyś szczególnie zainteresowany liczbą defektów wykrytych w fazie kodu, ponieważ prawdopodobnie obejmowałyby to twoje testy jednostkowe, a także recenzje kodu. Jeśli wiele defektów od fazy kodu przechodzi do fazy testu integracji, a nawet pola, wiesz, że należy poddać ocenie praktyki postkodowania.

Istotne byłyby również różne wskaźniki spotkania. Obejmują one czas na przygotowanie, czas na spotkanie, przeczytanie wierszy kodu, defekty znalezione w recenzji i tak dalej. Na podstawie tych danych można poczynić pewne obserwacje. Przykładem może być sytuacja, gdy recenzenci spędzają dużo czasu na czytaniu kodu, przygotowując się do recenzji, ale znajdując bardzo mało problemów. W połączeniu z danymi DRE można wyciągnąć wniosek, że jeśli defekty są testowane podczas testów integracyjnych lub w terenie, zespół musi skoncentrować się na swoich technikach przeglądu, aby znaleźć problemy. Kolejną interesującą notatką byłyby linie kodu (lub inny pomiar wielkości) odczytane na spotkaniu w porównaniu do czasu spotkania. Badania wykazały, że szybkość typowego przeglądu kodu wynosi 150 linii kodu na godzinę.

W przypadku dowolnej z tych miar ważne jest, aby zrozumieć ich wpływ na proces. Analiza przyczyn źródłowych przy użyciu technik takich jak diagram dlaczego-ponieważ , Five Whys lub diagramy Ishikawy mogą być użyte do zidentyfikowania powodów, dla których recenzje kodu (lub dowolna inna technika poprawy jakości) są (nie) skuteczne.

Możesz być także zainteresowany tym artykułem o inspekcjach z The Ganssle Group oraz artykułem Capers Jones w Crosstalk o Defect Potentials i DRE .

Thomas Owens
źródło
2

Podczas gdy w dużej mierze prawdą jest, że przegląd kodu wychwyciłby problemy, które są raczej utajone, że testy mogą złapać lub nie. Jednak moim zdaniem możesz mieć naprawdę stabilny (praktycznie bezbłędny) kod, ale nadal napisany w taki sposób, że jest wyjątkowo nieczytelny lub nie do utrzymania. Może się zdarzyć, że przegląd kodu NIE znajdzie błędów, jeśli w kodzie nie ma żadnych prawdziwych problemów.

Powiedziawszy to, naprawdę zapytam, dlaczego miałby chcieć dokonać przeglądu kodu? Prostym powodem, dla którego ważne jest, aby poprawić kod, aby był bardziej czytelny, łatwy w utrzymaniu i rozwijalny. Wiele osób powinno być w stanie czytać czystszy kod i mieć z tego sens. W tym sensie najprostszym celem procesu przeglądu kodu jest stworzenie czystego kodu. Zatem miarą skuteczności jest stopień czystości kodu.

Jak chciałeś mieć mierzalną skuteczność - oto, co sugerowałbym:

  1. Metryka związana z ilością przeróbek - Ilość czasu, w którym przeróbka jest stosowana w tym samym module / obiekcie / elemencie pracy, jest miarą tego, jak kiepski jest ten kod pod względem łatwości konserwacji. Kiedy efektywna weryfikacja kodu jest stosowana, jak często jesteśmy w stanie zredukować żądanie ponownej pracy w tym samym module?

  2. Metryka związana z wielkością zmiany, jakiej dotyczy każde żądanie zmiany. Gdy za każdym razem pojawia się żądanie zmiany - nieprawidłowo sklasyfikowany kod zawsze będzie miał wpływ na większą liczbę modułów. Środek prawdopodobnie wskazywałby na to, że po przeglądzie kodu - czy było jakieś zmniejszenie takiego rozprzestrzeniania się zmian w przypadku podobnego żądania zmiany w przeszłości?

  3. Metryka związana ze średnią prędkością, z jaką można odpowiedzieć na żądanie zmiany. Gdy kod jest czystszy - szybciej i lepiej odpowiada na wymagane zmiany. Po wyczyszczeniu kodu w procesie sprawdzania, możemy przyspieszyć odpowiadanie na żądanie o podobnym rozmiarze.

Nie umieszczam dokładnych jednostek miary - prawdopodobnie dzięki temu podejściu możesz stworzyć dokładniejsze miary. W powyższych podejściach może być więcej formalizmu rozszerzenia.

Zasadniczo chodzi mi o to, że zamiast patrzeć na liczbę błędów, proces weryfikacji kodu identyfikuje; powinniśmy mierzyć skuteczność pod kątem tego, czy przegląd kodu był w stanie sprawić, że kod będzie bardziej przejrzysty, szczuplejszy i łatwiejszy w utrzymaniu; w związku z tym możemy ocenić tę skuteczność, jeśli zobaczymy, że podobne żądania zmian w przyszłości będą bardziej efektywne w odpowiedzi.

Dipan Mehta
źródło
1
Chociaż nie jest to „błąd”, brak czytelności, łatwości obsługi lub ewolucji jest wadą w kodzie i powinien być traktowany jako taki. Nie ma powodu, dla którego nie można ich wyśledzić w narzędziu do śledzenia defektów, wraz z faktycznymi błędami w funkcjonalności. W ten sposób otwierasz także możliwość śledzenia wielu innych wskaźników związanych z defektami w fazie kodowania.
Thomas Owens
1
Jako programista z pewnością lubię widzieć czysty kod. Jednak recenzje kodu są bardzo kosztowne. Więc jako menedżer finansujący projekt, czysty kod nie jest naprawdę istotnym powodem, aby dodać 5-10% kosztów i czasu do mojego budżetu na rozwój. Zwłaszcza, gdy (jako menedżer) moja premia / recenzja wiąże się z ukończeniem bieżącego projektu na czas / w budżecie. Twoja opinia, że ​​głównym powodem recenzji kodu jest uzyskanie czystego kodu, sprawiłaby, że każdy dobry menedżer powiedziałby, że zwrot z inwestycji nie jest tego wart. Możesz spierać się o długoterminowe zwroty, ale do tego czasu menedżer, który zapewnia terminowość / budżet, zostanie awansowany z dala od tego problemu
Dunk
...problem. Podczas gdy menedżer, który promował recenzje kodu, będzie miał udane projekty konserwacji, ale zostanie uznany za nieukończenie oryginalnego projektu na czas / w budżecie, tak jak kierownik, który tego nie zrobił. OTOH, jeśli przeglądy kodu pomogły znaleźć błędy, których nie przejrzał brak recenzji i które pozwoliły kierownikowi przeglądu kodu ukończyć swój projekt bardziej na czas / w budżecie, to jest inna historia. To jest historia, którą trzeba sprzedać. Co oznacza również, że czysty kod nie może być przyczyną recenzji kodu.
Dunk
@Dunk Koszt przeglądu kodu zależy od rodzaju przeglądu kodu. Formalna inspekcja z udziałem 3-5 czytelników, moderatora i obecność autora (5-7 osób w pokoju) jest droga. Sprawdzanie dokumentacji, które polega na tym, że inny programista przegląda kod przez 10-15 minut, jest także przeglądem kodu, ale o wiele mniej formalnym i znacznie tańszym. Nawet programowanie w parach można uznać za swoistą technikę „przeglądu kodu”. Odpowiednią technikę określają czynniki, w tym (między innymi) krytyczność kodu, pożądany wskaźnik defektów oraz ilość czasu / pieniędzy do zainwestowania.
Thomas Owens
@Dunk - Wydaje mi się, że argumentowałeś za wyciągnięciem decyzji „powinniśmy sprawdzić kod” z rąk kierownika projektu i oddaniem jej w ręce kierownika odpowiedzialnego za platformę programową w perspektywie długoterminowej. Ogólnie rzecz biorąc, IMO wydaje dodatkowe 5-10% na rozwój przyzwoitych recenzji kodu, co jest opłacalną inwestycją ze względu na długowieczność opracowywanego systemu. Ale prawdopodobnie nie pod względem budżetu i harmonogramu bieżącego projektu.
Dawood mówi, że przywraca Monikę