Czy młodsi programiści powinni być zaangażowani jako recenzenci kodu w projekty starszych programistów?

55

Jeden z członków mojego zespołu, młodszy programista, ma imponujące umiejętności programistyczne dla swojego poziomu doświadczenia.

A podczas przeglądów kodu kładę nacisk na uczenie się, a nie na wskazywanie błędów.

Ale czy młodsi programiści powinni brać udział w przeglądach kodu dla starszych programistów? A może w recenzjach kodu powinni brać udział tylko programiści z odpowiednim doświadczeniem?

Md Mahbubur Rahman
źródło
54
O co chodzi w tych „młodszych” i „starszych” rzeczach? IMO, czy programista jest uprawniony do przeglądu kodu innej osoby, powinno być ustalane na podstawie umiejętności i doświadczenia - nie tytułu ....
Anthill
23
Tytuł powinien być zwykle ustalany na podstawie umiejętności i doświadczenia. Jeśli ten junior jest wystarczająco dobry, aby przejrzeć kod seniorów, czas zmienić tytuł.
superM
18
Ale czasem ten tytuł zależy od polityki i gier HR :)
Michał Franc
4
Co dokładnie masz na myśli przez „młodszych programistów”? Czy są to osoby z mniejszym doświadczeniem w aplikacji, czy po prostu mniejszym doświadczeniem w branży? Z mojego doświadczenia wynika, że ​​młodszy członek personelu może być najbardziej doświadczoną osobą w danym projekcie, ponieważ pracowali nad nim najdłużej lub ostatnio.
Thomas Owens
4
@ThomasOwens, Przez „młodszych programistów” mam na myśli osoby z mniejszym doświadczeniem w branży.
Md Mahbubur Rahman,

Odpowiedzi:

62

Podstawowym celem przeglądu kodu jest znalezienie wad lub potencjalnych problemów. Wymaganymi uczestnikami przeglądu powinny być osoby, które najlepiej nadają się do zidentyfikowania tych problemów, niezależnie od ich tytułu lub stażu pracy.

Na przykład, jeśli aplikacja jest rozwijana w Pythonie, a młodszy inżynier ma większe doświadczenie w języku Python niż starszy inżynier, który napisał kod, mogą być cennym zasobem w wskazywaniu alternatywnych metod robienia czegoś, ale może także mieć mniejszą wiedzę o systemie jako całości.

Oprócz doświadczenia w zakresie narzędzi i technologii, rozważ także doświadczenie w dziedzinie aplikacji. Ktoś z 20-letnim doświadczeniem, ale tylko 1 lub 2 w branży finansowej, może uzyskać pomoc, mając do czynienia z mniej doświadczonym programistą z zaledwie 5-letnim doświadczeniem w branży finansowej.

Zapraszanie mniej doświadczonych pracowników do obserwowania i uczestniczenia w jak największym stopniu proces przeglądu kodu może być również przydatny, ponieważ pozwala im nauczyć się podstawy kodu, zadawać pytania i dowiedzieć się, czego się od nich oczekuje nie tylko w recenzjach kodu, ale także w kod, który produkują. Jednak prawdopodobnie nie chcesz angażować zbyt wielu osób (skupiając się na osobach, które mogą w pełni wesprzeć przegląd kodu i jego cel) w tym procesie.

To naprawdę dotyczy każdego rodzaju recenzji - wymagań, projektu, kodu ...

