Jak radzić sobie z brakiem recenzji kodu w moim nowym miejscu, kiedy pochodzę z tej praktyki?

33

Zespół w mojej nowej firmie nie ma procesu sprawdzania kodu.

Pochodzę z firm, w których weryfikacja kodu jest obowiązkową kulturą, dlatego nie czuję się komfortowo, popełniając mój kod bez sprawdzenia go przez kogoś.

Jestem głęboko przekonany, że przegląd kodu jest sposobem na poprawę jakości i oszczędność czasu, ponieważ wcześniej wychwytuje potencjalne problemy (uwaga: nie mówię jednak o programowaniu par).

  • Jak mogę pokazać, że przegląd kodu nie jest marnowaniem czasu, ale oszczędnością czasu?
  • Czy przegląd kodu można pominąć, jeśli masz testy jednostkowe?
jparkcool
źródło
zalecenia dotyczące zasobów poza witryną są wyraźnie nie na temat w centrum pomocy . Zobacz meta.programmers.stackexchange.com/questions/6483/…
gnat
1
Zastanów się nad pytaniem tutaj: meta.codereview.stackexchange.com I moim zdaniem to pytanie można zadać tutaj, ponieważ on / ona chce po prostu poznać coś związanego z Programowaniem.
xqMogvKW
1
Chociaż jestem również głęboko przekonany do recenzji kodu, miałem również złe doświadczenia, w których przegląd kodu zmienił się w wieczną wojnę, narzędzie do przeglądu kodu (gerrit) zamieniło się w złego awatara na forum dyskusyjnym z nadmiernie namiętnymi debatami przez ponadgabarytowe ego. Nie jestem pewien, czy tak się stanie w jakimkolwiek towarzystwie, czy to tylko kwestia dojrzałości ludzi.
Joel
Powrócił do pytania, o które pytasz, ponieważ „Czy przegląd kodu jest koniecznością?” jest zbyt szerokim, niepodważalnym pytaniem, ponieważ będzie zależeć od ogromnej liczby czynników - wielkości firmy, # programistów, przychodów itp. itp. Zastanawiałbym się nad tym, jak możesz zarówno uwzględnić, jak i promować swoje pragnienie i entuzjazm dla dobrych praktyk programistycznych i kunszt oprogramowania na twoich publicznych stronach (CV, linkIn, github, twitter itp.). opublikuj to, na czym ci zależy i czego szukasz, aby ludzie, z którymi chcesz być, mogli to zobaczyć. To oczywiście „przyszłość”, stąd komentarz :)
Michael Durrant
3
Nie widzę, jak to jest „zalecenie dotyczące zasobów poza witryną”. To nie brzmi dla mnie jak właściwy powód.
nyuszika7h,

Odpowiedzi:

30

Czy przegląd kodu można pominąć, jeśli masz testy jednostkowe?

Ale dlaczego?

Podstawową rolą recenzowania nie jest wykrywanie błędów.

Tak, możesz zidentyfikować niektóre potencjalne błędy i wątpliwy, podatny na błędy kod, co często się zdarza, ale czasami wykrycie pewnych błędów nie oznacza, że ​​wzajemna ocena jest niezawodnym sposobem wykluczenia obecności błędów. Daleko od tego. To nie jest właściwe narzędzie do weryfikacji poprawności funkcjonalnej wdrożenia.

Przegląd kodu wymusza jednak jego konserwację . Będę wymagał, aby kod był czysty i zrozumiały (nie tylko dla jego autora), zanim wejdzie do produkcji.

Obecność testów jednostkowych jest całkowicie ortogonalna. Możesz mieć 100% pokrycia kodu i wszystkie testy przechodzą na całkowicie niezrozumiały kod.

Przegląd kodu służy również do zapoznania innych programistów z Twoją pracą, aby wiedzieli, co jest w stanie, i mogli stamtąd odbierać, lub obsługiwać raporty o błędach podczas wakacji itp. Wiedza o tym, co zrobiłeś od razu, może im pomóc dobrze wykonują swoją pracę - utrzymuj spójność bazy kodu (trzymaj się podobnych wzorców i konwencji w całej aplikacji) lub unikaj powielania kodu.

W szerszym ujęciu rzeczy uczy się i rozwija jako programista, czytając kod innych osób.

