Czas przeznaczony na przeglądy kodu

Jeśli robisz recenzje kodu

• Ile czasu spędzasz na recenzjach kodu w porównaniu do implementacji?
• Ile zmian podlega przeglądowi kodu?
• myślisz, że to za dużo / powinno być więcej?

Czy są jakieś badania dotyczące skuteczności?

[edytuj] dziękuję wszystkim za odpowiedzi, ciężko wybrać „zwycięzcę” na takie pytanie, w innych odpowiedziach jest też wiele cennych informacji.

W mojej pracy mamy następującą procedurę recenzji kodu. Do tej pory działało dobrze dla nas i okazało się, że jest bardzo oszczędny czasowo, szczególnie pod względem roboczogodzin. Tak naprawdę nie mamy konkretnego czasu przeznaczonego na recenzje. Każde zatwierdzenie lub scalenie do pnia musi zostać sprawdzone, a recenzent zajmuje tyle czasu, ile potrzeba.

Edycja: Czas potrzebny oczywiście zależy od wielkości zmiany. Małe funkcje i poprawki błędów zajmują kilka minut. Duże nowe funkcje, refaktoryzacje lub zmiany, które wpływają na wiele części systemu, mogą zająć pół dnia na przejrzenie, a następnego dnia na rozwiązanie wszystkich pojawiających się problemów.

Aby ten system działał, bardzo ważne jest częste przydzielanie do pnia, aby zmiany miały rozsądny rozmiar. Nie chcesz mieć takiej sytuacji, gdy musisz przejrzeć czyjś kod.

Jeśli chodzi o badania, oprogramowanie Smart Bear wyśle za darmo małą książkę Best Kept Secrets of Peer Code Review . Zawiera wiele artykułów na temat różnych aspektów przeglądu kodu, w tym badań dotyczących czasu, jaki powinny one zająć i skuteczności.

W naszym projekcie każda znacząca zmiana w systemie jest sprawdzana przez lidera zespołu lub wspólnie z innym deweloperem, który będzie głównym „konsumentem” nowego modułu. Rozmawiamy na skype i albo używamy Rudela w Emacsie (wtyczka do wspólnej edycji, w zasadzie pozwala kilku użytkownikom na edycję tego samego pliku na żywo), albo TypeWith.me (Piratepad), albo jeden z nas udostępnia swój ekran w skype.

Trudno to określić ilościowo, ponieważ przyziemne zmiany, takie jak nowe wyświetlenia, strony itp., Nie są sprawdzane. Sprawdzamy nowe moduły, główne aktualizacje i refaktoryzacje. Jeśli chodzi o duże zmiany, przegląd kodu może potrwać od 10% do 30% czasu, ale warto.

Mogę powiedzieć, że programowanie parowe, gdy 2 programistów jednocześnie edytuje ten sam plik, a nie tylko siedzi przy tym samym komputerze, jest o wiele lepsze niż zwykła praktyka biurowa polegająca na siedzeniu za ramieniem.

Do prostych rzeczy, takich jak konwencje nazewnictwa i błędy zakresu, używamy własnych lub automatycznych narzędzi typu open source (jslint, pylint, pyflakes, pep8). I nie ograniczamy zatwierdzeń i wypychań: używamy Mercurial, który ma bardzo łatwe rozgałęzianie i scalanie (muszę powiedzieć, łatwiejsze niż w Git). Błędy nie są sprawą przeglądu kodu.

Organizujemy spotkania zespołowe, na których ogłaszane są zmiany i nowe rzeczy, ale tam nie wszyscy naprawdę zwracają uwagę. Prawdopodobnie powinniśmy zrobić trochę więcej recenzji kodu.

Nie ma na to dobrej lub złej odpowiedzi. Ale jak wielu wcześniej mi to sugerowało - jeśli przegląd kodu jest wykonywany przez zewnętrznego członka zespołu [wysoce zalecana metoda], może to stanowić około 30% do 35% nakładów programistycznych. Ale jeśli zrobi to wewnętrzny członek zespołu projektowego, który był częścią zespołu programistycznego [niezalecane], można to zrobić w około 20% czasu poświęconego na prace rozwojowe.

Uwaga: natknąłem się na ten wątek, szukając czegoś innego i pomyślałem, że mogę tu dodać trochę wartości. Przy okazji, wszystkie powyższe szacunki nakładów oparte są na moim doświadczeniu zawodowym jako menedżer ds. Zaangażowania w wielu projektach. Mam nadzieję, że to pomoże.

Każda organizacja i baza kodu jest inna, więc trudno jest uzyskać wartość dla całej branży.
Jeśli naprawdę mówisz poważnie, powinieneś zacząć zbierać dane. Tj. Wykonaj przegląd kodu, aż zostanie pomyślnie wykonany, w tym przeróbki. Zacznij gromadzić to w bazie danych (LOC, złożoność kodu, język programowania, czas itp.). Następnie zbierz także wskaźniki dotyczące wskaźnika defektów podczas testowania. Tak długo, jak możesz zmniejszyć ten kod, przegląd powinien zapłacić sam. Jeśli wada wraca z testowania, zbierz dane dotyczące tego, ile czasu poświęcono na naprawę wad. Buduj te dane w swojej organizacji, twórz linie bazowe i możesz je dość dokładnie przewidzieć. Poszukiwane hasła to: Koszt jakości i Koszt niskiej jakości.

Jedynym zastrzeżeniem jest to, że może to stać się biurokratyczne i zależy od kultury organizacyjnej.