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

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?

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 .

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.