Przegląd kodu (angielskiego przeglądu kodu ) to systematyczne badanie kodu źródłowego oprogramowania.
Można to porównać do procesu zachodzącego w komitecie weryfikacyjnym , którego celem jest znalezienie błędów lub potencjalnych słabych punktów lub poprawienie błędów projektowych w celu poprawy jakości, łatwości konserwacji i bezpieczeństwa oprogramowania.
Przegląd kodu może opierać się na weryfikacji (ręcznej lub automatycznej) zgodności z zestawem reguł programowania.
Jeśli przegląd kodu od dawna jest uznawany za skuteczny sposób na poprawę jakości oprogramowania, organizacje, które wdrożyły systematyczne podejście, od dawna stanowią mniejszość. Coraz częściej staje się pełnym krokiem w każdym procesie tworzenia oprogramowania, zwłaszcza w metodach zwinnych, takich jak programowanie ekstremalne .
Firma Hewlett-Packard szacuje zwrot z inwestycji przeglądu kodu na 10 do 1.
Przegląd jest około 2 do 4 razy szybszy niż test i oferuje lepszy współczynnik wykrywania defektów: testy jednostkowe 25%, testy integracji 45%, przegląd projektu 55%, przegląd kodu 60%.
Ale recenzja nie wykrywa tych samych błędów, co test.
Przegląd kodu może przybierać różne formy, mniej lub bardziej formalne. Najbardziej odpowiedni model należy wybrać w oparciu o tolerancję ryzyka kontrolowanego kodu.
Michael Fagan, dyrektor IBM, sformalizował w 1976 roku metodę inspekcji kodu, która polega na zwołaniu kilku spotkań audytowych. Raczej ciężki, wymaga średnio dziewięciu roboczogodzin na 200 linii kodu, trudno go usystematyzować dla całego kodu.
Tom Gilb i Dorothy Graham opracowali również inną dość popularną metodę inspekcji.
System zarządzania wersjami można skonfigurować tak, aby wysyłał e-mail opisujący każdą modyfikację wprowadzoną w drzewie źródłowym. Pozostali programiści w zespole mają wtedy możliwość przejrzenia tych zmian.
Ta metoda stwarza problemy z zapewnieniem jakości : skąd wiedzieć, czy modyfikacja została poddana przeglądowi, czy uwzględniono krytykę ...
Przegląd przez ramię jest metodą nieformalną: autor kodu kieruje recenzją, przedstawiając recenzentowi zmiany, które wprowadził w kodzie źródłowym.
Ma tę zaletę, że jest prosty i szybki do wykonania. Jedną z jego wad jest to, że ponieważ autor jest pilotem recenzji, może brakować efektu ubocznego, którego nie zauważył w momencie pisania.
Porównywalna skuteczność programowania w parach z innymi metodami przeglądu kodu pozostaje nieco kontrowersyjną kwestią. Jest na przykład możliwe, że para nie ma wystarczającej odległości na kodzie.
Dostępne jest oprogramowanie ułatwiające przeglądanie kodu:
Niektóre bezpłatne oprogramowanie:
Analiza statyczna programu jest wykorzystanie narzędzi takich jak szarpie i jego następców w celu sprawdzenia zgodności z zestawem programowania zasady . Analiza statyczna umożliwia zautomatyzowanie (usystematyzowanie) niektórych kontroli (złożoność kodu, zgodność z regułami kodowania itp.), Ale nie pozwala na weryfikację niektórych bardziej abstrakcyjnych punktów (możliwość ponownego użycia, wydajność, zgodność ze specyfikacjami itp.) wymagają ręcznej korekty.
Analiza statyczna i wzajemna weryfikacja uzupełniają się zatem, umożliwiając rozszerzenie przeglądu kodu pod względem jakościowym i ilościowym. Narzędzie do analizy statycznej umożliwia w szczególności rozładowanie kontroli szczegółów i promuje bardziej globalną wizję systemu badanego podczas przeglądu kodu.
Checklist jest to dokument, który podsumowuje punkty, które należy sprawdzić w pierwszej kolejności podczas przeglądu kodu.
Lista kontrolna nie powinna zawierać więcej niż dziesięciu pozycji, czyli limitu tego, co normalny człowiek może zapamiętać. Dlatego konieczne jest:
Pozycje powinny dotyczyć tylko rzeczy, o których często się zapomina: na przykład „sprawdzenie, czy metoda właściwie uwalnia zasoby dla wszystkich przypadków powrotu błędu”. Aby to zrobić, możemy przeanalizować ostatnie 100 lub 200 poprawek błędów, aby znaleźć najczęstsze przyczyny błędów i przekształcić je w pozycje listy kontrolnej.
Interesujące będzie wtedy sklasyfikowanie nowych błędów według pozycji listy kontrolnej (nie zapominając o kategorii „żaden z tych elementów”). Kiedy pozycja na liście kontrolnej prawie nie będzie zawierała więcej błędów (ponieważ pojawiła się strategia uniknięcia tego problemu), nadszedł czas, aby zastąpić tę pozycję najczęstszą przyczyną błędów w kategorii „żaden z powyższych. Te przedmiotów ".
Samodzielne czytanie lub osobisty przegląd kodu polega na używaniu przez programistę metod przeglądu kodu (w szczególności listy kontrolnej) w produkcji oprogramowania w celu wykrywania i korygowania błędów.
Badanie przeprowadzone w Cisco wykazało, że przygotowane przez autora recenzje (adnotacje dotyczące modyfikacji dokonanych w kodzie źródłowym) zwróciły znacznie mniej błędów. Postawiono dwie hipotezy:
Niniejsze badanie wskazuje na faworyzowanie optymistycznej hipotezy.
Ciągła integracja może usystematyzować krok do analizy statycznej i / lub wzajemnej weryfikacji dla każdego nowego kodu osadzonego.
Zespół powinien wypracować kulturę udostępniania kodu źródłowego, zachęcając do dyskusji o kodzie. Ludzie niechętnie poświęcają czas na zrozumienie, jak działa złożony kod, więc w tym przypadku informacje zwrotne będą bardzo ogólne.
Pracownikowi trudno jest powiedzieć swojemu szefowi, że jeden z jego kolegów wykonał złą robotę. Kierownictwo musi zatem stworzyć klimat sprzyjający wykrywaniu błędów: błędy są normalnym procesem, a nie indywidualną awarią. Ważne jest, aby nie czuć się winnym, ale skupić się na przykład na pracy zespołowej: liczy się ostateczna jakość oprogramowania.
Deweloperzy muszą nauczyć się kontrolować swoje ego, odróżniać krytykę kodu od osobistej krytyki. Trzeba wziąć pod uwagę osoby, które nie chcą pokazywać swojej pracy.
Kierownictwo musi być również przekonane o wartości przeznaczania zasobów na korektę.
Metryki służą do pomiaru skuteczności recenzji.
Możliwe dane:
Dzięki temu można obliczyć na przykład gęstość defektów na wiersz kodu, średnią szybkość kontroli wiersza kodu lub czas wykrycia defektu.
Pomiary na dużą skalę w Cisco wykazały, że: