Czy przegląd kodu jest dobrą praktyką?

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?

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

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)

• MSDN - przegląd kodu
• Znajdź i napraw luki w zabezpieczeniach przed wysłaniem aplikacji
• Link do Wiki

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.

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.

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.

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.

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.

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!

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).

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.

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.

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.