Inspekcje kodu: Po prostu je rób

Oryginalny post: Code Reviews: Just Do It

Autor: Jeff Atwood

W artykule The Soft Side of Peer Reviews Karl Wiegers zaczął od mocnego oświadczenia:

Wzajemne przeglądy -- czynność, podczas której osoby inne niż autor kawałka kodu przyglądają się mu pod kątem błędów oraz możliwości poprawy -- są jednym z bardziej potężnych, dostępnych narzędzi do podtrzymywania jakości kodu. Wzajemne przeglądy zawierają w sobie inspekcje, kontrole ogólne, wzajemne symulowanie logiki i inne podobne czynności. Po tym jak doświadczałem korzyści związanych ze wzajemnymi przeglądami przez niemal 15 lat, nigdy nie chciałbym pracować w zespole, który nie wykonuje tych czynności.

Po tym jak brałem udział w inspekcjach kodu przez jakiś czas tutaj w Vertigo, wierzę, iż wzajemne przeglądy są najlepszą rzeczą, która może ulepszyć Twój kod. Jeśli nie uskuteczniasz inspekcji kodu teraz, wraz z innym programistą, to umyka Ci wiele błędów w Twoim kodzie oraz okradasz siebie z pewnych kluczowych szans na profesjonalne programowanie. Jeśli o mnie chodzi, mój kod nie jest skończony, dopóki nie zostanie on przejrzany przez innego programistę.

Ale nie ufajcie moim słowom. McConnell dostarcza wiele dowodów na skuteczność inspekcji kodu w książce Code Complete:

.. samo testowanie oprogramowania ma ograniczoną efektywność -- średni wskaźnik znajdowania defektów, to tylko 25% dla testów jednostkowych, 35% dla testów funkcjonalnych i 45% dla testów integracyjnych. Dla porównania średnia efektywność inspekcji projektu i kodu, to 55% i 60%. Analiza przypadków dla inspekcji jest imponująca:

  • W firmie zajmującej się utrzymywaniem oprogramowania, 55% jednolinijkowych zmian było błędnych przed tym, jak wprowadzono inspekcje kodu. Po wprowadzeniu inspekcji jedynie 2% zmian posiadało błędy. Kiedy wszystkie zmiany zostały wzięte pod uwagę, 95% było poprawnych po pierwszym razie, kiedy inspekcje zostały wprowadzone. Przed wprowadzeniem inspekcji, poniżej 20% było poprawnych za pierwszym razem.
  • W grupie 11 aplikacji, które zostały napisane przez tę samą grupę ludzi, pierwsze 5 zostało stworzonych bez inspekcji. Przy pozostałych 6 były obecne inspekcje kodu. Po tym jak wszystkie aplikacje zostały wdrożone na produkcję, pierwsze 5 miało średnio 4.5 błędu na 100 linii kodu. Te 6, które poddawane były inspekcjom, miały średnią 0.82 błędu na 100 linii. Inspekcje ucięły ilość błędów o 80%.
  • Aetna Insurance Company dzięki inspekcjom znalazła 82% błędów w swoim programie i była w stanie zmniejszyć zasoby potrzebne do tworzenia aplikacji o 20%.
  • Projekt Orbit IBMa, który ma 500000 linii, używał 11 poziomów inspekcji. Został wcześnie dostarczony i miał tylko około 1% błędów, które normalnie by posiadał.
  • Badania przeprowadzone w AT&T wskazują, że ponad 200 ludzi odnotowało 14% wzrost produktywności i 90% spadek liczby defektów po wprowadzeniu inspekcji przez organizację.
  • Jet Propulsion Laboratories szacuje, iż co inspekcję oszczędza $25000 poprzez znalezienie i naprawienie defektów we wczesnej fazie.

Jedyną przeszkodą w robieniu inspekcji kodu jest znalezienie szanowanego programisty, który by to robił oraz czasu na jej wykonanie. Myślę, iż jeśli już spróbujesz, to szybko się przekonasz, że każda minuta spędzona na inspekcji kodu zwróci się dziesięciokrotnie.

Jeśli inspekcje kodu są nowością w Twojej firmie, gorąco polecam książkę Karla, Peer Reviews in Software: A Practical Guide. Jak również przykładowe rozdziały, które Karl umieścił na swojej stronie, mogą być dobrym podkładem.

Data publikacji oryginału: 21 stycznia, 2006

4 komentarze:

Anonimowy pisze...

Zdecydowanie bardziej popularne jest pojęcie "przegląd kodu" niż "inspekcja kodu".

Konradzik pisze...

Nie miałem przyjemności żeby ktoś starszy doświadczeniem ode mnie przeglądał mój kod, a szkoda. Ten artykuł utwierdza mnie tylko w przekonaniu, że to ważna czynność - powyższe statystyki są niewątpliwie przekonujące.

Krzysztof Kliś pisze...

Niestety problem w tym, że dość spora liczba programistów traktuje "code review" jak obrazę majestatu i powątpiewanie w ich umiejętności, a szkoda.

Krzysiek Wesołowski pisze...

Jeżeli weźmiemy 2 programistów na podobnym poziomie, to obaj czytając kod drugiego wyrażą parę "WTF!?". Więc niekoniecznie trzeba szukać "guru" który będzie robił przeglądy, bardzo często trzeba tylko świeżego spojrzenia zwyklego współpracownika.

Prześlij komentarz

Related Posts with Thumbnails