Jak stopniowo wprowadzać recenzje kodu?


26

Jestem szefem zespołu złożonego z kilkudziesięciu starszych inżynierów. Wierzę, że przydałoby się nam bardzo dużo recenzji kodu ze wszystkich standardowych powodów. Niekoniecznie każda zmiana, ale przynajmniej ciągły strumień recenzji w tle. Ludzie przynajmniej widzą zmiany innych i zaczynają o nich mówić.

Czy istnieje dobry sposób na wprowadzenie recenzji? Wyczuwam dużą niechęć zespołu, ponieważ jest to jeszcze jedna rzecz do zrobienia, a rozmowy mogą być bolesne. Mam nadzieję, że sprawdzenie każdej zmiany nie jest początkowe, przynajmniej jako pierwszy krok. Chciałbym, żeby ludzie zaczęli ćwiczyć rytm i ćwiczyć robienie recenzji z małą częstotliwością przed zwiększeniem ilości.

Czy ktoś z powodzeniem wprowadzał recenzje kodu stopniowo? W jaki sposób? Myślałem o konieczności recenzji „gorących” plików lub bibliotek. Lub zbieranie losowo. Albo ja wybieram „wybór” do przejrzenia zmian. A może jedyną drogą, którą możesz podjąć, jest zanurzenie się i zrobienie każdej zmiany?


Nie podkreśliłem tego wystarczająco w pytaniu, ale „stopniowo” był tutaj kluczowym elementem. Nie sądzę, aby przeglądanie 100% zmian było w ogóle wykonalne. Ale jeśli recenzujesz tylko część, jak wybrać tę część? Po prostu wybrać „ulubione zmiany”? Coś losowego? Ołów wybiera? Odpowiedzi tutaj są świetne, ale tak naprawdę nie trafiły w „stopniową” część w mojej głowie.
Philip

Odpowiedzi:


16

To nie jest problem z oprzyrządowaniem lub procesem. Chodzi o kulturę. Opisujesz zespół złożony z ludzi wrażliwych na krytykę i chroniących własną pracę. To bardzo, bardzo powszechne. Ale to nie jest profesjonalne.

Radzę zacząć od dawania przykładu. Zaoferuj swoje zobowiązania do przeglądu. Bądź otwarty i poproś, aby ludzie podkreślili problemy w twoim podejściu. Bądź otwarty na opinie. Nie bądź defensywny, ale zamiast tego zbadaj powody opinii i uzgodnij działania jako zespół. Zachęcaj do atmosfery otwartego dialogu. Znajdź jednego lub dwóch bohaterów w swojej drużynie, którzy również są gotowi to zrobić.

To jest ciężka praca.


38

Pierwszym krokiem byłoby podejść do kogoś i powiedzieć „hej, czy przejrzałbyś mój kod?”. Bądź zmianą, którą chcesz zobaczyć w swojej organizacji. Jeśli nie możesz znaleźć nikogo, kto by to zrobił, nie będziesz w stanie przekonać całego zespołu. Jeśli obaj osiągną sukces, zgłoś się do zespołu.

Gdy znajdziesz kogoś, kto sprawdzi Twój kod, zapytaj go, czy nie przeszkadza ci sprawdzenie jego kodu. Wyrażenie to jako okazję do uczenia się ciebie , a nie jako okazję do ich poprawienia ich kodu.


10
„Hej, nie jestem zadowolony z tego projektu, czy mogę dostać drugi zestaw gałek ocznych?” To świetny pierwszy krok. ++
RubberDuck,

4

Jako lider zespołu największą wartością, jaką czerpię z procesu przeglądu kodu, jest świadomość tego, co się dzieje. Lubię mieć szansę zobaczyć każdy zestaw zmian, nawet jeśli nie mam żadnych zmian ani sugestii dla programisty. Nazywam to „przeglądami świadomości”. Mogę je odwrócić w mniej niż 30 minut, aby nie było wąskiego gardła.

Proponuję zacząć od nich. Zdefiniuj proces przesyłania recenzji kodu (jest dość wycięty i wysuszony, jeśli używasz TFS) i zaangażuj wszystkich w przesyłanie swoich zestawów zmian do ciebie (i tylko ciebie) przed odprawą. Powiedz im, że to tylko dla świadomości i nikt nie będzie krytykować ich kodu.

Po iteracji lub dwóch przeglądach świadomości zacznij zapraszać innych członków zespołu do wzajemnego przeglądu kodu ... ponownie, wyłącznie w celu uzyskania świadomości. Wierzcie lub nie, to samo może być pomocne dla spójności zespołu i jednolitości kodu.

Gdy zaangażujesz cały zespół, prawdopodobnie przekonasz się, że programiści nie mogą się powstrzymać przed sugerowaniem sobie nawzajem kodu. Stanie się to naturalnie i ekologicznie (inżynierowie nie mogą się powstrzymać!) Poproś zespół o spotkanie w celu przedyskutowania tego i wypracowania wytycznych dotyczących konstruktywnej informacji zwrotnej. Następnie ustaw je. Gratulacje, jesteś teraz w trybie pełnego przeglądu kodu!


1
Bardzo podoba mi się ciekawa koncepcja „przeglądów świadomości”. Dla tropu wydaje się naturalne, że chcesz mieć świadomość tego, co robią inni. Ale myślę, że możesz uzasadnić to wszystkim w zespole, musimy zdawać sobie sprawę z tego, co robią inni z korzyścią dla nas samych. W przeciwnym razie nie jesteśmy nawet w zespole, po prostu pracujemy równolegle.
Philip

4

Czy istnieje dobry sposób na wprowadzenie recenzji?

