Czy przegląd kodu jest dobrą praktyką?

32

Kiedy firma, w której pracuję, zatrudniała nowych menedżerów, oferowała nam przegląd czyichś kodów na każdym spotkaniu. Mamy spotkania co dwa tygodnie, więc za każdym razem jeden z programistów pokazywał swój kod na projektorze, a inni zamierzali go omawiać.

Pomyślałem, że to będzie świetne: każdy programista będzie bardziej ostrożny podczas pisania kodu i będziemy mogli lepiej dzielić się naszym doświadczeniem. Ale jakoś o tym zapomnieliśmy i oferta po prostu pozostała ofertą.

Jakie są z tego korzyści i czy są jakieś wady?

superM
źródło
9
To brzmi jak nieformalne / zwykłe recenzje kodu, a przegląd kodu jest dobrą rzeczą (tm). Mamy nawet siostrzaną stronę z recenzjami kodu.
yannis
@ElYusubov, komentarz musi być pod odpowiedzią
Odeda
2
Obsługuje środowisko uczenia się. To tyle samo dla widzów, co pisarzy.
MathAttack,
3
Tak długo, jak pozostaje współpracować, jest to dobra praktyka. W niektórych kulturach firmy (w górę lub w dół) koledzy są wewnętrznymi konkurentami. W tych okolicznościach przeglądy kodu wymagają umiejętności społecznych / politycznych oprócz umiejętności technicznych. W takim razie powiedziałbym, że to zbyt stresujące. Najlepsze recenzje kodu to nieformalne opinie między kolegami: „hej, właśnie ściągnąłem aktualizację i zobaczyłem kod, który sprawdziłeś wczoraj. Może lepiej byłoby, gdybyś ... niż ...”. Współpracujący i korzystny, nie konkurencyjny. Pomysł projektora wydaje się jak wycieczka „rzućmy pomidorem”.
Louis Somers,
2
Jedną z głównych zalet recenzji kodu jest to, że automatycznie piszesz lepszy kod, jeśli wiesz, że zostanie wyemitowany publicznie.
James Anderson

Odpowiedzi:

52

Recenzje kodu są świetną praktyką.

Jest to prawdopodobnie najlepszy sposób uczenia się na błędach i sprawdzania, w jaki sposób niektóre problemy są rozwiązywane przez innych. Jest to również jeden z najlepszych sposobów na utrzymanie jakości w bazie kodu.

Przeglądy kodu zdarzają się w wielu firmach, choć trudno powiedzieć, że istnieje specyficzny proces, który wszyscy stosują.

W bardziej formalnym przeglądzie kodu starszy (lub kilku seniorów) usiądzie razem z programistą, aby przejrzeć swój kod, oferując jednocześnie sugestie i nauczanie.

Dodatkowe korzyści z recenzji kodu (skomentowane w tym pytaniu) obejmują:

  • Świetny sposób na nauczanie i uczenie się
  • Są jednym z najlepszych sposobów na poprawę i utrzymanie spójności bazy kodu (styl i idiomy)
  • Pomagają upewnić się, że wszyscy członkowie zespołu rozumieją styl i idiomy użyte w projekcie oraz sposób ich użycia
  • Przeglądy kodu przyspieszają rozwój, ponieważ wcześnie wychwytują błędy i wady projektowe (więc, chociaż mogą spowolnić początkowy rozwój, wypłacają dywidendy w późniejszych cyklach rozwojowych)
  • Dostępna jest obsługa narzędzi, która pomaga usprawnić proces przeglądu kodu
Oded
źródło
1
Tak, recenzje kodu są dobre. Ale czy nie spowolni programistów?
Radu Murzea,
4
@SoboLAN - Cóż, jeśli recenzje kodu oznaczają, że błędy są wykrywane wcześniej, a złe projekty są naprawiane, zanim będą miały szansę wejść do produkcji, co myślisz?
Oded
9
@SoboLAN: jakość, szybkość, cena - wybierz dowolne dwa.
Den
6
Jest to również najlepszy sposób na poprawę i utrzymanie spójności bazy kodu, tj. Upewnienie się, że członkowie zespołu rozumieją i dzielą się preferowanymi w projekcie idiomami kodowania oraz używają ich poprawnie.
Péter Török,
4
@SoboLAN: Z mojego doświadczenia wynika, że ​​recenzje kodu przyspieszają programistów. Szybciej wychwytujesz więcej błędów i harmonizujesz swoje rozwiązania z tym, co robią inni programiści.
Tynam
15