Thomas Owens
źródło
4
+1 za „Wymaganymi uczestnikami przeglądu powinny być osoby, które najlepiej nadają się do zidentyfikowania tych problemów, niezależnie od ich tytułu lub stażu pracy”. A także za doskonałą odpowiedź.
Md Mahbubur Rahman
60
„Głównym celem przeglądu kodu jest znalezienie defektów lub potencjalnych problemów”. Całkowicie się nie zgadzam. Podstawowym celem przeglądu kodu jest dzielenie się wiedzą; drugim celem przeglądu kodu jest ustanowienie standardu kodowania; wszelkie błędy znalezione podczas przeglądu to więcej szczęścia niż oceny. programmer.97things.oreilly.com/wiki/index.php/Code_Reviews
pdr
8
@pdr Standard kodowania powinien zostać ustanowiony na długo przed napisaniem pierwszego wiersza kodu. Jeśli używasz recenzji do ustalenia standardu, jest już za późno. Może to być dobry moment na dostosowanie standardu kodowania podczas opracowywania - możesz użyć recenzji, aby wskazać słabości lub zasugerować ulepszenia standardu, ale nie wyobrażam sobie rozpoczęcia projektu programistycznego bez jakiegoś standardu (nawet jeśli jest to po prostu sugerowane wytyczne języka).
Thomas Owens
5
Skąd wiesz, co wprowadzić w standardach kodowania przed rozpoczęciem projektu i staje się jasne (poprzez przegląd kodu), że różni członkowie zespołu podchodzą do tego samego problemu na różne sposoby? Nie mówimy o obudowie nazwami metod, gdzie istnieją ogólnie standardy językowe, mówimy o takich rzeczach, jak NUnit vs. MSTest; wzorce repozytoriów; możliwość powiedzenia „Hej, już napisałem opakowanie dla klientów WCF. Spójrz na moje, wybierz najlepsze z nich i ustaw je jako standard”. Te rzeczy pochodzą wyłącznie z recenzji kodu i są najlepszym powodem do ich zrobienia.
pdr
4
Framework testów jednostkowych był prawdopodobnie złym przykładem, ale często mówi się, że dwa różne opracowania wymagają rozpakowania pliku. Dwóch różnych programistów może używać różnych bibliotek, ponieważ korzystali z nich wcześniej. Nie możesz mieć WSZYSTKICH tych dyskusji z góry, bo możesz się oderwać od większej liczby spotkań niż rozwoju. Dzielenie się wiedzą poprzez przegląd kodu jest najważniejszą rzeczą, aby upewnić się, że te problemy się nie rozprzestrzeniają.
pdr
81

Czy młodsi programiści powinni być zaangażowani jako recenzenci kodu w projekty starszych programistów?

Tak, powinni. Dobrze jest czytać kod innych ludzi. (Dotyczy to zarówno dobrego, jak i złego kodu. Chociaż można mieć nadzieję, że kod starszego programisty nie będzie zły ...)

Oczywiście nierozsądne jest, aby tylko osoby starsze przeglądały kod. I nierozsądnie stawiać zbyt wysokie oczekiwania juniorów pod względem tego, co mogą znaleźć. Możesz jednak być zaskoczony świeżymi spostrzeżeniami, które mogą przynieść młodsi programiści.


W innej odpowiedzi wspomniano, że juniorzy są / czują się zastraszeni. To NIE powinno być recenzowanie kodu ... ani dla recenzentów, ani dla recenzentów. Jeśli tak się dzieje, twoja grupa musi zmienić sposób, w jaki dokonuje przeglądów kodu ... a może zastraszacze muszą zostać doprowadzeni do linii.

Stephen C.
źródło
Myślę, że mouviciel ma na myśli to, że kod seniorów może być onieśmielający, a nie sami seniorzy (jeśli tak, to tak, zespół ma poważniejsze problemy niż to, kto może przejrzeć kod).
yannis
6
@YannisRizos - 1) Nie czytam tego w ten sposób. 2) W tym momencie pojawia się „nierozsądne jest oczekiwanie zbyt wiele” . Jeśli kod seniora jest „onieśmielający”, wtedy szczególnie przydatne dla rozwoju juniora jest próba jego odczytania / zrozumienia.
Stephen C
1
Nauczenie się, jak myślą programiści, to kolejna cenna część recenzji kodu dla młodszych programistów. Kiedy byłem młodszym programistą, kod miał większy sens, gdy starszy programista sprawdził go ze mną.
Michael Shopsin
38

Dodałbym, że jeśli programista „Junior” nie rozumie kodu seniorów, to sam w sobie jest dobrą miarą kodu. OK, mogą zdarzyć się chwile, gdy po prostu nie będzie możliwe napisanie kodu, który każdy może zrozumieć, ale mam nadzieję, że są to wyjątki - jeśli tylko 1 lub 2 osoby mogą zrozumieć kod, co się stanie, gdy ci ludzie nie będą dostępni i wystąpi problem z to?

