Kiedy robić przegląd kodu?

Niedawno przeszliśmy do procesu scrum i pracujemy nad zadaniami i historiami użytkowników w sprintach. Chcielibyśmy często przeprowadzać recenzje kodu, aby były mniej zniechęcające. Myślimy, że robimy to na poziomie historii użytkownika, ale nie jesteśmy pewni, jak rozgałęzić nasz kod, aby to uwzględnić.

Używamy VS i TFS 2010 i jesteśmy zespołem 6 osób.

Obecnie rozgałęziamy funkcje, ale pracujemy nad przejściem na rozgałęzienie dla scrum.

Obecnie nie używamy zestawów półek i tak naprawdę nie chcemy wdrażać, jeśli dostępne są inne techniki.

W jaki sposób zalecamy wdrożenie recenzji kodu dla historii użytkownika?

To zależy od charakteru historii użytkowników.

Utworzenie gałęzi dla każdej historii użytkownika może być skuteczne, widoczne są postępy w różnych historiach, w razie potrzeby można je przekazywać, jeśli opowieści nie zostaną ukończone w sprincie, postęp może pozostać w gałęzi do następnego sprintu . Końcowe recenzje można następnie wykonać na końcu historii użytkownika w gałęzi historii użycia i scalić, jeśli kod jest zgodny ze standardem.

Aby działać w sposób, w jaki historie muszą być drobnoziarniste, aby zapobiec niemożliwym do zarządzania zadaniom scalania na końcu sprintu. Małe historie umożliwią stałą aktualizację gałęzi deweloperów poprzez sprint, z którego deweloperzy pracujący nad historiami innych użytkowników muszą stale pobierać (podstawowe VCM).

Powoduje to narzuty procesowe związane z ciągłym tworzeniem i łączeniem oddziałów, które w niektórych przypadkach można rozwiązać za pomocą skryptów automatyzacji, ale zespół nadal musi czuć się bardzo dobrze z VCS.

Pod koniec sprintu łączysz swoją gałąź programistów w integrację / produkcję itp.

Pracowałem również w zespołach, w których wszyscy pracują z jednej gałęzi deweloperów, po ukończeniu historii użytkownika kod jest przekazywany do tej gałęzi w celu przejrzenia i przetestowania, a jeśli ktoś popchnie coś, co psuje kompilację dewelopera, musi wprowadzić piwa zespołu.

Najskuteczniejszym sposobem sprawdzenia kodu jest wstanie, znalezienie kogoś i poproszenie go o przyjście i omówienie właśnie opracowanego kodu.

Nie używaj narzędzia, chyba że nie możesz znaleźć kogoś, kto lokalnie sprawdzi Twój kod.

Możesz całkowicie uniknąć recenzji kodu, łącząc go w pary.

Czy wszyscy w zespole są lokalni? Jeśli tak, poproś kogoś, aby przyszedł i sprawdził, zanim kod zostanie wpisany. Nie lokalny? Uruchom swój ulubiony program do udostępniania ekranu i zadzwoń do kogoś. Osobiście często to robię. Czasami robię to tylko po to, by powiedzieć „Hej, zobacz co zrobiłem!”

Zdecydowanie wolę ten styl recenzji kodu ad-hoc od stylu, w którym ktoś wstaje i przedstawia swój kod zespołowi. Recenzje ad hoc mogą dać wiele (wszystkich?) Korzyści z parowania bez niewygody. Ponadto „recenzent” chętniej zadaje pytania i sugeruje ulepszenia w nieformalnym otoczeniu jeden na jednego.

Uważam, że przegląd kodu nie jest formalną częścią SCRUM, ale poprawki są niezależną taktyką w celu osiągnięcia jakości i ulepszenia projektów / zespołu.

Dlatego użyłbyś SCRUM (lub innej zwinnej metodologii programistycznej), aby zapewnić / poprawić jakość PROJEKTU i dotrzymywać terminów. Dobrą taktyką jest również robienie przeglądu produktu (nie kodu) niezależnie od normalnych zadań kontroli jakości / testowania. Jeśli to działanie można wykonać przed zespołem / partnerami / klientami / publicznością, będzie lepiej.

Powinieneś używać poprawek kodu (lub innych konkretnych) głównie w celu ulepszenia swojego ZESPOŁU, oczekując wyników w perspektywie średnio- / długoterminowej. Wpłynie to na Twoje PROJEKTY, ale w dłuższej perspektywie jako efekt ulepszenia ZESPOŁU.

Tak więc, aby odpowiedzieć na twoje pytanie, uważam, że próbujesz zbyt mocno naciskać na SCRUM, i powinieneś lepiej rozważyć poprawki tylko takie, jakie są.

Czy nie jest oczywiste, aby robić recenzje kodu przed sprawdzeniem kodu?

TFS nie działa jak GIT, więc za każdym razem, gdy wpiszesz kod do oddziału lub pnia, jest on dostępny dla wszystkich.

Oznacza to, że sprawdzenie powinno nastąpić podczas odprawy, aby złe zmiany nie były propagowane do wszystkich kopii roboczych.