Recenzje kodu są bardzo przydatnym narzędziem do nauki , szczególnie gdy masz nowego członka zespołu na pokładzie. Znany jest również jako proces recenzowania :)

Istnieją różne rodzaje recenzji kodu:

  • Over-the-ramię - gdy jeden programista patrzy przez ramię autora kodu, gdy ten drugi przechodzi przez kod.
  • Przekazywanie wiadomości e-mail - system zarządzania kodem źródłowym automatycznie wysyła kod do recenzentów po dokonaniu zameldowania. Wyciąg z komentarza: Nie udało mi się przekonać kierownictwa do poświęcenia czasu na jakąkolwiek formalną weryfikację kodu. Spojrzałem na zmiany w moich współpracownikach, ilekroć ściągam nowe poprawki z kontroli źródła za pomocą narzędzi historii / różnic wbudowanych w Tortise
  • Programowanie parowe - dwóch autorów opracowuje kod razem na tej samej stacji roboczej, co jest powszechne w programowaniu ekstremalnym.
  • Wspomagane narzędzie przeglądanie kodu - autorzy i recenzenci używają specjalistycznych narzędzi zaprojektowanych do przeglądu kodu równorzędnego.

Jest tylko jeden, w associated disadvantagektórym formalne przeglądy kodu wymagają znacznych inwestycji w przygotowanie do zdarzenia przeglądu i czasu wykonania.

Więcej referencji znajduje się poniżej (dla bardziej szczegółowych odczytów nurkowania)

EL Yusubov
źródło
1
Twój drugi pocisk można poszerzyć. Ponieważ nie udało mi się przekonać kierownictwa do poświęcenia czasu na jakąkolwiek formalną weryfikację kodu, zacząłem przeglądać zmiany współpracowników, ilekroć ściągam nowe poprawki z kontroli źródła za pomocą narzędzi historii / różnic wbudowanych w Tortise.
Dan Neely
@ Dan Niezwykle dobry komentarz, na pewno go dołączę.
EL Yusubov
11

Ta szczególna praktyka wydaje się nieefektywna i może być krępująca - kto chce, aby ich błędy wskazywały całej grupie ludzi. Jeśli więc nie będą mogli wybrać tego, co ma zostać sprawdzone, a kod nie jest jeszcze produkowany, może to sprawić, że ludzie poczują się niekomfortowo.

W zależności od tego, kiedy kod jest sprawdzany, może mieć dużą różnicę w tym, czy komentarze recenzowania kodu trafią do kodu, czy nie. Jeśli deweloper może wybrać i wybrać tylko kod produkcyjny, komentarze do recenzji prawdopodobnie nie zostaną wdrożone. Fajnie jest organizować spotkania, na których programiści mogą pochwalić się sprytną techniką, której nauczyli się inni, ale to nie jest przegląd kodu. To jest trening.

Sprawdzamy kod każdego fragmentu kodu, zanim zostanie on przeniesiony do kontroli jakości. Każdy kawałek Dotyczy to zasadniczo tylko recenzenta kodu i programisty. Nie przechodzi ono do kontroli jakości, dopóki recenzent kodu go nie przejdzie. Deweloper musi więc wprowadzić zmiany. Znaleźliśmy i szybko naprawiliśmy wiele problemów, których QA nie mogła znaleźć (znajdują też rzeczy, których nie widzimy w przeglądzie kodu). Co więcej, zmniejsza to kodowanie kowbojów i szybko identyfikuje osoby, które nie radzą sobie dobrze, abyśmy mogli naprawić ich problemy i przeszkolić je lub pozbyć się, zanim spowodują uszkodzenie naszej aplikacji. Czas przeglądu kodu jest częścią naszego szacunkowego czasu przy planowaniu pracy, więc nie ma żadnego wpływu na termin. W rzeczywistości oszczędza czas na dłuższą metę, ponieważ im wcześniej problem zostanie znaleziony, tym łatwiej go naprawić.

