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

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?

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

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.

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.

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.

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.

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.

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.

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.

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.

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