Jak zachęcić młodszych programistów do udziału w przeglądzie kodu?

13

Obecnie pracuję jako starszy programista z 3 młodszymi osobami pode mną i wprowadziłem proces sprawdzania kodu, aby pomóc w zarządzaniu jakością kodu wprowadzanego do produkcji.

Uważam, że dla nas wszystkich bardzo korzystne jest sprawdzanie siebie nawzajem, jednak po około 5 tygodniach procesu jestem jedynym, który może komentować narzędzie (BitBucket).

Myślę, że w pracy występują pewne problemy kulturowe i być może naturalna niechęć w przypadku, gdy ich komentarze są błędne, ale czy jest jakiś sposób i mogę pomóc młodym poczuć się bardziej komfortowo krytykując moje i nawzajem współpracując?

Graham S.
źródło
2
Zastanawiam się, czy to nie może być lepsze pytanie dla Workplace.SE, ale moje własne 2 centy jako młodszy programista. Kiedy byłem stażystą, bardzo denerwowałem się uczestnictwem w recenzjach kodu z kilku powodów: brak umiejętności, brak znajomości bazy kodu itp. Wkrótce odkryłem, że udział w recenzji kodu pomógł w obu tych aspektach ( szczególnie znajomość), a także bardzo mi pomogła, sprawiając, że poczułem, że nasza baza kodów była czymś, co bardzo mnie interesowało, więc chciałem się przyłączyć. Zdecydowanie nie zawsze zostawiałem świetne komentarze, ale nie wiedziałem, dopóki nie (cd.)
Dannnno,
2
(kont.) próbowałem i pomogło mi to lepiej pracować z zespołem jako całością. Myślę, że jeśli spróbujesz wyjaśnić, dlaczego udział w nich jest pomocny dla ciebie, zespołu i bazy kodów, nawet jeśli ich komentarze są błędne; jeśli ich komentarze są błędne, jest to prawie lepsze, ponieważ wtedy mogą się z nich uczyć.
Dannnno,

Odpowiedzi:

15

Dla mnie pytanie brzmi: „Czego szukasz swoich młodszych programistów, aby wydostać się z recenzji kodu?”. Dla mnie potencjalnie najważniejszą rzeczą jest, aby młodsi programiści uczyli się, patrząc na, co, mam nadzieję, dobry kod; jeśli zdołają znaleźć problemy w twoim kodzie, to bonus.

Jeśli szukasz młodszego personelu do nauki na podstawie recenzji kodu, najważniejszą rzeczą, którą musisz zrobić, to stworzyć środowisko, w którym nauka jest ceniona, a nie postrzegana jako strata czasu. Oznacza to wiele rzeczy:

  • Nie ma czegoś takiego jak głupie pytanie . Jeśli ktoś nie rozumie odrobiny kodu, dlaczego użyłeś określonego wzorca lub cokolwiek innego, musi swobodnie zapytać, nigdy nie zmuszając się do poczucia, że ​​marnuje on twój czas lub czas innych programistów .
  • Czas spędzony na nauce to czas dobrze spędzony . Chcesz, aby twoi młodsi programiści spędzali czas na szukaniu kodu i uczeniu się z niego, ponieważ dzięki temu będą lepsi, bardziej produktywni pracownicy w przyszłości. O ile nie jest to krytyczna poprawka, którą należy teraz przejrzeć , zachęć ich do poświęcania więcej, a nie mniej czasu na przeglądy kodu.
  • Wyżsi pracownicy nie zawsze mają rację . To, że robisz to dłużej, nie oznacza, że ​​masz rację. Jeśli myślą, że znaleźli błąd, prawdopodobnie mają rację. Jeśli uważają, że odpowiedni wzorzec projektowy byłby odpowiedni dla tego fragmentu kodu, muszą swobodnie to powiedzieć, nie otrzymując negatywnej opinii.
Philip Kendall
źródło
Wielkie dzięki za wkład, zastanowię się nad tym i omówimy to jutro na naszym stanowisku
Graham S,
1
Dodałbym: sposób na bycie ekspertem polega na popełnianiu błędów i uczeniu się na ich podstawie. w praktyce może być pomocne dla sr. deweloperzy opowiadają historie wojenne o swoich dawnych wpadkach.
5

Co tydzień organizuj spotkania poświęcone przeglądowi kodu o określonej godzinie. Sprzedałem to mojemu koledze z drużyny w ten sposób (tak naprawdę oboje jesteśmy starszymi deweloperami, ale cokolwiek):

„Przegląd kodu jest częściowo po to, abym mógł lepiej poznać Twój kod i dowiedzieć się, co dzieje się po twojej stronie, na wypadek, gdybyś kiedyś został potrącony przez ciężarówkę i kazano mi zakończyć twój sprint. Ale głównie abyś wyjaśnił swój kod komuś innemu, ponieważ kiedy to robisz, angażuje on inną część twojego mózgu, i często razy jego wyjaśnienie i / lub ich pytania lub komentarze mogą spowodować, że pamiętasz coś, o czym zapomniałeś zrobić w kodzie, lub może sprawić, że zrozumiesz lepszy sposób, aby uczynić go bardziej czytelnym lub lepiej go zaprojektować. To prowadzi do piękniejszego kodu ”.