Osobiście nauczyłem mniej doświadczonych programistów wielu lepszych technik poprzez przegląd kodu i sam nauczyłem się kilku lepszych technik, przeglądając kod innych ludzi, a także ich komentarze do mojego kodu. Dalsza weryfikacja kodu upewnia się, że ktoś inny rozumie kod, co znacznie ułatwia jego utrzymanie. Czasami kod działa, ale pytania przeglądu wyjaśniają, że wystąpią problemy z utrzymaniem, ponieważ kod jest trudny do zrozumienia. Lepiej zreformować w tych przypadkach, gdy wszystko jest jeszcze w pamięci, niż rok później, kiedy nawet autor kodu drapie się po głowie i zastanawia się, dlaczego kod robi to i tak.

HLGEM
źródło
Absolutnie się z tobą zgadzam, ale mam nadzieję, że nasz zespół jest wystarczająco profesjonalny, aby się nie wstydzić, tylko się uczyć.
superM
2
Wreszcie rozsądna odpowiedź. Przekonałem się, że o wiele skuteczniejsze jest dokonywanie poprawek tylko z programistą i jednym recenzentem niż w grupach. W ten sposób o wiele łatwiej jest poradzić sobie z błędami po obu stronach i od czasu do czasu można przejść do programowania par bez marnowania czasu innych w grupie.
x4u
5
@ superM, reguła brzmi „wychwalaj publicznie, krytykuj prywatnie” z jakiegoś powodu.
HLGEM,
+1 za czas. Najlepiej jest kodować parami, najpierw w teście. Ale w każdym razie chcesz przejrzeć kod, gdy nadal chcesz go przepisać. Przeglądanie kodu nie ma większego sensu, jeśli nie chcesz przeprowadzać poważnych porządków. Byłem w recenzjach kodu, w których pierwotny programista wziął ponad 50 linii kodu, aby ponownie zaimplementować funkcję biblioteki. Ale odkąd ten kod został przetestowany, zastąpienie 50 niepotrzebnych wierszy jednym wywołaniem funkcji nie było dozwolone! To zmienia program 10 000 linii, który może być utrzymany przez połowę programisty, w program 100 000 linii, który wymaga czterech.
kevin cline
8

Problem z tego typu przeglądem kodu, jeden programista co dwa tygodnie, postęp będzie powolny. Może minąć kilka miesięcy, zanim wszyscy znajdą się w centrum uwagi.

Chociaż przeglądy kodu mogą być dobre, musi istnieć powód i procedura ich wykonywania.

Trzeba będzie rozstrzygnąć kilka kwestii:

  • Kto wybierze programistę i ile zostanie powiadomionych. Recenzje bez powiadomienia są pułapkami.
  • Kto wybierze część kodu poddawanego przeglądowi: kierownictwo, starszy programista w projekcie lub recenzowany programista.
  • Ma na celu nauczyć osobę, której kod znajduje się na projektorze, jak zrobić coś lepiej, lub jest celem osoby, której kod znajduje się na projektorze, aby nauczyć wszystkich w pomieszczeniu, jak poprawić swój kod.
  • Jaki procent kodu zostanie sprawdzony w ten sposób, czy będzie to częścią procesu kontroli jakości?

Jeśli osoby, które zaproponowały ten plan, nie mają jeszcze odpowiedzi na te pytania, możliwe jest, że przeczytały artykuł o tym, jak wszystkie wielkie firmy robią recenzje kodu, więc powinniśmy je również zrobić, nie rozumiejąc za tym celu.

mhoran_psprep
źródło
3

Przegląd kodu jest świetną praktyką, tylko gdy pomysł na przegląd kodu pochodzi od zespołu programistów. Deweloperzy nie potrzebują projektorów i prezentacji do wzajemnego sprawdzania kodu. Jeśli chcą - wolą iść na konferencję.

Kiedy pomysł przeglądu kodu pochodzi od zarządzania - może to brzmieć jak badanie niskiej jakości oprogramowania i może zdemoralizować zespół programistów. Nie sądzę, że zespół zarządzający powinien być zaangażowany w proces przeglądu kodu. Przegląd kodu wraz z zespołem zarządzającym - bardzo zła, zabójcza i destrukcyjna praktyka.

Nikolay Fominyh
źródło
2

Przegląd kodu jest doskonałą praktyką, zwłaszcza jeśli programiści dokonują dzielenia się wiedzą, a podstawowe zasady są ustalane z wyprzedzeniem, aby sugestie i krytyka miały być KONSTRUKCYJNE, a nie wykorzystywać indywidualnego programistę do praktyki docelowej.

