Przegląd kodu

Przegląd kodu (czasami określany jako przegląd równorzędny ) to czynność polegająca na zapewnianiu jakości oprogramowania , w ramach której jedna lub kilka osób sprawdza program, głównie przeglądając i czytając fragmenty jego kodu źródłowego , i robią to po wdrożeniu lub jako przerwa we wdrażaniu. Przynajmniej jedna z osób nie może być autorem kodu. Osoby dokonujące sprawdzenia, z wyłączeniem autora, nazywane są „recenzantami”.

Chociaż głównym celem jest często bezpośrednie wykrywanie problemów z jakością, przeglądy kodu są zwykle przeprowadzane w celu osiągnięcia kombinacji celów:

Lepsza jakość kodu – popraw jakość wewnętrznego kodu i jego łatwość konserwacji (czytelność, jednolitość, zrozumiałość itp.)
Znajdowanie defektów – poprawianie jakości pod kątem aspektów zewnętrznych, zwłaszcza poprawności, ale także znajdowanie problemów z wydajnością, luk w zabezpieczeniach, wstrzykiwanych złośliwych programów,…
Learning/Knowledge transfer – pomoc w przekazywaniu wiedzy o kodzie, podejściu do rozwiązania, oczekiwaniach co do jakości itp.; zarówno recenzentom, jak i autorowi
Zwiększ poczucie wzajemnej odpowiedzialności – zwiększ poczucie wspólnej własności kodu i solidarności
Znajdowanie lepszych rozwiązań – generuj pomysły na nowe i lepsze rozwiązania oraz pomysły, które wykraczają poza określony kod.
Zgodność z wytycznymi QA, normami ISO/IEC – przeglądy kodu są obowiązkowe w niektórych kontekstach, np. oprogramowanie ruchu lotniczego, oprogramowanie krytyczne dla bezpieczeństwa

Powyższa definicja przeglądu kodu oddziela go od sąsiednich, ale oddzielnych technik zapewniania jakości oprogramowania : w statycznej analizie kodu główne sprawdzenie jest wykonywane przez zautomatyzowany program, w samokontrolach tylko autor sprawdza kod, w testowaniu wykonania kodu jest integralną częścią, a programowanie par odbywa się w sposób ciągły podczas implementacji, a nie jako osobny krok.

Typy recenzji

Istnieje wiele odmian procesów przeglądu kodu, z których niektóre zostaną szczegółowo omówione poniżej. Dodatkowe typy recenzji są częścią standardu IEEE 1028

IEEE 1028-2008 wymienia następujące typy recenzji:

Przeglądy zarządzania
Przeglądy techniczne
Inspekcje
Przejścia
Audyty

Inspekcja (formalna)

Historycznie pierwszy proces przeglądu kodu, który został szczegółowo zbadany i opisany, został nazwany przez jego wynalazcę Michaela Fagana „Inspekcją” . Ta inspekcja Fagana jest formalnym procesem, który obejmuje staranne i szczegółowe wykonanie z wieloma uczestnikami i wieloma fazami. Formalne przeglądy kodu to tradycyjna metoda przeglądu, w ramach której programiści uczestniczą w serii spotkań i przeglądają kod linia po linii, zwykle korzystając z drukowanych kopii materiału. Inspekcje formalne są niezwykle dokładne i okazały się skuteczne w wykrywaniu defektów w sprawdzanym kodzie.

Regularny przegląd kodu oparty na zmianach (instrukcje)

W ostatnich latach ^{[ kiedy? ]} wiele zespołów w branży wprowadziło lżejszy typ przeglądu kodu. Jego główną cechą jest to, że zakres każdego przeglądu opiera się na zmianach w bazie kodu dokonanych w zgłoszeniu, historyjce użytkownika, zatwierdzeniu lub innej jednostce pracy. Ponadto istnieją zasady lub konwencje, które osadzają zadanie przeglądu w procesie programowania (np. „każdy bilet musi zostać przejrzany”), zwykle jako część żądania ściągnięcia, zamiast jawnego planowania każdego przeglądu. Taki proces przeglądu nazywany jest „regularnym przeglądem kodu opartym na zmianach”. Istnieje wiele odmian tego podstawowego procesu. Ankieta przeprowadzona wśród 240 zespołów programistycznych z 2017 roku wykazała, że 90% zespołów stosuje proces przeglądu oparty na zmianach (jeśli w ogóle korzystają z przeglądów), a 60% używa regularnego przeglądu kodu opartego na zmianach. Ponadto większość dużych korporacji programistycznych, takich jak Microsoft, Google i Facebook, stosuje proces przeglądu kodu oparty na zmianach.

Wydajność i skuteczność przeglądów

Bieżąca analiza Capers Jones ponad 12 000 projektów rozwoju oprogramowania wykazała, że wskaźnik wykrywania ukrytych defektów podczas formalnej inspekcji mieści się w przedziale 60-65%. Dla nieformalnej kontroli liczba ta jest mniejsza niż 50%. Wskaźnik wykrywania ukrytych defektów dla większości form testowania wynosi około 30%. Studium przypadku przeglądu kodu opublikowane w książce Best Kept Secrets of Peer Code Review wykazało, że lekkie recenzje mogą wykryć tyle samo błędów, co formalne recenzje, ale były szybsze i bardziej opłacalne, w przeciwieństwie do badania przeprowadzonego przez Capers Jones

Zbadano również rodzaje defektów wykrytych w przeglądach kodu. Badania empiryczne dostarczyły dowodów na to, że nawet 75% defektów związanych z przeglądaniem kodu wpływa na możliwości rozwijania/utrzymania oprogramowania, a nie na funkcjonalność, co sprawia, że przeglądy kodu są doskonałym narzędziem dla firm programistycznych o długim cyklu życia produktu lub systemu. Oznacza to również, że mniej niż 15% problemów omawianych w przeglądach kodu dotyczy błędów.

Wytyczne

Stwierdzono, że skuteczność przeglądu kodu zależy od szybkości przeglądu. Szybkość przeglądu kodu powinna wynosić od 200 do 400 linii kodu na godzinę. Sprawdzanie i przeglądanie więcej niż kilkuset wierszy kodu na godzinę w przypadku oprogramowania krytycznego (takiego jak oprogramowanie wbudowane krytyczne dla bezpieczeństwa ) może być zbyt szybkie, aby znaleźć błędy.

Narzędzia pomocnicze

do statycznej analizy kodu zmniejsza zadanie przeglądania dużych fragmentów kodu przez programistę poprzez systematyczne sprawdzanie kodu źródłowego pod kątem znanych luk i typów defektów. Badanie przeprowadzone w 2012 roku przez VDC Research wykazało, że 17,6% ankietowanych inżynierów oprogramowania wbudowanego korzysta obecnie z automatycznych narzędzi do wspierania wzajemnej weryfikacji kodu, a 23,7% spodziewa się ich użyć w ciągu 2 lat.

Zobacz też

Linki zewnętrzne

Pięć antywzorców recenzji kodu ( Java Magazine, Best of 2020 )