Stawianie ludziom nowych wyzwań pomaga im się rozwijać; być może nie wszyscy są wykluczeni z recenzowania kodu, ale dogmatyczne jest naleganie, aby ktoś miał tytuł ( określony przez politykę HR i gry ), zanim będzie mógł pomóc w recenzji.

Jak zauważyli inni, przegląd kodu może być procesem dwukierunkowym; pomaga każdemu zrozumieć bazę kodu, więc dzieli się wiedzą, pomaga młodym uczącym się nowych i lepszych sposobów i technik od swoich seniorów oraz pomaga seniorom udoskonalić ich zrozumienie i pisząc, aby każdy mógł przestrzegać kodu, masz więcej oczu, które mogą łapać błędy.

Simon Martin
źródło
6
To dobre zdanie wstępne.
pdr
Jeśli kod używa bardziej zaawansowanych technik (np. Operacji ustawiania zamiast tablic i pętli), wówczas dzieje się tak, że ktoś w zespole podnosi swoją grę.
kevin cline
1
Podczas przeglądania kodu jest to bardzo silny wskaźnik, że kod potrzebuje komentarza lub dwóch, jeśli ktoś musi zapytać, co robi dany fragment kodu.
Bryan Anderson
24

Celem przeglądów kodu jest wychwycenie problemów, których nie mogą wykryć testy, takich jak problemy z utrzymaniem i przypadki narożne. Twierdziłbym, że pod wieloma względami młodsi programiści lepiej nadają się do tego celu:

  • Mają ogólnie więcej czasu.
  • Bardziej prawdopodobne jest, że podejmą to powoli, wiersz po wierszu, z konieczności zrozumienia kodu.
  • Kiedy mówisz o tym, że kod jest łatwy do utrzymania, oznacza to, że wszyscy w firmie, nie tylko najlepsi programiści. Oznacza to, że twoi młodsi programiści muszą być w stanie zrozumieć kod, aby zadeklarować jego utrzymanie.
  • Często rzadziej przyjmują złe założenia, ufając, że coś działa tak, jak zakładają, że powinno działać.
  • Ich edukacja w języku programowania jest nowsza i rzadziej będzie mylona wraz z wieloletnim doświadczeniem w innym języku. Na przykład senior może przypadkowo skorzystać z nawyku, który wybrał z C ++, który kompiluje, ale działa nieco inaczej w Javie. Juniorzy łatwiej wychwytują tego rodzaju błędy.
  • Recenzenci kodu muszą jedynie identyfikować problemy, niekoniecznie proponując lepsze rozwiązanie. Często komentują: „Nie mogę naprawdę wymyślić, jak to zrobić lepiej, ale ta część jest naprawdę myląca z powodu całej powtarzalności”. Bardziej doświadczony programista może łatwo wprowadzić ulepszenia, nawet jeśli początkowo nie zauważyli problemu.

Nie oznacza to, że nie ma innych sposobów, w jakie starsi programiści lepiej nadają się do robienia recenzji, ale mam na myśli, że robisz krzywdę, jeśli nie w pełni korzystasz z różnorodności swojego zespołu.

Karl Bielefeldt
źródło
13

Juniorzy często proszeni są o utrzymanie kodu, bardzo ważne jest, aby mogli go zrozumieć.

Czasami juniorzy są jedynymi osobami dostępnymi do przeglądu kodu starszych programistów. Czy kod powinien czekać na przejście do kontroli jakości (nie wypychamy niczego z dev bez recenzji kodu i zakładam, że ten rodzaj recenzji również), ponieważ szef seniora jest na wakacjach?

Specjalnie poprosiłem juniorów o sprawdzenie kodu, gdy wiedziałem, że wkrótce zrobią coś podobnego dla innego klienta lub gdybym wiedział, że pracowali nad czymś podobnym lub że mieli określony zestaw umiejętności.