Menedżerowie, którzy nie są programistami, zostaną powitani przez programistów podejrzliwie, jeśli zdecydują się na przegląd kodu. Większość typów menedżerów nie chce zagłębiać się w szczegóły, którymi programiści się zajmują, patrząc na kod. Większość menedżerów również nie zrozumie, dlaczego programiści krytykują jedno podejście nad drugim.

Jeśli chcesz pokazać dobrą pracę, jaką programiści wykonują w zarządzaniu, wówczas „przegląd kodu” ma inne znaczenie i nie powinien być tak szczegółowy, jak przegląd kodu, który ma na celu instruowanie / poprawę jakości kodu wśród programistów. Tego rodzaju prezentacja może być pomocna w zademonstrowaniu, co robią programiści, jeśli prezentacja może być na wyższym poziomie i mniej specyficzna dla kodu, koncentrując się na tym, co rozumieją menedżerowie (wartość, ROI itp.). Może sprawić, że menedżerowie zrozumieją, że Joe wniósł znaczącą wartość dodaną do firmy, budując X, co możemy zaoszczędzić Y czasu lub dolarów Z na zamówienie itp. Myślę, że warto spróbować wykazać wartość jednostki członkowie twojego zespołu. Pamiętaj jednak, że musisz uważać, aby nie przytłoczyć odbiorców żargonem ani zbyt wieloma poziomami szczegółowości.

Jennifer S.
źródło
1

Chociaż w pełni zgadzam się, że recenzje kodu są bardzo konstruktywne w nauczaniu, chciałbym podkreślić, ale dla mnie i tak jest to zapewnienie prawidłowego przestrzegania wzorców projektowych zespołu.

Piszemy trochę pracy prototypowej i refaktoryzujemy fragmenty kodu i chociaż na końcu czujemy się komfortowo z produktem, czytelność została uszkodzona - ludzie nie mogą na to patrzeć i widzieć tak wyraźnie, co się dzieje.

Niezależne oczy są zawsze korzystne, gdy utkniesz w pewnych trybach myślenia, i to na wszystkich poziomach doświadczenia. Poświęciłeś wiele godzin na projektowanie i kod, więc recenzje kodu są trudne do rozwiązania, gdy istnieje obawa, że ​​Twój wysiłek zostanie odrzucony. Jednak na koniec masz nadzieję, że otrzymujesz czystszą, prostszą i łatwiejszą do zarządzania aplikację, a doświadczenie jest w tobie zakorzenione.

Dla naszego zespołu robimy jak wspomniano @ElYusubov i używamy narzędzia specjalnie do przeglądu kodu - Crucible. Ludzie sprawdzają, komentują i podpisują kod. Co tydzień siadamy i analizujemy twarzą w twarz interesujące i / lub złożone fragmenty kodu.

John D.
źródło
+1, wszyscy możemy „sprawić, by działało”, ale chodzi bardziej o to, aby kod był czytelny i łatwy do utrzymania, szczególnie poprzez przestrzeganie konwencji. Nie jest to najbardziej ekscytująca praca, ale bardzo cenna.
Kirk Broadhurst
1

Jako stażysta ds. Oprogramowania znalazłem bardzo pomocne recenzje kodu.

W moim zespole wymagana jest weryfikacja kodu dla każdego zatwierdzenia (duże zmiany kończą się formalnie, mniejsze zmiany kończą się „szybkim spojrzeniem”). Zdecydowanie czuję się tak, jakby moje ulepszenia inżynieryjne / projektowe zostały przez to wzmocnione, tym bardziej, że bardziej prawdopodobne jest, że natychmiast wyciągnę tablicę niż terminal, ponieważ wiem, że jestem „obserwowany”. :)

W efekcie myślę, że produkuje on znacznie lepszy kod, a jedyną niewielką wadą jest nieco wolniejszy czas programowania (co moim zdaniem jest tego warte na dłuższą metę, gdy nie trzeba poprawiać / rozszerzać strasznie zaprojektowanego kodu). Myślę też, że jeśli w zespole są juniorzy / stażyści, docenią szansę na cenne opinie. Wiem, że tak!

