Jak skłonić programistów do szybkiego dokonywania recenzji kodu

Firma, dla której pracuję, wymaga sprawdzenia całego kodu przez innych programistów przed jego zatwierdzeniem. Członkowie mojego zespołu są często sfrustrowani, ponieważ inni programiści są zbyt zajęci kodowaniem, aby dokonać przeglądu, szczególnie jeśli jest on bardzo długi. Jak zachęcasz innych programistów do dokonywania terminowych recenzji kodu?

(Używamy git-svn, abyśmy mogli kontynuować kodowanie w oczekiwaniu na recenzję. Jednak wciąż frustruje mnie, gdy muszę długo czekać, zanim będę mógł zatwierdzić swój kod).

Zobacz, jak robi to Facebook z własną aplikacją o nazwie phabricator: http://phabricator.org/

Zasadniczo zatwierdzają dla poszczególnych numerów, a dla każdego numeru wyświetlany jest kod, który ktoś ma sprawdzić. Kod nie trafia do ich głównego repozytorium, dopóki recenzent nie stwierdzi, że jest to w porządku.

Myślę, że to sprawia, że ​​jest to bardziej zabawne.

Być może kod powinien być przypisany dwóm osobom: jednej, która to robi, i drugiej, która go recenzuje.

Chociaż być może twoi koledzy z drużyny nie wierzą w tę recenzję.

Osobiście, z braku recenzentów, użyłem testów jednostkowych dla funkcji niższego poziomu i „testu woźnego” dla całej reszty: test woźnego jest tak nazywany, ponieważ nawet woźny powinien być w stanie zrozumieć Twój kod.

Zwykle usuwałem niektóre drobne części, takie jak nawiasy blokowe / funkcyjne, notki widoczności, czasem nawet typy, i pokazywałem to menedżerom, ekspertom domeny, partnerom, którzy poprosili o kod: „czy tego chcesz?”

Pomaga też osobiście udać się tam i nie wyjechać, dopóki nie dokona się przeglądu.

Lub, jeśli nie masz nic przeciwko zespołowi lub nie są w porządku, wiesz, „jeśli możesz zmienić firmę, zmienić firmę” ...

Opieram to na kilku założeniach:

1. Wydaje się, że wszyscy chcą pisać kod (jeśli nie, masz ludzi, którzy muszą iść).
2. Wszyscy chcą, aby ich kod został sprawdzony.

Zezwalaj tylko tym, którzy wypełniają recenzje, na sprawdzenie kodu.

Być może pewien blok czasu można poświęcić na przeglądanie kodu w nadziei uniknięcia problemu przerwania.

Celem powinno być sprawdzenie kodu jakości. Nie chcesz karać / wymuszać recenzji do tego stopnia, że ​​wszyscy po prostu przyznają jej „pieczątkę”.

Jeśli masz różne poziomy (jr., Sr. Itp.), Awans i utrzymanie tytułu powinny być uzależnione od wykonania pracy.

W przypadku kilku poprzednich pracodawców rotowaliśmy, którzy codziennie korzystali z Code Review. Zwykle 3 osoby dzieliły dzień CR i każdy CR musiał być podpisany przez dwóch recenzentów. To sprawiło, że kiedy był twój dzień, wiedziałeś, że CR będzie od ciebie oczekiwany, niezależnie od innych projektów. Co około pięć dni nadeszła Twoja kolej i możesz odpowiednio dostosować swoje zadania programistyczne.

Obecnie mamy kierownika zespołu, który pobierze pobieżnie CR na kodzie swojego zespołu. W zależności od tego, który obszar aplikacji został zaktualizowany, po zakończeniu CR można go podnieść do Globalnego Zespołu Przeglądu, w którym sprawdzamy, czy istnieją rzeczy, które mają globalny wpływ na aplikacje, zamiast rzeczy, które są związane z jedną funkcją. Kiedy trzeba dokonać dużej recenzji, zwykle dzielimy ją na kilka osób, aby nikt nie musiał radzić sobie ze zmianami w absurdalnej liczbie plików.

To powiedziawszy, zawsze sprawdzamy tylko kod, który został przypisany do aktualnej gałęzi / wariantu Dev. Kod musi przejść przegląd kodu, przegląd globalny, przegląd DB i przegląd interfejsu użytkownika (każdy w razie potrzeby), zanim będzie można go awansować do następnego środowiska (np. Alpha).

Wreszcie, zgadzamy się na umowę SLA dotyczącą tego, jak szybko zmieniane są Recenzje. Prawie nic nie stoi w kolejce przez ponad 48 godzin, a większość recenzji jest wykonywana w mniej niż 24 godziny.

Firma, dla której pracuję, wymaga sprawdzenia całego kodu przez innych programistów przed jego zatwierdzeniem. Członkowie mojego zespołu są często sfrustrowani ...

O ile nie tworzysz oprogramowania o znaczeniu krytycznym lub poprawek krytycznych do kodu kandydata do wydania produkcyjnego, nie ma istotnych powodów, by ściśle trzymać się określonego rodzaju recenzji kodu.

• ^{Idea stojąca za wymaganiami Twojej firmy brzmi rozsądnie na pozór (100% sprawdzony kod), ale środki, które zdecydowali się zastosować, przynoszą efekt przeciwny do zamierzonego - ponieważ, jak zauważyłeś, prowadzą do frustracji programistów.}