Jeśli kod jest dość prosty, często zlecam sprawdzenie młodszej osobie. Po co marnować czas osoby starszej, jeśli osoba młodsza jest w stanie wykonać tę pracę? Jeśli juniorzy czują się zastraszani, przeglądając kod seniora, poproś, aby początkowo spojrzeli na łatwiejsze elementy. W końcu nie możesz przejść przez młodość, dopóki nie przestaniesz być zastraszonym.

Często stwierdzam, że jeśli muszę wyjaśnić kod młodszej osobie, która go nie rozumie, zobaczę błąd, który popełniłem (zwykle w założeniu) i że żaden doświadczony recenzent kodu nie złapałby go, ponieważ kod działa ale nie robi dokładnie tego, co było zamierzone. Tak więc samo wyjaśnienie rzeczy często pomaga programistom dostrzec problem bez znalezienia go przez recenzenta kodu. Ponieważ bardziej doświadczeni ludzie nie są często przechodzeni przez kod krok po kroku, tego rodzaju rzeczy można łatwiej znaleźć, gdy młodszy dokonuje przeglądu.

Uważam, że udział juniora w recenzjach ma kilka dobrych efektów. Po pierwsze, zwiększa ich pewność siebie, gdy rozumieją kod osoby starszej. To sprawia, że ​​są jeszcze bardziej pewni, kiedy mogą znaleźć błąd w tym kodzie.

Naraża ich na procesy myślowe poza własnymi i pozwala im dostrzec inne sposoby postępowania. Przydarzyło mi się to jako osoba starsza - spojrzenie na inny sposób rozwiązania problemu może otworzyć oczy na nowe możliwości.

Pomaga im nauczyć się czytać kod innych ludzi i daje im możliwość zapytania, co robi kod, gdy jest jeszcze świeży w umyśle autora. To o wiele lepsze niż konieczność utrzymywania tej rzeczy sześć miesięcy później, kiedy autor już dawno nie ma lub jest zajęty innym projektem i nie ma czasu na pytania.

Jest to dobre dla seniorów, ponieważ pytania zarówno ujawniają potencjalne obszary, w których młodszy jest słaby i potrzebuje mentoringu (aby mogli wziąć większą odpowiedzialność i dać seniorom więcej czasu na wykonywanie innych rodzajów zadań) lub obszary, w których kod po prostu nie jest jasny ktokolwiek poza autorem (co oznacza, że ​​autor może nawet nie wiedzieć za rok, kiedy trzeba to zmienić). Pomaga także seniorom zdać sobie sprawę, że juniorzy mogą być mądrzejsi, niż im przypisują. Pomaga wszystkim utrzymać profesjonalną postawę. W końcu, jeśli wykluczysz juniorów, to wyraźnie sugerujesz, że nie sądzisz, że są w stanie zrozumieć kod, który jest psychologicznie niefortunny.

Juniorzy przeglądający kod seniorów mogą generować większy szacunek zawodowy w Twojej organizacji. Seniorzy mogą zdawać sobie sprawę, że nie doceniają juniorów, a juniorzy mogą zdawać sobie sprawę, że seniorzy wiedzą więcej, niż im przypisali. Juniorzy czasami myślą, że mają większe umiejętności niż oni. Narażenie na kod, którego nie potrafią pisać, jest dobre dla tych ludzi, ponieważ zaczynają zdawać sobie sprawę, że muszą się wiele nauczyć. Pobudzi także najlepszych z nich, aby zdobyć umiejętności. W szkole czasami uczniowie klasy B nie rozumieją, dlaczego nie dostali litery A, dopóki ktoś nie pokaże im próbki pracy na poziomie A. To samo dotyczy juniorów i seniorów podczas przeglądu kodu.

HLGEM
źródło
7

Moja odpowiedź brzmi: czasami . Będzie się różnić od programisty do programisty i od zadania do zadania.