Testy jednostkowe nie mogą zastąpić żadnego z nich. Tak, jeśli są dobrze napisane, czytają jak dokumentację i powinniśmy do tego dążyć. Ale znowu nie wyklucza się to wzajemnie z przeprowadzaniem wzajemnej oceny, wręcz przeciwnie - wszystkie zalety wzajemnej oceny są nadal aktualne, fakt, że twoi rówieśnicy mają kilka fajnych testów jednostkowych, które sprawią, że proces recenzowania będzie łatwiejszy i jeszcze bardziej korzystny zamiast zbędnych.

Konrad Morawski
źródło
4
Nie sądzę, aby testy jednostkowe również zastępowały przeglądy kodu. Ale podstawową rolą testów jednostkowych nie jest również wychwytywanie błędów. Tak, możesz zidentyfikować niektóre potencjalne błędy podczas pisania testu jednostkowego, ale testy jednostkowe mają na celu upewnienie się, że nie wprowadzisz błędów później, gdy będziesz musiał coś zmienić. Dlatego celem testów jednostkowych jest również utrzymanie kodu w celu utrzymania.
Doc Brown,
2
@DocBrown to prawda. Jednak łapanie błędów regresyjnych również należy do kategorii łapania błędów. Oczywiście jest to jedna z zalet testów jednostkowych w porównaniu z recenzją (w tym aspekcie), ponieważ nie są one operacją jednorazową. Recenzja nie próbuje nawet zmierzyć się z tym ważnym aspektem, ponieważ nie jest możliwe ponowne sprawdzenie całej bazy kodu po każdej zmianie.
Konrad Morawski
1
@DocBrown Peer review doesn't even attempt to tackle this important aspect- no cóż, w pewnym sensie. W stopniu. Często zwracam uwagę np. „partnerze, skutecznie powtarzasz tutaj tę samą logikę, a to tykająca bomba. Pewnego dnia zmieni się ona w tym innym miejscu i zapomnimy ją tutaj zaktualizować ...”
Konrad Morawski,
24

Czy są jakieś badania i statystyki pokazujące, że przegląd kodu nie jest marnowaniem czasu, ale oszczędnością czasu?

Nie znam żadnego. Trudno też prowadzić takie badania, ponieważ potrzebne byłyby dwa zespoły, które mają zadanie o równej i realistycznej złożoności do wykonania, w którym jeden używa recenzji kodu, a drugi nie. Prawdopodobnie będziesz musiał poprosić ich o rozwiązanie tego samego problemu, co oznacza wyrzucenie dużej ilości pieniędzy przez okno. I trzeba by powtarzać eksperyment wystarczająco często, aby uzyskać trafność statystyczną, co zwiększyłoby ilość wyrzucanych pieniędzy o rzędy wielkości.

Jeśli po prostu zmierzysz wydajność firm korzystających z recenzji kodu w stosunku do firm, które tego nie robią, nie tylko nie będzie jasne, jak zmierzyć wydajność, ale także jaka jest rzeczywista przyczyna. Recenzje kodu są częścią większej kultury. Trudno powiedzieć, która jego część sprawia, że ​​zespół jest bardziej wydajny (i może zależeć od charakteru zespołu lub projektu). Lub obecność tej kultury może po prostu oznaczać, że firma jest mniejsza lub młodsza, a każda z nich ma wiele efektów. A może po prostu chęć poddania się przeglądowi kodu wyklucza lub promuje zdrowy dystans do twojego ego;)

Ale nie zapomnij: możesz czerpać z własnego doświadczenia. To po części dlatego cię zatrudnili. Więc jeśli naprawdę wierzysz, że możesz zwiększyć efektywność (a twój zespół rzeczywiście cierpi na jej brak), to przekaż to jasno.

Czy przegląd kodu można pominąć, jeśli masz testy jednostkowe?

Nie. Jeśli wierzysz w ważność testów, to tak naprawdę twoje testy powinny być pierwszą rzeczą do sprawdzenia. Co jeśli są nonsensowne? A jeśli zasięg jest kiepski? A może raczej testują implementację niż zachowanie?