Prawdopodobnie istnieje kilka dobrych sposobów, w zależności od zespołu i korzyści, które można uzyskać z recenzji, ale każde podejście będzie miało kilka wspólnych cech:

  • wyjaśnij, czego oczekujesz: jest to nowy proces dla Twojego zespołu lub przynajmniej zmiana w istniejącym procesie, więc uczciwe jest jedynie poinformowanie zespołu, dlaczego wprowadzasz zmianę, jak możesz oczekiwać, że zespół odniesie korzyść, i skąd będziesz wiedzieć, czy to działa.

  • zdefiniuj proces: Przeprowadź ludzi przez proces, który chcesz, aby sprawdzili kod, omawiali zmiany itp., aby wszyscy w zespole wiedzieli, jak postępować.

  • Zdefiniuj kryteria: Określ rodzaje zmian, które ludzie powinni, a nie powinni nazywać, że wymagają poprawy. Na przykład warto zauważyć błędy i znaczące ulepszenia wydajności; standardy kodowania, czytelność i łatwość konserwacji powinny być odnotowane, ale nie rozwiązywane; kwestie osobistego gustu lub stylu należy pozostawić w spokoju.

  • omów zachowanie: Zwróć uwagę, że celem jest poprawa kodu i wspólne zrozumienie, które pomoże zespołowi pisać lepszy kod na forum, nie zawstydzać nikogo, ustalać wyniki itp. Krytyka powinna być obiektywna i konstruktywna, nigdy osobista. Ustanowienie niektórych podstawowych zasad może pomóc złagodzić wątpliwości związane z przeglądem kodu.

  • postaw się na pierwszym miejscu: Niezależnie od tego, czy planujesz mieć indywidualne recenzje czy recenzje grupowe, prawdopodobnie dobrym pomysłem jest przejrzenie kilku pierwszych jako grupy. Pierwsza recenzja powinna zawierać Twój własny kod, aby inni członkowie zespołu mogli zobaczyć, że proces nie jest taki zły i że jesteś gotów sam go wykonać.

Rozpocznij od spotkania inauguracyjnego, aby wyjaśnić wszystkie powyższe kwestie i odpowiedzieć na obawy członków zespołu. Następnie prześlij wiadomość e-mail z dokumentacją procesu.

Wyczuwam dużą niechęć zespołu, ponieważ jest to jeszcze jedna rzecz do zrobienia, a rozmowy mogą być bolesne.

Są to dwie odrębne obawy. Jeśli uważasz, że recenzje będą pomocne, musisz poświęcić czas na ich wykonanie. Upewnij się, że członkowie zespołu rozumieją, że sprawdzanie działa jak każde inne zadanie, a nie coś dodatkowego, co muszą zrobić, kontynuując wykonywanie innych zadań w tym samym tempie.

Spotkania grupowe powinny być prowadzone przez moderatora, który prowadzi dyskusję, ogranicza długość spotkania i utrzymuje konstruktywność. To powinno pomóc w uniknięciu bolesnych rozmów. Do czasu, gdy będziesz gotowy do rozpoczęcia indywidualnych recenzji, zespół powinien przyjąć zachowania, które pomogą im zachować konstruktywność.

Od czasu do czasu należy również przejrzeć proces recenzji. Co jakiś czas zbieraj zespół, aby omówić proces: jak działa, jak można go poprawić, jakie praktyki należy porzucić itp. Daj zespołowi prawo własności do procesu i swobodę próbowania nowych rzeczy.


-2

Jednym ze sposobów jest przeprowadzenie sesji przeglądu kodu po każdym sprincie i przejrzenie zmian wszystkich osób, w których kod jest wyświetlany na jakimś dużym ekranie, aby wszyscy w zespole mogli wziąć udział. Wszelkie ulepszenia można dodać jako zaległości techniczne do zaległości.

To podejście działa, ale nie jest idealne.

Ostatecznym celem byłoby użycie żądania ściągnięcia, aby scalić kod z powrotem w master lub rozwinąć gałąź, w której każdy wiersz kodu musi zostać przejrzany.


3
Siedzenie wszystkich godzin na przeglądanie całego kodu wygenerowanego podczas iteracji po jego zakończeniu (i słusznie za późno) brzmi jak wspaniały sposób na zniechęcenie wszystkich do recenzji recenzji kodu.
RubberDuck,

Cóż ... jeśli przegląd kodu wygenerowanego podczas jednego sprintu zajmuje wiele godzin, to robisz to źle, albo Sprint ma 6 miesięcy, albo współpracujesz z 50 osobami, lub programiści nie robią nic w sprawie kodowania lub najlepszych praktyk. Ponieważ kodowanie nie kończy się po iteracji, nigdy nie jest za późno, a kod zawsze się zmienia, a dług technologiczny można rozwiązać w kolejnych iteracjach. A przeprowadzanie recenzji kodu w ten sposób pozwala programistom, którzy nigdy tego nie robili, zobaczyć, czego szukać i tak dalej ... kiedy już tak się zacznie, można go stopniowo przesuwać w kierunku żądań ściągania
Low Flying Pelican

mój zespół 7 dodaje / usuwa / modyfikuje kilka tysięcy wierszy kodu w ciągu ~ 3 tuzinów zatwierdzeń co dwa tygodnie. Przegląd jakości PR zajmuje około 15–60 minut. Średni PR to 3-4 zatwierdzenia. Więc tak. Gdybyśmy to wszystko zrobili naraz jako zespół, zajęłoby to 8 godzin x 7 programistów zamiast 8 godzin w całym zespole. Ubolewam nad twoją insynuacją, że robimy coś złego. Chodzimy do prod kilka razy w tygodniu . Czy ty?
RubberDuck,

Produkujemy raz na każdą iterację
Low Flying Pelican
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.