Dla:

  • Jeśli chcesz, aby ci juniorzy nauczyli się, jak przeprowadzać skuteczny przegląd kodu, najlepszym sposobem jest przekonanie się, jak to robią seniorzy.
  • Młodszy programista może mieć większe doświadczenie niż starszy w danym języku / domenie / itp.
  • Zmuszając juniorów do oceny kodu seniorów, nieuchronnie będą się uczyć. Programowanie w parach będzie jednak bardziej efektywnym sposobem na zrobienie tego, ponieważ wszelkie pytania, które może mieć junior, mogą uzyskać natychmiastowe odpowiedzi.
  • Kod nikogo nie jest święty i nikt nie jest tak dobry, że jego kod nie powinien być sprawdzany. Jeśli tego nie zrobisz, kto będzie sprawdzał kod twoich najlepszych facetów?
  • Nie wszyscy juniorzy są równi i nie wszyscy seniorzy są równi. Czasami może nie być dużej luki, więc nie odkładaj słuchawki na stanowiska pracy.

Przeciwko:

  • Istnieje ryzyko, że recenzje utkną w martwym punkcie bez problemów.
  • Wymagany poziom wiedzy / umiejętności może po prostu przekraczać możliwości juniora. To nie tylko zmarnuje ich czas, ale całkiem możliwe, że zdemoralizują je.
Vaughandroid
źródło
5

Jestem głęboko przekonany, że każdy w zespole powinien być zaangażowany po obu stronach recenzji kodu. Juniorzy powinni przejrzeć kod Seniora i odwrotnie. Dlaczego oba? Ponieważ zwykle nie chodzi tylko o to, czy kod „rozwiązuje problem”. Nie potrafię powiedzieć, ile razy musiałem wyjaśniać komuś fragment kodu i nagle pod koniec wyjaśniania wpadłem na lepszy sposób. Recenzje kodu służą prawdopodobnie 3 celom:

  1. Upewnij się, że kod jest poprawny
  2. Niech pisarz pomyśli o tym, jak inni zobaczą swój kod
  3. Uzyskaj opinie czytelnika na temat tego, co można poprawić, i ogólną drugą parę oczu

Jestem młodszy i często przeglądam starszy kod pisany. Jest to ogólna polityka firmy „wszystko jest sprawdzane przez kogoś”. Dużo się uczę od przeglądania ich kodu i możliwości zadawania pytań o to, dlaczego rzeczy są robione w określony sposób. Czasami proponuję czystszy sposób na zrobienie określonego fragmentu kodu i tym podobnych. Znacznie rzadziej niż ludzie mówią mi, jak poprawić mój kod, ale zdarzyło się to przynajmniej raz.

Ważne jest również, jak formalne są twoje recenzje kodu. Nasz jest bardzo nieformalny i polega na tym, że „hej spojrzysz na mój kod” wypowiadany w kabinach lub na prywatnym kanale IRC. Mogę sobie wyobrazić, że jeśli przejrzysz kod w bardziej formalnym otoczeniu, junior byłby prawdopodobnie znacznie bardziej zastraszony recenzowaniem kodu seniora.

Earlz
źródło
2

Absolutnie, młodsi inżynierowie powinni przynajmniej raz zapoznać się z kodeksem starszych inżynierów.

Z mojego doświadczenia wynika, że ​​bardzo rzadko recenzent w recenzji kodu jeden na jeden rzeczywiście widzi błąd, który został pominięty przez pierwotnego programistę, niezależnie od tego, czy recenzent jest starszy, czy młodszy; recenzent nie musi nawet być człowiekiem . Z drugiej strony bardzo często zdarza się, że oryginalny program rozpoznaje błąd podczas próby wyjaśnienia kodu, a im młodszy recenzent, tym bardziej prawdopodobne, ze względu na wymaganą głębokość wyjaśnienia.

Moim zdaniem, niektóre częściej pomijane zalety przeglądu kodu, które są prawdopodobnie ważniejsze na dłuższą metę niż wykrywanie błędów:

  • Dzieląc się wiedzą o tym, co faktycznie dzieje się w bazie kodu - „Czekaj, myślę, że Bill miał klasę, która robi X, nie musimy pisać nowej”.
  • Dzielenie się wiedzą na temat dobrych technik i stylu programowania.

W obu tych aspektach młodszy recenzent zwykle odnosi więcej korzyści niż starszy.

Russell Borogove
źródło
2

Młodsi programiści powinni absolutnie przeprowadzać recenzje kodu dla swoich starszych kolegów!

Nie powinni jednak być jedynym recenzentem . Połącz je z bardziej doświadczonym programistą na podstawie recenzji kodu.

