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?
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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!
źródło
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.
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.
źródło
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.
źródło