back2dos
źródło
2
Wydaje mi się, że naprawdę dobrze oceniłeś kod dla przypadków testowych. Dziękuję Ci!
jparkcool,
4
+1 za „masz własne doświadczenia do czerpania” - tak naprawdę, jeśli ktoś naprawdę pracował z recenzjami kodu przez pewien czas, musiał zobaczyć, ile problemów z jakością zazwyczaj naprawiono podczas typowego przeglądu kodu i ile transferu wiedzy zostało osiągnięte. Z tego doświadczenia powinno być trudno nie mieć garstki argumentów za lub przeciw przeglądom kodu.
Doc Brown,
2
Jeśli chodzi o twój pierwszy akapit: wymagałoby to nie tylko dwóch zespołów wykonujących to samo zadanie, ale dwóch zespołów o równych możliwościach, indywidualne doświadczenie będzie popsuć każdą próbą zbadania tego.
David Wilkins,
„Co jeśli są nonsensowne? Lub jeśli zasięg jest kiepski?” Albo po prostu powiedz return true;.
Burhan Ali
1
Przeczytaj rozdział 20 Kompletnego kodu, aby dokładnie zapoznać się z recenzjami kodu oraz analizami i statystykami, które potwierdzają ich użycie. Oto kilka dobrych podsumowań: blog Jeffa Atwooda i inny facet
Mike Partridge
5

Z niektórych przypadkowych slajdów, które znalazłem , ale twarde dane pochodzą z książki Code Complete Steve'a McConnella:

Czy recenzje kodu są przydatne?

„Uważam, że recenzje kodów równorzędnych to jedna z największych rzeczy, które możesz zrobić, aby ulepszyć swój kod”

Jeff Atwood z Coding Horror na http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html


„Indywidualne kontrole zwykle wykrywają około 60 procent defektów, co jest wyższe niż w przypadku innych technik, z wyjątkiem prototypowania i testów beta na dużą skalę”.

Steve McConnell, Code Complete 2nd Edition, strona 485

Ta 60% pochodzi z dokumentu IEEE Shull i in. 2002 Czego się dowiedzieliśmy o zwalczaniu wad, który zawiera sekcję zatytułowaną:

„Wzajemne oceny wyłapują 60% wad”

icc97
źródło
1
Wydaje mi się, że problemem jest to, że w 2006 roku jeszcze nie w pełni przyjęliśmy programowania par, co, jak sądzę, stało się swego rodzaju zastępstwem w pewnym sensie dokonywania recenzji kodów równorzędnych. Zdaję sobie sprawę, że pod pewnymi względami nie są porównywalne.
JP Silvashy,
3

Uwaga: Ta odpowiedź jest moim osobistym doświadczeniem :)

Zrobiłem bardzo złe doświadczenia z recenzjami kodu w kodzie, który utrzymujemy. Ponieważ zwykle mamy tylko jedną linijkę i nie ma wiele do recenzji.

Ale w rzeczywistych projektach robiłem dobre doświadczenia, podczas mojego egzaminu mój trener regularnie sprawdzał mój kod i bardzo pomogło mi znaleźć błędy, które popełniłem bardzo często, których już nie popełniam.

Powiedziałbym więc, że to zależy od tego, co robisz, ilu ludzi jesteś itp.

Ryzyko, że twoje podsumowania kodu zakończą się wojną, nie jest niedoceniane.

Knerd
źródło
3

Możesz poprosić swojego kierownika zespołu i / lub kolegę o sprawdzenie kodu, nawet jeśli recenzje kodu nie są wykonywane normalnie, być może w ramach szkolenia.

Przed sprawdzeniem upewnij się, że kod jest dobrze napisany i przetestowany.

Kiedy byłem liderem zespołu, sam przeprowadzałem przeglądy kodu nowych pracowników, aż (po pewnym czasie) przestałem znajdować błędy lub cokolwiek innego, co mogłoby skrytykować ich kod, i od tego momentu przestałbym z nimi przeglądać kod; tak by się stało, gdy:

  • Nauczyli się systemów, z którymi się komunikują i nie potrzebowali moich wyjaśnień
  • Nauczyli się projektować i / lub testować swój kod, dopóki nie był wolny od błędów, zanim go zobaczyłem
  • Dowiedzieli się wystarczająco o moich wytycznych dotyczących stylu kodowania, które uważam za możliwe do utrzymania w kodzie

Recenzje kodu mają kilka celów:

  • Znajdowanie wad w kodzie
  • Transfer wiedzy między członkami zespołu

Myślę, że dobrze jest przeprowadzać recenzje kodu nowych pracowników, nawet jeśli zespół zdecyduje się pominąć recenzje kodu wśród doświadczonych członków zespołu.

ChrisW
źródło
2