Istnieje niezliczona ilość korzyści:

  • Autor będzie zmuszony wyjaśnić więcej swojego kodu. Omówienie kodu jest jednym z najlepszych sposobów na znalezienie problemów z nim lub lepszych sposobów na zrobienie tego.

  • Autor znajdzie słabości w swoim kodzie. Młodszy twórca jest bardziej zdezorientowany przez niektóre bardziej zaawansowane części. Często są one „zbyt trudne” dla własnego dobra i mogą skorzystać z uproszczenia.

  • Młodszy programista nauczy się lepszych praktyk kodowania. Recenzje kodu są okazją do nauczania przez przykład.

  • Młodszy programista będzie bardziej skutecznym recenzentem kodu. Przeglądanie kodu jest trudne . Im bardziej doświadczeni są użytkownicy przeglądów kodu, tym szybsze i bardziej skuteczne stają się recenzje kodu.

  • Młodszy programista będzie miał głębszą wiedzę na temat bazy kodu. Bądź samolubny! Wciągając młodszych programistów wcześniej, będziesz mógł im je przekazać wcześniej.

  • Młodszy deweloper poczuje się bardziej zaangażowany. Młodszy programista zacznie postrzegać „starszy” kod (i ich kolegów) jako mniej obcy i zastraszający. Jest to ogromna i często pomijana zaleta recenzji kodu.

  • Młodszy twórca to świeży zestaw oczu. Nie są tak indoktrynowani jak ktoś, kto pracuje nad bazą kodu od dłuższego czasu. Młodszy programista częściej wskazuje różne sposoby osiągania celów, zadając pytania. Nie przejmuj się ich szalonymi komentarzami bez przynajmniej odrobiny uwagi!

  • Starsi deweloperzy są rozliczani. Często widziałem sytuacje, w których starsi deweloperzy mają tendencję do przerzucania się kodami innych osób (zaufanie, lenistwo itp.). Dodatkowy zestaw oczu pomaga go zniechęcić.

Minusem, który należy wziąć pod uwagę, jest to, że wszystkie zaangażowane strony spędzą sporo czasu na przeglądaniu kodu. Dlatego może to być trudna sprzedaż dla kierownictwa. Korzyści całkowicie przewyższają jednak wolniejsze tempo.

Nevir
źródło
0

Recenzja kodu służy do przeglądania kodu, a nie do nauki. Gdybym był młodszym programistą, byłbym zastraszony do przejrzenia kodu seniora.

Z drugiej strony, czytanie kodu seniora to świetny sposób na naukę, pod warunkiem, że senior jest dostępny do udzielania odpowiedzi na wszystkie pytania.

Dwie alternatywy mogą być:

  • niech Juniorzy będą uczestniczyć w spotkaniach dotyczących przeglądu kodu i niech każdy uczestnik będzie otwarty na niektóre dyskusje dotyczące nauczania / uczenia się
  • ćwiczyć programowanie par
mouviciel
źródło
7
Recenzje kodu mogą być doświadczeniami edukacyjnymi. To powiedziawszy, w pełni się zgadzam, to nie jest ich główny cel. Idealnie powinni być zaangażowani wszyscy członkowie zespołu, ale rozumiem, o co ci chodzi. Trochę potrwa, zanim (prawdziwie) młodszy programista będzie wystarczająco pewny siebie, aby wskazać wady (zakładając, że może je najpierw zidentyfikować, czego też nie chciałbym szczerze oczekuję od juniora recenzji kodu seniora).
yannis
PO wyraźnie stwierdził, że młodszy programista ma dobre umiejętności. Mniejsze doświadczenie nie zawsze oznacza recenzje kodów o niższej jakości.
Cascabel,
@Jefromi: OP wyraźnie powiedział, że chce ustawić cel przeglądu kodu na uczenie się. Mówię tylko, że nie po to są przeznaczone.
mouviciel
Hm, myślę, że różnie rozumiemy PO - post kładzie nacisk na naukę, ale mówi też „zaangażowany jako recenzenci kodu”, co sugeruje, że młodszy programista nie jest jedyną osobą.
Cascabel,