Wchodząc w twoje buty, chciałbym najpierw wskazać kierownictwu, że recenzje kodu po zatwierdzeniu są uważane za równie godne szacunku, jak te przed zatwierdzeniem . Terminy te można przeszukiwać w Internecie - w razie potrzeby znajdź odniesienia do kopii zapasowej tego. Aby uzyskać 100% sprawdzonego kodu, nie trzeba koniecznie dokonywać przeglądu przed zatwierdzeniem .

W oparciu o powyższe zasugerowałem następnie, aby porzucili podejście mikrozarządzania i pozwolili programistom wypróbować sposób, który będzie im wygodniejszy. Recenzje przed lub po zatwierdzeniu najlepiej pozostawić programistom do wyboru. Jeśli firma wie lepiej niż programiści, dlaczego nie sami piszą kodu?

Masz wiele problemów do rozwiązania - musisz zdobyć serca i umysły oraz upewnić się, że masz czas na recenzje kodu.

Druga część jest prawdopodobnie najłatwiejsza - zgadzasz się (łącznie i to musi obejmować zarządzanie), że pierwszą rzeczą, którą programista robi każdego ranka, są recenzje kodu - jest to proste, zrozumiałe, skuteczne i daje ci fajny kij do pokonania ludzi jeśli nie są zgodne. Co więcej, niczego nie przerywasz, nie prosisz ich, aby przestali pracować nad swoim kodem, nie prosisz ludzi o wyciśnięcie czegoś z listy rzeczy do zrobienia ...

Pierwsza część to prawdziwy problem - uczestnicy procesu sprawdzania muszą widzieć, że ma wartość, w przeciwnym razie nigdy nie zrobią przeglądu kodu (który jest postrzegany jako nie mający wartości), gdy mogą pisać kod lub naprawiać błędy (które jest z pewnością ważniejsze ...?).

Jeśli umiesz połączyć te dwa elementy - po pierwsze upewniając się, że wszyscy wierzą (lub rozumieją), że w recenzjach kodu ma wartość - w najprostszym przypadku powinno to oznaczać mniej błędów, co oznacza więcej nowego kodu, co zwykle sprawia więcej zabawy, a następnie po drugie porządkowanie rzeczy, aby w harmonogramie było wolne miejsce na przegląd kodu, mam nadzieję, że wydarzy się coś dobrego ... stanie się częścią kultury.

Kiedyś będzie to część kultury, może nie być już konieczne mówienie „pierwsza rzecz każdego dnia” - ale powiedziawszy, że uważam, że pasuje do wzorca, w którym prawdopodobnie chce pracować deweloper.

W większości firm, dla których pracowałem, masz 3 dni na dokończenie recenzji. Niedopuszczalne jest nie robienie recenzji. To część twojej pracy. Jeśli nie zrobisz przyzwoitych recenzji na czas, wpłynie to na twoją ocenę wydajności. I tak, recenzje zawsze wydają się zdarzać w najbardziej nieodpowiednich momentach. Szkoda, naucz się uwzględniać czas oceny w swoich prognozach. W każdym razie, jeśli kierownictwo naprawdę wierzy, że recenzje są ważne (tj. Nakazują przeglądanie całego kodu), wówczas zastosowaliby podobną politykę. Dodatkowo, jeśli ludzie nie ukończą przeglądu w wyznaczonym czasie, oznacza to akceptację materiału.

Rozważ skorzystanie z narzędzia takiego jak komisja recenzująca . Jest to bardzo pomocne, szczególnie w przypadku długich recenzji.

Możesz przesłać swoje różnice i poczekać, aż recenzent zakończy swoją recenzję. Jeśli masz otwarte recenzje, które uniemożliwiają ci kontynuowanie pracy, możesz to zgłosić podczas codziennych spotkań (Twój zespół chce, aby nowe funkcje zostały sprawdzone, aby można je było jak najszybciej przetestować, prawda?).

Kilka punktów do dodania, których nie ma w innych odpowiedziach.

Kod do przejrzenia musi zostać zameldowany

• tak, że przeglądasz stabilną wersję.
• Może znajdować się w głównej gałęzi programistycznej, jeśli wydanie jest wystarczająco daleko
• Może być na gałęzi, jeśli istnieje dobry powód, aby nie zanieczyszczać magistrali

Blokowanie zadań ma pierwszeństwo, dlatego recenzje kodu powinny mieć pierwszeństwo przed innymi pracami (ale starając się nie przerywać przepływu). Jako programista powinieneś poprosić innych o sprawdzenie Twojego kodu (ponieważ chcesz go ulepszyć). Mając tę ​​wiedzę, należy niezwłocznie wykonywać recenzje dla innych osób.

Trudniejsze pytania dotyczą tego, kiedy i jak dobrze wykonywać recenzje kodu.

Reguła, która zadziałała dla nas w tym momencie, jest taka, że ​​kod dzielony musi zostać sprawdzony, ponieważ ma szerszy wpływ, podczas gdy w kodzie dla pojedynczej aplikacji (szczególnie biorąc pod uwagę, że używamy programowania opartego na testach) jest mniej ważny.