Nie ma żadnej reguły kciuka, aby recenzje kodu były wykonywane na każdym opracowanym oprogramowaniu ... wszystko zależy od zakresu aplikacji, wielkości klienta i wielkości firmy. Na przykład, jeśli budujesz aplikację, w której jest to prosta aplikacja, w której w przyszłości mogą nie być wdrażane żadne dalsze wersje, wystarczą testy jednostkowe. Ale znowu przegląd kodu ma miejsce, gdy mówisz o wydajności aplikacji, w której musisz przejrzeć kod pod kątem wszelkich krótkich spadków kodu, które mogłyby zostać wykonane w lepszy sposób, aby ułatwić większą wydajność.

Przeglądy kodu są zwykle przeprowadzane, gdy zespół składa się z więcej niż 2 programistów i lidera technicznego, w którym lider techniczny chce zapewnić jakość aplikacji i upewnić się, że przestrzegane są standardy kodu, aby skalować aplikację do przyszłych ulepszeń i aktualizować ją dla różnych nadchodzące wersje.

Na przykład mamy obecnie wiele platform typu open source CMS i platformy te od czasu do czasu wydają aktualizacje, aby ulepszyć funkcje platformy, wyobraź sobie, że programista używa jednej z tych platform i nie przestrzega standardów kodowania, takich jak kodowanie twarde w plikach podstawowych, pisanie aplikacji kod w plikach szablonów, a jeśli ten kod przejdzie do produkcji, a później, gdy klient chce zaktualizować platformę do nowej wersji, nigdy nie zostanie zaktualizowany, chyba że kodowanie zostanie powtórzone zgodnie ze standardami kodowymi dla tej platformy. Tutaj staje się poważnym problemem związanym z udostępnieniem kodu do produkcji bez przeglądu kodu.

Powiedziałbym więc, że recenzje kodu wykonane przed wydaniem są koniecznością dla wszystkich profesjonalnych firm programistycznych, a wyjątki mogą dotyczyć tylko aplikacji osobistych / bardzo małej skali, w których programista jest bardzo doświadczonym programistą i ma z nim doświadczenie.

Venkat
źródło
1

Przeglądy kodu mają zalety, które nie wynikają z samego procesu recenzowania: zawsze istnieje dylemat, aby uzyskać kod wysokiej jakości, ale utworzony w krótkim czasie. Bez recenzji kodu jesteś sam, więc możesz poświęcić jakość za wykonanie kodu w krótkim czasie. Dzięki recenzjom kodu jest ten recenzent, który nie pozwala ci uciec od niskiej jakości kodu - to jest dokładnie to, czego chcesz, zmuszony poświęcić czas na uzyskanie kodu jakości, który jest tym, czego chciałeś, a który wiesz, że skończy się to oszczędzaniem czasu, ponieważ każda godzina spędzona na pisaniu lepszego kodu to dwie godziny zaoszczędzone na debugowaniu (lub więcej).

Bez recenzji kodu jesteś sam, więc utrzymanie wysokiej jakości kodu zależy od Ciebie. Prostym rozwiązaniem jest sprawdzenie każdej dokonanej zmiany i naprawienie rzeczy niezgodnych z Twoimi standardami jakości.

Pozwala to również uniknąć okropnych sytuacji, w których recenzje kodu prowadzą do zderzeń ego - sytuacji, w której programista A użyłby metody X, podczas gdy B użyłby metody Y, więc jeśli A napisze kod, użyje metody X, recenzent B nalega na metodę Y, więc A przepisuje kod za pomocą metody Y, podczas gdy gdyby B napisał kod, a A go przejrzał, stałoby się dokładnie odwrotnie.

gnasher729
źródło
0

Jeśli jesteś zwolennikiem recenzji kodu, obawiam się, że nie ma prawdziwego substytutu. Niefortunnym i stereotypowym przypadkiem jest miejsce pracy, które nie dokonuje przeglądu kodu, ponieważ (A) nie zna praktyki i / lub (B) nie chce poświęcać czasu i wysiłku na przegląd kodu system na miejscu.

Zasadniczo, aby uzyskać to, czego chcesz, potrzebujesz zmiany kultury pracy - i to nigdy nie jest proste ani łatwe. Nie zapominaj, że nawet jeśli twoje miejsce pracy jest w 100% przekonane, że recenzje kodu są doskonałe i chcą je przyjąć, przejście do nowego sposobu pracy nadal będzie wymagało znacznej inwestycji czasu, energii i wydajności. Ta inwestycja powinna się zwrócić - ale musisz mieć wpisowe na inwestycję, a nie tylko na spłatę. Zobacz wideo Roya Osherove'a „Testowanie jednostek i TDD - jak to się stało” - wyzwania związane z przyjęciem recenzji kodu są bardzo podobne do tych z przyjęcia testów jednostkowych.