Colin
źródło
Pracuję dopiero od 1,5 roku i chcę tych recenzji kodu z podobnych powodów. ))
superM
1

Z mojego doświadczenia Code Review jest naprawdę świetną rzeczą, jeśli wykonujesz go dobrze. Gdy masz profesjonalnych / dojrzałych członków zespołu i menedżerów. Jako programiści jesteśmy „rozwiązującymi problemy”. Naszym zadaniem nie jest tworzenie wierszy „tekstu”. Dlatego musimy dzielić się pomysłami, błędami, problemami, doświadczeniami. Przegląd kodu jest naprawdę dobrą praktyką, aby to osiągnąć.

Niestety, brzmi świetnie, ale w większości firm jest naprawdę trudny do wdrożenia. Twój zespół potrzebuje dużo „autonomii”. Przekonanie kierowników lub działów finansowych, że nie tworzenie nowych funkcji jest opłacalne, wydaje się trudne.

W mojej firmie próbujemy dokonać przeglądu kodu. Ale zbyt wiele czasu spędza się na „ściganiu królika” (robieniu funkcji).

Michał Franc
źródło
„Chasing the rabbit” brzmi dla mnie bardzo dobrze)). ale nadal mam nadzieję, że uda nam się wprowadzić przegląd kodu, szczególnie gdy nasi menedżerowie w ogóle nie mają nic przeciwko.
superM
1

Wiele sprawdzeń stylu i podstawowych typów składni jest obecnie wykrywanych przy użyciu narzędzi (FXCop itp.).

Jednak przeglądy kodu są dobre, szczególnie w przypadku nowych członków zespołu, rzeczy złożonych lub mających duży wpływ (np. Coś, co będzie zauważalne dla ważnych osób, jeśli zawiedzie lub spowoduje wpływ na biznes), a zwłaszcza podczas outsourcingu lub korzystania z krótkoterminowych kontrahentów (szczególnie ponownie gdy nie są językami ojczystymi, ponieważ błędy w tłumaczeniu / problemy językowe mogą pozwolić oprogramowaniu przejść wszystkie testy, ale nie robić tego, co powinny).

Nie jestem fanem umieszczania kodu na projektorze, aby zespół mógł go przejrzeć - znacznie lepiej jest zorganizować spotkanie poświęcone przeglądowi kodu, podczas którego inny członek zespołu (kierownik zespołu itp.) Przechodzi przez listę z deweloperem. Wpływa to mniej ludzi - zatrzymuje dużo straconego czasu na argumenty stylu - i jest mniej krępujące dla deweloperów. Twórca jest bardziej konstruktywny i łatwiej jest wchłonąć prawdziwe problemy i nie dać się zaślepić komentarzom typu „zrobiłbym to ...”.

Myślę też, że niewymuszone recenzje kodu - takie jak umieszczanie kodu w udziale lub wysyłanie go pocztą elektroniczną w nadziei, że ktoś poświęci czas na lunch, aby go przejrzeć - to strata czasu.

Idealne do tego jest usiąść ze stosem list, markerem i filiżanką kawy w strefie kawy.

Wolf5370
źródło
0

Tego rodzaju grupowe pokazy i informacje byłyby dobre dla nowych technologii lub zdobycia kilku jr. rozwija się szybko, ale nie sądzę, że jest tak dobra, jak spójna recenzja nowego kodu. Bardziej efektywne jest robienie tego jeden na jednego.

JeffO
źródło
-2

Przegląd kodu pomaga zobaczyć „całość”. Oddzielni programiści mają tendencję do dostrzegania tylko swoich wymagań / problemów. CR odkrywa pomysły i rozwiązania z całej perspektywy. CR głównie pomaga wyeliminować marnotrawstwo niepotrzebnej pracy. Cały produkt jest tańszy i lepszej jakości.

Tibor Beck
źródło
1
bez wyjaśnienia odpowiedź ta może stać się bezużyteczna w przypadku, gdy ktoś inny wyrazi przeciwną opinię. Na przykład, jeśli ktoś opublikuje takie twierdzenie, jak „Przegląd kodu, zasłania rzeczy, utrudniając dostrzeżenie„ całości ” , w jaki sposób ta odpowiedź pomoże czytelnikowi wybrać dwie sprzeczne opinie? Rozważ edycję go w lepszym stanie, aby spełnić wytyczne How to Answer
gnat