Lubię myśleć o tym jak o show-and-tell. Ludzie mogą pochwalić się swoją pracą swoim rówieśnikom. Nie chodzi o to, aby twoi rówieśnicy znaleźli coś złego w pracy, czego nikt nie lubi. Chodzi o to, aby zaimponować swoim rówieśnikom niesamowitym kodem, który wszyscy lubią.

Jednak myślę, że używanie narzędzi do przeglądania kodu, w których nie ma interakcji człowieka, nie ma spotkania w pokoju, nie ma tablicy ... staje się to po prostu kolejną irytującą „rzeczą” do zrobienia. Nie jest tak, że nie powinny istnieć takie narzędzia, ale powinny one być czymś, na co należy się zwrócić, jeśli podczas spotkania poświęconego przeglądowi kodu zdamy sobie sprawę, że niezbędna może być bardziej szczegółowa analiza pewnej sekcji kodu. Następnie możesz przypisać jednego z młodszych programistów do przejrzenia kodu drugiego w określonym obszarze.

CommaToast
źródło
+1 za zaangażowanie innej części mózgu. Z mojego doświadczenia, zwłaszcza gdy byłem młodszym programistą, sama wiedza o tym, że mój kod będzie recenzowany, sprawiła, że ​​zwróciłem uwagę na szczegóły, które w innym przypadku mogłem zignorować.
Laconic Droid,
0

Możesz pomóc, dając dobry przykład. Nie możesz się obronić, gdy ktoś wskaże twoje błędy. Dokonaj przeglądu kodu na własnym kodzie i zanotuj obszary wymagające poprawy. Udostępnij to zespołowi. W końcu dowiedzą się, że jest to zalecane i nikt nie dostanie bicia za błąd w kodzie.

Posiadanie pracy oznacza wzięcie odpowiedzialności i dumy z pracy. Jeśli przegląd kodu jest częścią tego, udział w przeglądzie kodu powinien być uwzględniony w ocenach. Brałem udział w zajęciach online, w których udział w dyskusjach online jest częścią oceny. Należy opracować komentarze. „Zgadzam się” jest niedopuszczalne.

Przegląd kodu powinien poprawić kod. W zależności od sytuacji można to zmierzyć na podstawie numerów sprzedaży, skarg użytkowników lub innych ocen, jeśli piszesz kod do użytku wewnętrznego. Rzeczywistość jest taka, że ​​twój kod ma jakiś cel i twój zespół powinien być mierzony na podstawie tego, jak dobrze służą temu celowi. Ci, których określisz, przyczyniają się do sukcesu, dzielą się proporcjonalnie w nagrodach.

Skoncentruj się na wydaniu kodu jakości. Celem nie jest, aby wszyscy czuli się dobrze, unikając błędów. Piszę zły kod; Muszę naprawić zły kod. To jest praca i życie. Nienawidzę naprawiać błędów, więc staram się ich unikać. Jestem dumny z mojej pracy, więc przeszkadza mi, gdy mój kod nie działa. Żal mi użytkowników lub innych osób, które muszą poświęcić swój czas na wskazanie tych rzeczy i motywuje mnie to do naprawy.

Na marginesie, jeśli masz środowisko, w którym nikt nie może wyrażać ani przyjmować konstruktywnej krytyki, masz problem.

JeffO
źródło
-3

Proces: ktoś chce zatwierdzić swoje zmiany. Ktoś jest wyznaczony jako recenzent i przegląda zmiany. Następnie sprawdzone i naprawione zmiany przechodzą do testowania.

Jeśli testy wykryją błędy wprowadzone w tej zmianie, to autor i recenzent są w równym stopniu winni.

Więc dokonanie recenzji bez żadnych komentarzy sprawi ci kłopoty, chyba że kod będzie doskonały.

gnasher729
źródło
5
1) Przypisywanie „winy” za błędy to świetny sposób na spowodowanie odejścia twojego personelu 2) Przypisywanie winy młodszym pracownikom za niezauważenie błędów napisanych przez starszych pracowników jest podwójnie złe.
Philip Kendall,
2
@ PhilipKendall Jeśli mój kod zawiera błąd, nikt nie musi mnie winić. Jestem profesjonalistą i jestem dumny z mojej pracy. Czy to coś w rodzaju nowej ery, w której nikt nie robi nic złego, a wszyscy dostają trofeum za uczestnictwo?
JeffO,
@PililKendall: Nie wiem, gdzie pracujesz ... Tam, gdzie pracuję, powiem „co za głupi błąd, który popełniłem”, a recenzent mówi „i ja też tego nie zauważyłem”, a potem oboje się śmiejemy. „Wina” oznacza wzięcie na siebie odpowiedzialności, a nie stanie w kącie z nieukończonym kapeluszem.
gnasher729,
1
@ gnasher729 Tak. Ale nikt nie ma z tego powodu „kłopotów”.
Philip Kendall,