W międzyczasie zrób, co możesz, aby uzyskać jak najwięcej:

  • Jeśli są inni programiści, którzy widzą wartość recenzji kodu, spróbuj sprawdzić siebie nawzajem, nawet nieformalnie.
  • Jeśli masz mentora lub programistę odpowiedzialnego za twoje szkolenie, wyjaśnij mu wartość, którą widzisz w recenzjach kodu i zapytaj, czy byłby skłonny przejrzeć twój kod, przynajmniej czasami.
  • Powiedz swojemu menedżerowi, że chcesz przejrzeć kod innej osoby, ponieważ pomoże ci to lepiej zrozumieć system.
  • Jeśli w pewnym momencie zostaniesz liderem zespołu, możesz wprowadzić recenzje kodu lokalnie, tylko dla swojego zespołu.

Główną zaletą któregokolwiek z nich jest to, że jeśli będziesz w stanie utrzymać je z czasem, programiści wokół ciebie zaczną zauważać recenzje kodu. Będziesz skutecznie demonstrować, w jaki sposób recenzje kodu można zintegrować z istniejącą kulturą - i to otwiera drogę do zmiany kultury. Recenzje kodu pomagają , więc jeśli jesteś w stanie wykazać, że na małą skalę, otworzy to drogę innym - i całej kulturze - do naśladowania twojego przykładu.

Cofnij się
źródło
-2

Przestań się o to martwić - twój nowy pracodawca po prostu nie dba o recenzje kodu. Naucz się ufać własnym umiejętnościom, a nikt inny nie powie ci, że możesz wpisać kod, który napisałeś. Wkrótce nauczysz się żyć bez nudnego i żmudnego procesu sprawdzania kodu innych osób.

Postępuj zgodnie ze wskazówkami dotyczącymi stylu (lub tylko stylu), których wszyscy inni używają. Skorzystaj z własnego doświadczenia, aby zdecydować, co wymaga komentowania, jakich konwencji nazewnictwa użyć i tak dalej.

Następnie przetestuj wszystko, zanim je zameldujesz. Najważniejsze, że działa poprawnie.

Simon B.
źródło
2
-1: Fakt, że nowy zespół PO nie dokonuje przeglądów kodu, nie czyni tego złym pomysłem. To znak dobrego inżyniera, który pomaga poprawić jakość procesu rozwoju.
Jørgen Fogh
1
@ JørgenFogh Popieram także recenzje kodu, ale wydaje się, że zakładasz, że recenzje kodu pomogłyby w tym konkretnym procesie rozwoju. Oprócz tej odpowiedzi zapytałbym, dlaczego nie robią recenzji kodu - mogą mieć dobry powód. Być może, jak sugeruje ta odpowiedź - ta firma zatrudnia osoby, które nie muszą sprawdzać swojego kodu, lub przynajmniej korzyści z tego wynikające nie są warte dodatkowych kosztów. Jeśli OP spróbuje, ale nic nie zmieni, będzie to odpowiedź, na którą można się oprzeć.
DoubleDouble,
1
Możliwe, że korzyści nie są warte kosztów. Jednak fakt, że zespół nie przeprowadza przeglądów kodu, nie mówi nam nic o tym, czy powinien.
Jørgen Fogh
4
-1: „Najważniejsze, że działa poprawnie.” Jest to dość krótkowzroczny widok tego, co ważne, jeśli chodzi o kod produkcyjny. Kod jest czytany częściej niż jest napisany. Wartość (dobrze przeprowadzonego) przeglądu kodu znacznie wykracza poza sprawdzenie poprawności. Wśród wielu zalet recenzje kodu zapewniają, że kod ma sens dla kogoś, kto go nie napisał.
Dancrumb,
-2

Jeśli Twojemu nowemu pracodawcy nie podoba się pomysł recenzji kodu, może to wynikać z negatywnego powiązania ze staromodnymi metodologiami typu dowodzenia i kontroli i dążą do stworzenia bardziej nowoczesnego, zwinnego zestawu praktyk. W takim przypadku mogą być bardziej otwarci na pomysł programowania w parach, który zapewnia wiele takich samych korzyści i jest powszechnie uważany za bardziej dynamiczną, nowoczesną praktykę.

Jules
źródło