Udana strategia przeglądu kodu z SVN i ReviewBoard?

Question

Udało mi się wprowadzić ReviewBoard do procesu kodowania w mojej firmie, a "wprowadzić" oznacza, że ​​go zainstalowałem i zaprezentowałem. Mamy również ogólną zgodę, że bardzo potrzebujemy recenzji kodu, ale nie jesteśmy do końca pewni, jak chcielibyśmy to zrobić.

Naszą główną kontrolą wersji jest SVN, więc ograniczyliśmy rozgałęzianie i łączenie. Niektóre strategie, o których myślałem:

1. Wstępna ocena z pnia. Zalety obejmują posiadanie pojedynczej łatki, bez niepotwierdzonego kodu w repozytorium. Contras muszą utrzymywać kasę w czystości lub robić rozgałęzienia dla biednych z kilkoma kasami.
2. Ocena po zatwierdzeniu z bagażnika. Działa dobrze z Komisją Recenzującą, jednak nie powstrzymuje ludzi przed popełnianiem brudnego kodu, a także pozwala im zignorować prośby o sprawdzenie.
3. Ocena po zatwierdzeniu z oddziału funkcji. Zalety są oczywiste, ponieważ funkcja może być obsługiwana niezależnie, jednak istnieje duży problem z tworzeniem oddziałów opartych na serwerze, a także znacznie większy problem z synchronizacją różnych oddziałów. Zobacz także pozycję 2.

Chciałbym uczynić to tak bezbolesnym, jak to możliwe, więc istnieje kilka możliwych zautomatyzowanych dodatków do przepływu pracy, takich jak posiadanie przez robota kodu, który zdobył co najmniej X "Wyślij to!" głosów i powoływanie komisji rewizyjnej "podążaj" za oddziałem funkcji z zatwierdzeniem zatwierdzenia. Nadal nie jestem pewien, który workflow przeglądu kodu może być najlepszy dla naszego zespołu około 8 programistów. Nie będziemy w stanie zmienić systemów kontroli rewizji, tzn. Git-svn i SVK nie wchodzą w grę (mimo że ten drugi jest już martwy).

Czy możesz polecić coś ze swojego doświadczenia?

Answer 1

bazowej systemu na zaufaniu i odpowiedzialności i utrzymać ją waga:

1. zdrowym rozsądkiem: „Można sprawdzić cokolwiek w dowolnym momencie. Poproś o sprawdzenie kodu, gdy będziesz go potrzebować. Dodaj komentarze do recenzji, jeśli zostały sprawdzone, by ułatwić szybkie recenzje.
2. Zespół kontrolny jest odpowiedzialny za monitorowanie zmian za pomocą haków zatwierdzenia. Jeśli zobaczą coś, czego nie lubią, weź to z deweloperem. Różni członkowie mogą przeglądać różne sekcje.
3. Jeśli programista nadal sprawdza bzdury bez pytania o opinię, należy je zwolnić.
4. Jeśli istnieją sekcje systemu, które są niezwykle skomplikowane/centralne/łatwe do zepsucia - zablokuj je i wymagaj zgody na odprawę.
5. Każdy może monitorować zameldowania. Recenzowanie nie dotyczy wyłącznie forum recenzentów.

Widziałem tę pracę z 2 programistów i 100.

Answer 2

kombi swojego # 2 i # 3 (chyba ze skróconych opinii tułowia jeśli gałąź funkcji został już oceniony) mogą działać dobrze . Uważam, że opinie przed dokonaniem zatwierdzenia są trochę dławiące - lepiej mieć entuzjazm (podtrzymywany przez ciebie?) Do przeglądu zainfekować cały zespół.

Polecam przeczytanie bezpłatnej książki SmartBear, Best Kept Secrets of Peer Code Review, która jest dość bezstronna, szczególnie esp. biorąc pod uwagę, że jego autor sprzedaje pakiet do przeglądu kodu handlowego. (Nie pracuję dla nich, ani nie używam ich produktów, FWIW.)

Ta książka pomoże Ci przemyśleć zarówno możliwe przepływy pracy dla twojego środowiska, jak i wprowadzić obieg pracy, wyjaśniając zespołowi, dlaczego możesz chcieć dążyć do recenzji x-set LoC lub mniejszej, lub mieć trochę oprowadzania z przewodnikiem przed recenzjami itp.

Answer 3

Jesteśmy na podobnej pozycji.

Czy masz skonfigurowany svn do wysyłania wiadomości e-mail do wszystkich programistów przy każdym zatwierdzeniu? To dobry pierwszy krok w utrzymaniu uczciwości wszystkich. Wysyłamy wiadomość e-mail z komunikatem dziennika, pierwszym 200 wierszy pliku svn diff i linkiem do całego pliku diff (który zasadniczo służy wyłącznie do wyświetlania plików svn diff).

Jeżeli deweloper sądzi zmiana wymaga przeglądu po fakcie, używamy ReviewBoard do przeprowadzenia przeglądu.

Z drugiej strony, programiści mogą również poprosić o sprawdzenie przed zameldowaniem. Czy one opracowane zmiany na oddział fabularnego lub w piaskownicy bagażnika, nie ma znaczenia. Zastanawialiśmy się nad dostosowaniem skryptów do przesłania żądania przeglądu z wiersza poleceń, ale proces jest tak prosty, że jeszcze tego nie zrobiliśmy, przynajmniej jeszcze.

Moje ogólne zalecenie jest wprowadzenie systemu ręcznego i automatyzacji, i ewentualnie wymusić ją wstępnie popełniają skryptów, gdy jesteś zadowolony z tego procesu. Z małym zespołem szczególnie lepiej jest błądzić po stronie egzekwowania presji rówieśników, ponieważ chcesz zminimalizować liczbę małych procesów zabijania produktywności.

Answer 4

Niedawno wprowadziliśmy ReviewBoard do naszego procesu. Przed dodaniem ReviewBoard mieliśmy następujące rzeczy:

1. SVN z wiadomością e-mail automatycznie wysyłaną do wszystkich programistów przy każdym zameldowaniu.
2. ViewCV zintegrowany z, aby umożliwić przeglądanie różnic po obejrzeniu w przeglądarce.
3. Skrypt błędu SCM zintegrowany z SVN, więc programiści muszą dołączyć duży identyfikator do swoich masek.
4. Buildbot zintegrowany z SVN, aby automatycznie uruchamiać testy po każdym odprawie.

Ponieważ już wcześniej post-commit był dość dobrze sprawdzony z innymi rzeczami, używamy aplikacji ReviewBoard jako narzędzia do wstępnego zatwierdzania i dopiero po tym, jak wprowadzimy "uzupełnianie funkcji" dla danej wersji.

Answer 5

W większych przedsięwzięciach gałęzie obiektów są nieuniknione. W przypadku SVN nie można "zaktualizować" gałęzi funkcji z pnia, jak z kopii roboczej. Jednak możesz mieć częste scalanie i tworzenie nowych oddziałów.

Nawiasem mówiąc, RB wie obsługiwać pre-commit opinie, jak również.

Answer 6

zgadzam się z pierwszym zdaniem: Pre-commit opinię od tułowia

Od użycia narzędzi inspekcja kodu, upewnij się, nie niezrewidowanemu kodu w repozytorium, i aby utrzymać kasę czysty